NICポーリングと割り込みを必要とするネットワーク負荷は何ですか？

フレーム結合（NAPI）が必要な場合、およびフレームごとに1つの割り込みで十分な場合に答えられるデータまたは基本的な計算はありますか？

私のハードウェア：IBM BladeServer HS22、Broadcom 5709 Gigabit NICハードウェア（MSI-X）、デュアルXeon E5530クアッドコアプロセッサ。主な目的は、Squidプロキシサーバーです。スイッチはCisco 6500シリーズです。

私たちの基本的な問題は、ピーク時（100 Mbpsのトラフィック、10,000 ppsのみ）に、待ち時間とパケット損失が増加することです。2.6.38への多くのチューニングとカーネルアップグレードを行った結果、パケット損失は改善されましたが、遅延は依然として不十分です。pingは散発的です。ローカルGbps LANで200ミリ秒にもジャンプします。CPU /メモリの負荷は良好ですが、Squidの平均応答は30msから500 + msにジャンプします。

ピーク時には、割り込みは約15,000 /秒に上昇します。KsoftirqdはCPUをあまり使用していません。irqbalanceをインストールして、すべてのコアでIRQ（eth0とeth1にそれぞれ8）のバランスを取りましたが、それはあまり役に立ちませんでした。

Intel NICにはこのような問題はないように見えますが、ブレードシステムと固定構成ハードウェアの事実を行うため、Broadcomsに固執しています。

すべてがNICが主犯であると指摘しています。私が今持っている最良のアイデアは、レイテンシーを低く、スループットを高く保ちながら、割り込みを減らすことです。

残念ながらbnx2はadaptive-rxまたはtxをサポートしていません。

適応割り込みの対NAPIスレッドの答えが与えられた問題を回避するための割り込み調停の偉大なオーバービューが、どのように計算最適のethtool合体設定への具体的な情報を提供します。単なる試行錯誤よりも優れたアプローチがありますか？

上記のワークロードとハードウェア構成にはNAPIも必要ですか？または、パケットごとに単一の割り込みで生きることができますか？

それを試して理解するためにいくつかの読書をしていた大きな質問。私は答えを持っていると言うことができます...しかし、おそらくいくつかのヒント。

少なくともあなたの質問に答えることができます、「パケットごとに単一の割り込みで生きることができるか」。私は非常に忙しいファイアウォールに基づいて、答えはイエスだと思います：

Sar出力：

03:04:53 PM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
03:04:54 PM        lo     93.00     93.00      6.12      6.12      0.00      0.00      0.00
03:04:54 PM      eth0 115263.00 134750.00  13280.63  41633.46      0.00      0.00      5.00
03:04:54 PM      eth8  70329.00  55480.00  20132.62   6314.51      0.00      0.00      0.00
03:04:54 PM      eth9  53907.00  66669.00   5820.42  21123.55      0.00      0.00      0.00
03:04:54 PM     eth10      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM     eth11      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth1      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth2 146520.00 111904.00  45228.32  12251.48      0.00      0.00     10.00
03:04:54 PM      eth3    252.00  23446.00     21.34   4667.20      0.00      0.00      0.00
03:04:54 PM      eth4      8.00     10.00      0.68      0.76      0.00      0.00      0.00
03:04:54 PM      eth5      0.00      0.00      0.00      0.00      0.00      0.00      0.00
03:04:54 PM      eth6   3929.00   2088.00   1368.01    183.79      0.00      0.00      1.00
03:04:54 PM      eth7     13.00     17.00      1.42      1.19      0.00      0.00      0.00
03:04:54 PM     bond0 169170.00 201419.00  19101.04  62757.00      0.00      0.00      5.00
03:04:54 PM     bond1 216849.00 167384.00  65360.94  18565.99      0.00      0.00     10.00

ご覧のとおり、1秒あたりの非常に高いパケット数がカウントされ、このマシンでは特別なethtoolの調整は行われていません。ああ...しかし、Intelチップセット。：\

