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 でアプリケーションをスケジュールできなくなります。