【入門編】ソケットバッファサイズ(Send-Q/Recv-Q)の監視とバッファ溢れの検知 – トラブルシューティング＆ネットワーク運用監視実践ガイド

こんにちは！ネットワーク運用（NOC）の現場で、夜中の障害対応に汗を流してきたシニアエンジニアです。

皆さんは、Webサーバーやデータベースを運用していて「通信速度が急に落ちる」「特定の処理でタイムアウトする」といった経験はありませんか？ネットワークのトラブルは目に見えない分、どこで詰まっているのかを突き止めるのが本当に難しいものです。

今回は、そんな時に必ずと言っていいほどお世話になる、超重要コマンド ss（Socket Statistics）についてお話しします。特に Send-Q と Recv-Q という「通信の行列」に注目することで、現場の「なぜ？」を一瞬で解決する方法を伝授します。

—

まず、難しい技術用語を捨てて、身近な例えで考えてみましょう。

通信を「郵便物」、アプリケーションを「郵便局の窓口」と想像してください。
サーバーという建物の中には、外から届いた手紙を受け取るための「受け取りボックス（Recv-Q）」と、相手に返事を出そうと準備している「発送待ちボックス（Send-Q）」があります。

さて、ここからが本題です。もし窓口の職員（アプリケーション）が忙しすぎて手紙をさばききれなくなったらどうなるでしょうか？そう、カウンターの上（Recv-Q）に手紙が山積みになりますよね。これが、「通信が遅い」という現象の正体です。

—

まずは、サーバー上で ss コマンドを叩いてみましょう。

# -t: TCP接続を表示
# -n: ホスト名解決をせずIPアドレスで表示
# -l: リッスン（待ち受け）中のソケットを表示
ss -tnl

出力結果の中に Recv-Q と Send-Q という列が見えるはずです。

State  Recv-Q Send-Q  Local Address:Port  Peer Address:Port
LISTEN 0      128     0.0.0.0:80          0.0.0.0:*

この値がずっと 0 であれば、窓口は平和そのものです。しかし、ここが数字で埋まっている場合、要注意です。

Recv-Q に数字が溜まっているということは、「OSまではデータが届いているのに、アプリケーションがそれを引き取れていない」という状態です。

Send-Q に数字が溜まっているということは、「こちらから送信しようとしているが、相手（または経路）が受け取ってくれない」状態です。

—

「ずっと画面を監視するわけにもいかないよ！」という方に、現場でよく使う「異常をサクッと見つけるワンライナー」を紹介します。

# 1秒ごとに更新し、Recv-Q または Send-Q が 0 以外になっている接続を抽出
watch -n 1 "ss -nt | awk '\$2 > 0 || \$3 > 0'"

このコマンドを動かしておくだけで、「おっ、一瞬だけキューが跳ね上がったぞ！」という瞬間を逃さずキャッチできます。

もし「アプリケーションは正常なのに、通信が異常に増えてバッファが溢れる」という場合は、Linuxのシステム設定でバッファサイズを拡張する必要があるかもしれません。

以下の設定ファイル（/etc/sysctl.conf）で調整可能です。

# TCP受信バッファのデフォルトと最大値を拡張（単位はバイト）
net.core.rmem_default = 262144
net.core.rmem_max = 4194304

# 設定を反映させるコマンド
sysctl -p

*※ただし、闇雲に大きくすれば良いわけではありません。メモリーを大量に消費するため、まずは負荷の原因を特定することが先決です！*

—

現場でトラブルに直面すると、どうしても焦ってパッチを当てたくなります。ですが、まずは ss コマンドで「どこが詰まっているのか」を冷静に見極めてください。

「窓口（アプリ）が遅いのか？」それとも「外（ネットワーク）が混んでいるのか？」

この切り分けができるだけで、あなたのトラブルシューティング能力は格段に上がります。最初は難しく感じるかもしれませんが、パケットの流れを想像しながらコマンドを叩いていれば、必ず「あ、これはあそこの行列が原因だ！」と直感的にわかる日が来ますよ。

それでは、皆さんのサーバーが今日も平穏無事でありますように。また次回の記事でお会いしましょう！