行われた唯一のことは、インターフェースごとに、/ proc / irq / XXX / smp_affinityを使用した手動のirqバランシングでした。なぜirqbalanceではなくそのように選択したのかはわかりませんが、うまくいくようです。

私はあなたの質問に答えるために必要な数学についても考えましたが、あまりにも多くの変数があると思います。要約すると、私の意見では、答えは「いいえ」です。ここで結果を予測することはできないと思いますが、十分なデータキャプチャがあれば、より良いレベルに調整できるはずです。

そうは言っても、私の直感では、ここで何らかの形でハードウェアに縛られているということです...ファームウェアや相互運用性のバグのように。

確かに、CPU、チップセット、およびバスの能力が、トラフィック量が非常に少ないことと比較すると、何らかの形式の割り込み管理が必要になる理由はまったくありません。10Gbps NICを備えた複数のRHEL 5.3 64ビットマシンがあり、それらの割り込みはまったく悪くありません。これは100倍少ないです。

明らかに構成が固定されているので（かなり似たHPのブレードを使用しています）、IntelのNICを交換するのは簡単なオプションになりましたが、私はこのフォーラムや他の場所で同様の問題をいくつか発見し始めたということですその特定のBroadcom NICで。これまで、SEサイト自体にこの種の不整合に関する問題がいくつかあり、Intel NICへの切り替えは絶対に役立ちました。

私がお勧めするのは、単一のブレードを選び、Intelベースのアダプターをその1台のマシンに追加することです。明らかに、相互接続またはIBMが呼び出すものを追加して信号を取得する必要がありますが、同じソフトウェアセットアップを試してくださいNIC（可能であればBroadcomを無効にする可能性があります）。これをテストして、どのように実行するかを確認してください。説明した内容には、2、3ビットの追加ハードウェアが必要であることがわかりますが、IBM担当者が喜んで貸してくれると思います。確実に知る唯一の方法です。奇妙なエッジケースであっても、これらのNICに問題がある場合、私はあなたが見つけたことを教えてください、私は本当に興味があります。余談ですが、私は来週インテルとブロードコムと会って、まったく関係のないことを話し合いますが、確かにそれについて話し合い、興味のあることを見つけたらお知らせします。

割り込みに関する問題は、割り込みがシステム全体のパフォーマンスにどのように影響するかです。割り込みは、ユーザーとカーネルの土地処理を先取りすることができ、CPUの使用量はあまり見られないかもしれませんが、コンテキストの切り替えが多く発生し、パフォーマンスが大幅に低下します。あなたが使用することができvmstat、チェックsystem欄を、cs割り込みやコンテキストのヘッダは、その価値があまりにもチェック、毎秒（あなたがそれを重み付けしなければならないので、割り込みがクロックを含む）に切り替わります。

短い直接的な答え：

ポーリングを有効にすると、コンテキスト切り替え（通常は割り込みによる）を現在の状態（この場合は15kips）から事前に決定された数（通常は1kから2k）に減らします。

現在、所定の数を超えるトラフィックがある場合は、ポーリングを有効にして応答時間を改善する必要があります。その逆も同様です。コンテキストの切り替えがパフォーマンスに影響を与えない限り、これが「必要」だとは言いません。

フォローアップ：NATとconntrackモジュールがアンロードされ、さらに最小化されたiptablesルールセットを使用すると、すばらしいパフォーマンスが得られます。IPVSロードバランサーは900 Mbps / 150 kppsを超えています。これは、同じBroadcom bnx2チップセットをまだ使用している間です。

結論として：割り込み処理はうまくいくようで、2.6.38 / 3.0.xカーネルを使用したDebianのデフォルトは許容できるように見えます。

間違いなく、標準のDebianパッケージを使用できるように、Intel NICを使用したいと思います。非フリーのbnx2ファームウェアと戦うことは時間の浪費です。