Send-Q / Recv-Q が増え続ける時の見方

Linuxで通信トラブルを調査していると、次のような状況に遭遇することがあります。

• ss で ESTABLISHED になっている
• Send-Q / Recv-Q の数値が増え続けている
• 通信が遅い・返ってこない

この状態は、

「通信は成立しているが、データが滞留している」

ことを意味します。

本記事では、

• Send-Q / Recv-Q の正しい意味
• 増え続ける時に何が起きているのか
• 原因ごとの切り分けと対処法
• どこまで直れば解決と判断できるか

を、実務目線で解説します。

Send-Q / Recv-Q とは何か

ss や netstat の出力に表示される、

• Send-Q
• Recv-Q

は、それぞれ以下を意味します。

• Send-Q：送信待ちのデータ量
• Recv-Q：受信したが未処理のデータ量

重要なのは、

「キューがある＝異常」ではない

という点です。

問題になるのは、

• 数値が増え続ける
• 時間が経っても減らない

場合です。

確認方法：Send-Q / Recv-Q の基本的な見方

ss -antp

以下のように判断します。

• 一時的に増えてすぐ減る → 正常
• 増え続けて張り付く → 異常

解決の判断基準：
Send-Q / Recv-Q が一定以下に戻り、通信が流れる

原因1：相手側がデータを受信・処理できていない

Send-Q が増え続ける場合、

「こちらは送っているが、相手が受け取れていない」

状態です。

• 相手アプリが高負荷
• 相手側で処理が詰まっている
• ネットワーク途中で輻輳

確認方法

tcpdump -nn host 相手IP

ACK が遅い／返ってこない場合、 相手側要因の可能性が高いです。

原因2：自分側アプリが受信処理できていない

Recv-Q が増え続ける場合、

「受信はしているが、アプリが読めていない」

状態です。

• スレッド枯渇
• ブロッキングI/O
• アプリ内部ロック

確認

Recv-Q が増え、 CPU idle が高い場合は、 アプリの待ち状態を疑います。

原因3：MTU不一致・フラグメント問題

MTU 不一致があると、

• 小さい通信は流れる
• 大きいデータで詰まる

結果として、 Send-Q が溜まり続けます。

確認

ping -M do -s 1472 相手IP

解決の判断基準：
フラグメントなしで疎通できる

原因4：ネットワーク帯域・輻輳

帯域不足や輻輳があると、

• 送信はできる
• 到達が遅れる

ため、Send-Q が増えます。

確認

ss -i

再送（retrans）が多い場合、 ネットワーク要因を疑います。

原因5：ウィンドウサイズ・カーネル制限

以下の制限でも、 キューは詰まります。

• 送受信バッファ不足
• ウィンドウサイズが小さい

高スループット環境では特に注意が必要です。

実務的な切り分けフロー

1. Send-Q / Recv-Q のどちらが増えているか
2. tcpdump で ACK の挙動を確認
3. 相手側 or 自分側かを切り分け
4. MTU・帯域・アプリ状態を確認

まとめ

• Send-Q＝送れない
• Recv-Q＝処理できない
• 増え続けるのは「待ち」が発生している証拠

Send-Q / Recv-Q を見た時は、

「どこでデータが止まっているか」

を考えることで、最短で原因に辿り着けます。