そうこうするうちにAMD Athlon 64 X2マシン上では、VMware Serverが安定稼動し、開発環境やWebサーバとして活躍しているわけだが、Hostからブリッジ接続しているGuest(VM)への通信性能が異常に悪いことに気がついた。一方でGuestからHost、GuestからGuest、Hostから他のHost(とその逆)、Guestから他のHost(とその逆)はまったく問題のない性能を示す。
NetperfでTCP STREAMのスループットを計測すると、Guest→Hostは427.37Mbpsに対して、Host→Guestは0.52Mbps。ざっとみて1000倍遅い。
調べたところ、Host NICにNVIDIA nForce Ethernet NICを使っている場合にはTCP Segmentation Offload(TSO)がenabledになっていると遅くなることがあるようだ。TSO機能はTCPやUDPのチェックサム計算、セグメンテーション処理などをNIC上で実行させることでCPUの負荷を削減するもの。Host上で、
# /sbin/ethtool -K eth0 tso off
しておけばTSOはdisableされるので速度は大幅に改善する。
Host(FC-6-x86_64)→Guest(FC-6-x86_64):
| TSO on | 0.52Mbps |
|---|---|
| TSO off | 94.20Mbps |
ちなみに「Guest→Host」の結果とIntelマシンでの結果も書いておく。これらの場合にはTSO offの場合の方が微妙に良い結果が得られているが、測定誤差の範囲内か、TSOによるCPU負荷の軽減効果を選択した方がよい程度のアドバンテージしかない。
Guest(FC-6-x86_64)→Host(FC-6-x86_64):
| TSO on | 427.37Mbps |
|---|---|
| TSO off | 435.70Mbps |
Host(CentOS-4.4-i386)→Guest(CentOS-4.4-i386):
| TSO on | 90.96Mbps |
|---|---|
| TSO off | 94.69Mbps |
Guest(CentOS-4.4-i386)→Host(CentOS-4.4-i386):
| TSO on | 414.99Mbps |
|---|---|
| TSO off | 455.05Mbps |
ところで、Guest→Hostが400Mbps以上出ているのにHost→Guestは90Mbps強しかスコアが出ていない。これにはVMwareのブリッジ接続の構造に由来する、ちゃんとした理由がある。
ブリッジ接続の様子は下の図のように書ける。Hostのeth0は外部スイッチに接続するとともにVMwareの仮想スイッチvmnet0にも接続しているのに対して、ゲストのeth0はvmnet0にのみ接続している。
このとき、Guest→Hostはvmnet0を介して直接に通信できる(赤字の経路)が、Host→Guestは一旦外部スイッチを経由し、Host eth0、vmnet0、Guest eth0を順次経由してしか通信できない(緑字の経路)。なぜそうなるかと言えば、(1)Guestがvmnet0に接続していても外部スイッチに接続していても、Hostのarp tableではeth0にGuestが繋がっているとしか表現しようがなく、(2)eth0にエミットされたパケットはプライマリーには外部スイッチに送出されるため、だ。Guestあてのパケットは、外部スイッチを経由して、promiscuous modeで動作するHost eth0にキャプチャされ、無事にvmnet0経由でGuest eth0に到達する。
したがってHost→Guestの通信速度は外部スイッチのスループットに制限される。上記の計測でHost→Guestが90Mbps強しか出ていなかったのは、つまりは外部スイッチが100Base-TXだったため。Gigabit Ethernet Switchを使えば、Guest→Hostと同程度まで高速化される見込みがある。
0 コメント:
コメントを投稿