ほぼデフォルト設定状態のRHEL6系OSで通信オフロード設定の有効/無効によって、通信の転送速度がどれほど差異があるか検証してみました。検証環境の概要は下記のとおりです。
- さくらのクラウドで仮想サーバを2台用意して、サーバ間をスイッチで繋げて速度測定。
- 測定対象サーバにはSientific Linux 6.5をインストール。
- 対向サーバにはUbuntu 14.04.0をインストール。
- 測定環境のサーバのNICの理論回線速度は公称1000Mbps （最大実効速度は500Mbps程度）。
- サーバ間を結ぶスイッチの回線速度は無制限。（概ねNICのほうの実効速度に依存する。）
- 速度測定には iperf を使用。
今回、変更対象となる通信オフロード設定は、仮想NIC (Network Interface Card) の TSO (TCP Segmentation Offload) と GSO (Generic Segmentation Offload) の設定。
ざっくり解説すると、TSOは送信パケットの分割処理をNICにオフロードする機能、GSOは受信パケットをNICが結合してからOSに渡すオフロード処理をソフトウェアで実装した機能です。
経験上、この手の設定を変更すると、通信の並列度（同時通信数）が増えるほどに通信速度に与える影響も大きくなりがちなので、iperfによる速度測定では1並列（-P1）のパターンと100並列（-P100）のパターンとで各3回、1回あたり5分(-t300)の試験をしてみました。検証結果は以下のとおりでした。
検証結果
TSO on / GSO on ( ethtool -K ethX tso on gro on )
| 並列度 | 1回目 | 2回目 | 3回目 |
|---|---|---|---|
| 送信(TX) 1並列 | 483 Mbits/sec | 478 Mbits/sec | 482 Mbits/sec |
| 送信(TX) 100並列 | 311 Mbits/sec | 301 Mbits/sec | 310 Mbits/sec |
| 受信(RX) 1並列 | 481 Mbits/sec | 454 Mbits/sec | 456 Mbits/sec |
| 受信(RX) 100並列 | 316 Mbits/sec | 291 Mbits/sec | 312 Mbits/sec |
RHEL6系のデフォルト設定です。まあまあ、こんなもんでしょう。
TSO on / GSO off ( ethtool -K ethX tso on gro off )
| 並列度 | 1回目 | 2回目 | 3回目 |
|---|---|---|---|
| 送信(TX) 1並列 | 454 Mbits/sec | 452 Mbits/sec | 453 Mbits/sec |
| 送信(TX) 100並列 | 396 Mbits/sec | 384 Mbits/sec | 391 Mbits/sec |
| 受信(RX) 1並列 | 451 Mbits/sec | 452 Mbits/sec | 455 Mbits/sec |
| 受信(RX) 100並列 | 336 Mbits/sec | 336 Mbits/sec | 299 Mbits/sec |
100並列のとき、送信速度が20%が改善されました。
TSO off / GSO on ( ethtool -K ethX tso off gro on )
| 並列度 | 1回目 | 2回目 | 3回目 |
|---|---|---|---|
| 送信(TX) 1並列 | 483 Mbits/sec | 475 Mbits/sec | 483 Mbits/sec |
| 送信(TX) 100並列 | 213 Mbits/sec | 213 Mbits/sec | 199 Mbits/sec |
| 受信(RX) 1並列 | 451 Mbits/sec | 454 Mbits/sec | 447 Mbits/sec |
| 受信(RX) 100並列 | 314 Mbits/sec | 320 Mbits/sec | 311 Mbits/sec |
100並列のとき、送信速度が約30%低下しました。なるべく、TSOはoffにしないほうが良さそうな結果が出てきました。
TSO off / GSO off ( ethtool -K ethX tso off gro off )
| 並列度 | 1回目 | 2回目 | 3回目 |
|---|---|---|---|
| 送信(TX) 1並列 | 148 Mbits/sec | 145 Mbits/sec | 136 Mbits/sec |
| 送信(TX) 100並列 | 150 Mbits/sec | 144 Mbits/sec | 154 Mbits/sec |
| 受信(RX) 1並列 | 479 Mbits/sec | 479 Mbits/sec | 475 Mbits/sec |
| 受信(RX) 100並列 | 324 Mbits/sec | 304 Mbits/sec | 337 Mbits/sec |
おっと、送信速度が約65%低下しました。これはダメダメですね。
まとめ
TSOとかGSOのようなオフロード機能は通信が不安定になる要因の一つだから、何も考えずにoffにしとけって話も一時期ありましたが、どんな環境でもオフロード機能をoffにしとけば良いというわけでもないということがわかりました。検証って大事ですね。
RHEL6系のOSならTSO on / GSO offが最も高速な設定ではないかと思います。もしくは、安心のデフォルト設定を採用してTSO on / GSO onのままでも良いと思います。
ちなみに、Ubuntu 14.04でも同様の検証をしてみましたが、Kernel 3.x系のネットワーク周りの作り込みが優秀なのか、ここまで極端な回線速度の落ち込みは確認できませんでした。
なお、今回の検証は特定のクラウド環境上における仮想サーバでの検証結果であって、物理サーバの場合は結果がさらに変わるはずですし、仮想サーバのために採用されているハイパーバイザーによってもエミュレーターやドライバーのチューニング度合いが各々異なるので結果は変わるはずです。
また、通信処理の一部をNICにオフロードする機能なので、サーバの負荷次第ではTSOやGSOをonにしていると、通信が不安定になることがあります。逆に、TSOやGSOをoffにすると通信ができなくなる環境もあるのでチューニングを試みる際には色々と注意が必要です。
以上、参考までに。