オンボードのGbEの性能が出ませんでした

2月18日の朝から定例のFirefoxのアップデートが始まりました。今回は借りていたSun Multithreaded 10 GbE Networking Card (nxge)を返却していたので、オンボードの4つのGbEをアグリゲートして立ち向かったのですが、見事に玉砕しました。

18日の18時ごろに急に出力パケットが詰まり、外からのpingにも応えなくなったので、一番怪しいLSOを切って19時ごろにリブートしました。ところが1時間も経たないうちにまた詰まってしまったので、今度はJumbo Frameを切って21時15分ごろにリブートしたのですが、ちょっと手違いがあって20分ほど外からアクセスできないになってしまいました。

Sun Fire T2000はIntelのDual Port Ethernet Controller (82575EB)を2つ積んでいます。Intelのサーバ用のEthernet ControllerにはLSO (Large Segment Offload)という機能があって、大きなセグメントをControllerにそのまま転送すれば、mssに分割してTCPヘッダとIPヘッダを付けて流してくれます。この機能を使うとCPUの負荷がぐっと軽くなります。

しかし残念ながらつい最近まで、このLSOという機能は地雷でした。最新のアップデートのs10u8のリリースノートにもe1000g ドライバが破損した LSO パケットを生成する (6855964)ということで、使ってはいけないことになっていました。ところが2月8日にこの問題を解決するパッチがリリースされました。それならLSOを有効にして4つのGbEをアグリゲートすれば、nxgeがなくてもいけるだろうと思ったのですが、うまくいきませんでした。

最初に詰まったときは原因をLSOと決め付けて、まったく分析せずにLSOを切ってリブートしてしまいました。2回目のときはdld_tx_enqueueで詰まっていました。これはアグリゲートしたインターフェイスのキューにメッセージを投入する部分です。キューに空きがなくて詰まっていたので、その下のe1000gドライバの処理がうまくいっていなかったようです。デフォルトと異なるe1000gの設定はJumbo Frameしかなかったので、Jumbo Frameを切ってリブートしたところ、詰まることなく処理されるようになりました。

しかし、Path MTU Discoveryを有効にしているので、Jumbo Frameが流れることはほとんどありません。たまに流れるJumbo Frameが止めを刺したのかもしれませんが、IntelのEthernet ControllerがJumbo Frameごときで発狂するのはあまりにも不自然です。

結局LSOもJumbo Frameもなしで乗り切ったのですが、アクセスのピークではCPUを100%使い切る状態でした。下のグラフの最初の100%はログファイルの圧縮によるもので、午前6時のピークがそうです。この程度の負荷で100%だなんてnxgeでは考えられません。