ネットワーク系カーネルパラメータを変更する前に見るべき指標

Linux のネットワークトラブルや性能問題に直面すると、

• sysctl を触れば直るのでは？
• とりあえず tcp_* をチューニングしたい

と考えがちですが、指標を見ずにパラメータ変更するのは非常に危険です。

本記事では、

• ネットワーク系カーネルパラメータを変更する「前」に必ず確認すべき指標
• どんな状態なら変更を検討すべきか

を、実務目線で整理します。

なぜ「先に指標確認」が必要なのか

カーネルパラメータは、

• 原因を解決するもの
• 症状を悪化させるもの

の両面を持っています。

現象の正体を誤認したまま変更すると、

• 一時的に直ったように見える
• 別の問題を引き起こす

というケースが非常に多いです。

最優先で見るべき指標①：パケットロス

確認コマンド

ip -s link

以下を確認します。

• RX errors / dropped
• TX errors / dropped

この指標が示す意味

• ここで増加している → カーネル以前の問題
• NIC / MTU / 物理・仮想基盤の可能性が高い

この状態で tcp_wmem 等を変更しても意味はありません。

指標②：再送（retransmission）の有無

確認コマンド

netstat -s | grep -i retrans

再送が多い場合、

• 輻輳
• 遅延
• 途中経路の問題

が疑われます。

判断基準

• 再送が増えている → 変更検討余地あり
• 再送がほぼない → チューニング対象外

指標③：Send-Q / Recv-Q

確認コマンド

ss -lntp

ここで注目するのは、

• Send-Q が溜まり続けていないか
• Recv-Q が異常に大きくなっていないか

読み取り方

• Send-Q 増加 → 送信できていない
• Recv-Q 増加 → アプリが捌けていない

カーネルではなくアプリ側が原因の可能性も高い点に注意します。

指標④：CPU使用率と softirq

確認コマンド

mpstat -P ALL

または

top

見るポイント

• %soft が高くないか
• CPU idle は高いのに遅くないか

softirq が詰まっている場合、

• netdev_budget
• RPS/RFS

などを検討する余地があります。

指標⑤：アプリケーション側の状態

以下を必ず確認します。

• アプリのスレッド数
• accept backlog
• 処理遅延ログ

カーネルパラメータはアプリの設計ミスを補えません。

「変更すべき状態」と「触ってはいけない状態」

変更を検討してよい状態

• 再送が多い
• Send-Q が詰まる
• CPU / softirq がボトルネック

触ってはいけない状態

• 物理的なパケットロスがある
• アプリが処理できていない
• 原因不明のまま

よくある失敗例

• とりあえず tcp_tw_reuse を有効化
• 理由なく rmem/wmem を増やす
• 効果測定をしない

まとめ

• ネットワーク系 sysctl は「最後の一手」
• 指標を見れば触るべきかは判断できる
• 見ずに触るのが一番危険

カーネルパラメータ変更前に、

「今どこが詰まっているのか」を数字で説明できる状態

これができて初めて、チューニングは意味を持ちます。