Linuxでacceptキューが溢れる時の見方

Linux サーバで、

• 接続が遅い
• ときどき接続エラーが出る
• SYN-RECV が溜まっている

といった状況を見ると、

acceptキューが溢れているのでは？

と疑うことになります。

しかし accept キューは 1 種類ではなく、

どのキューが溢れているかを誤ると対処を間違えます。

本記事では、

• accept キューの正体
• 溢れているかの確認方法
• 原因別の正しい対処

を実務レベルで整理します。

acceptキューは2段構えで存在する

Linux の TCP 接続には、

• SYNキュー（半接続キュー）
• acceptキュー（完全接続キュー）

の2段階があります。

SYNキュー

• 状態：SYN-RECV
• 制御：tcp_max_syn_backlog

acceptキュー

• 3-way handshake 完了後
• アプリの accept 待ち
• 制御：somaxconn / listen backlog

どちらが詰まっているかで対処は全く異なります。

SYNキューが溢れている時の見方

確認方法

ss -ant | grep SYN-RECV | wc -l

特徴

• SYN-RECV が大量に存在
• 時間が経っても減らない

判断

• 一時的 → backlog 調整検討
• 常時大量 → ネットワーク / DoS 疑い

acceptキューが溢れている時の見方

確認方法

ss -lnt

以下を確認します。

• Recv-Q が大きい
• LISTEN 状態で張り付いている

これは

接続は確立したがアプリが accept できていない

状態です。

acceptキューが溢れる主な原因

原因①：アプリの accept 処理が遅い

• シングルスレッド
• 処理待ちが長い

この場合、

カーネル設定では解決しません。

原因②：listen backlog が小さい

アプリ側で指定している

listen(fd, backlog)

が小さいケースです。

somaxconn より小さい値が使われます。

原因③：somaxconn が小さい

カーネル側の上限です。

sysctl net.core.somaxconn

listen backlog が somaxconn を超えても、

実際は somaxconn に丸められます。

正しい切り分け手順

1. SYN-RECV の有無を確認
2. LISTEN の Recv-Q を確認
3. アプリの accept 性能確認
4. backlog / somaxconn の関係確認

対処方法まとめ

SYNキューが原因の場合

• tcp_max_syn_backlog の検討
• ネットワーク品質確認

acceptキューが原因の場合

• アプリのスレッド増加
• listen backlog 見直し
• somaxconn 調整

「解決した」と判断する基準

• SYN-RECV が溜まり続けない
• LISTEN の Recv-Q が減少
• 接続エラーが解消

よくある誤解

• SYN-RECV＝acceptキュー → ×
• somaxconn を増やせば速くなる → ×
• とりあえず backlog 増加 → ×

まとめ

• acceptキューは2種類ある
• 溢れている場所を見誤らない
• アプリが原因のケースが非常に多い

acceptキューが溢れていると感じたら、

まず「どのキューか」を特定する

これが最短で正しい対処につながります。