tcp_wmem / tcp_rmem を変更すべき具体条件

URLをコピーしました！

Linux のネットワークチューニングで必ず話題に上がるのが、

tcp_wmem
tcp_rmem

ですが、

とりあえず増やす
高速化するらしいから変更する

という対応は ほぼ失敗します。

本記事では、

tcp_wmem / rmem が何を制御しているのか
変更すべき「具体的な状態」
変更してはいけないケース

を、実務で判断できるレベルまで落とし込みます。

tcp_wmem / tcp_rmem の役割を正しく理解する

tcp_wmem（送信バッファ）

アプリ → TCP → NIC に渡すまでの 送信側バッファサイズです。

tcp_rmem（受信バッファ）

NIC → TCP → アプリに渡すまでの 受信側バッファサイズです。

いずれも以下の3値構成です。

min default max

常に max が使われるわけではありません。

変更を検討すべき前提条件

まず以下が前提です。

パケットロスが発生していない
NIC エラーが出ていない
MTU 不一致がない

ここを満たしていない場合、変更しても意味がありません。

tcp_wmem を変更すべき具体条件

条件①：Send-Q が継続的に溜まる

確認コマンド

ss -nt

以下の状態が続く場合です。

Send-Q が大きい値で張り付く
通信は確立している

送信はしたいが、送り切れていない状態です。

条件②：再送が発生していない

netstat -s | grep -i retrans

再送が多い場合は、

輻輳
経路問題

が原因であり、wmem増加は逆効果になります。

判断

Send-Q 増加
再送ほぼなし

→ tcp_wmem の max 増加を検討

tcp_rmem を変更すべき具体条件

条件①：Recv-Q が増え続ける

確認コマンド

ss -nt

Recv-Q が溜まる場合、

受信はできている
アプリが読み切れていない

状態です。

条件②：CPU idle が十分ある

CPU に余裕があるのに Recv-Q が溜まる場合、

受信バッファ不足

の可能性があります。

判断

Recv-Q 増加
CPU idle 高

→ tcp_rmem の max 増加を検討

変更してはいけない典型ケース

再送が多い
SYN-RECV が溜まっている
NIC error / drop がある

この場合、

バッファを増やす＝問題を隠すだけ

になります。

変更例（検証前提）

sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"

必ず一時変更 → 効果確認 → 永続化の順で行います。

変更後に必ず確認する指標

Send-Q / Recv-Q の変化
再送数の増減
レスポンス改善の有無

改善しなければ元に戻す判断も重要です。

よくある誤解

増やせば速くなる → ×
max を大きくすれば安心 → ×
チューニング＝正義 → ×

まとめ

tcp_wmem / rmem は「条件付きチューニング」
Send-Q / Recv-Q が判断軸
再送があるなら触らない

tcp_wmem / rmem を触るべきか迷ったら、

「どこで詰まっているか説明できるか」

これが判断できないうちは、変更すべきではありません。