8.4. 一般的なキュー/フレーム損失問題の解決
フレーム損失の理由で圧倒的に多いのは、queue overrun です。カーネルがキューの長さを制限し、場合によってはキューが排出するよりも早くいっぱいになってしまいます。これが長期間発生すると、フレームのドロップが始まります。
図8.1「ネットワーク受信パスの図」 にあるように、受信パスには、NIC ハードウェアバッファーとソケットキューという、2 つの主要なキューがあります。両方のキューで、queue overrun から保護するための設定が必要です。
8.4.1. NIC ハードウェアバッファー
NIC はフレームでハードウェアバッファーを満たします。すると、バッファーは
softirq で排出を行います。これは NIC が割り込みでアサートするものです。このキューのステータスを調べるには、以下のコマンドを使います。
ethtool -S ethX
ethX を NIC の対応するデバイス名で置き換えます。こうすることで、ethX 内でいくつのフレームがドロップされたかが表示されます。ドロップが発生する理由の多くは、キューがフレームを保存するバッファースペースを使い切ってしまうためです。
この問題に対処するには、以下の方法があります。
- 入力トラフィック
- queue overrun は、入力トラフィックを遅らせることで防ぐことができます。これは、フィルタリングで統合マルチキャストグループの数を減らし、ブロードキャストトラフィックを抑えることで実現できます。
- キューの長さ
- 別の方法では、キューの長さを伸ばすこともできます。これは、ドライバーが許可する最高値まで指定のキューでバッファー数を増やすというものです。これを行うには、以下のように
ethXコマンドのrx/txリングパラメーターを編集します。ethtool --set-ring ethX
上記のコマンドにrxもしくはtxの値を追加します。詳細に関してはman ethtoolを参照してください。 - Device weight
- また、キューからの排出率を高めることもできます。これを行うには、NIC の device weight をそれに応じて調整します。この属性は、
softirqコンテキストが CPU を放棄して再スケジュールを行う前に NIC が受信可能なフレームの最大数を指します。これは、/proc/sys/net/core/dev_weight変数で制御されます。
ほとんどの管理者は 3 番目のオプションを選ぶ傾向がありますが、このオプションの実行で影響が出ることに留意してください。1 回の反復で NIC から受信可能なフレーム数を増やすと CPU サイクルが増えることになり、この間はその CPU でアプリケーションをスケジュールできなくなります。
