Linux のチューニングで頻繁に登場するのが
net.core.somaxconn
ですが、
- なぜ必要なのか
- いつ変更すべきか
- 変更しないと何が起きるのか
を正しく理解しないまま、
「接続が多いから上げる」
という対応は非常に危険です。
本記事では、
- somaxconn の役割
- 変更が必要な具体条件
- 判断に使う指標
を実務目線で整理します。
目次
net.core.somaxconn とは何か
net.core.somaxconn は、
accept キューの最大長の上限値
を決めるカーネルパラメータです。
アプリケーションが
listen(fd, backlog)を指定しても、
最終的に somaxconn が上限として適用
されます。
somaxconn が関係する接続フロー
TCP 接続確立は以下の順で進みます。
- SYN を受信
- SYN-ACK を返却
- ACK を受信
- accept キューに格納
- アプリが accept()
somaxconn は
④の accept キューの最大数
に影響します。
変更を検討すべき代表的な症状
- 接続が時々失敗する
- アクセス集中時だけエラーが出る
- listen overflow のログが出る
ただし、
これだけで somaxconn を疑うのは早計
です。
判断指標①：accept キューの溢れ
確認コマンド
netstat -s | grep -i listen注目ポイント
- listen queue overflow
- listen queue drops
これが増加している場合、
somaxconn 不足の可能性
があります。
判断指標②：SYN-RECV ではなく ESTABLISHED が多いか
確認コマンド
ss -ant読み取り
- SYN-RECV が多い → somaxconn 以前の問題
- ESTABLISHED が多い → accept 側の滞留
somaxconn が関係するのは
接続確立後
です。
判断指標③：アプリケーションの accept 処理速度
somaxconn を上げる前に必ず確認します。
- accept() が詰まっていないか
- ワーカースレッド不足ではないか
アプリが遅いだけなのに
somaxconn を上げると、
- 遅延が隠れる
- 障害が長時間化
します。
変更すべき明確な条件
以下をすべて満たす場合のみ、
somaxconn の変更を検討
します。
- listen overflow が発生している
- SYN-RECV が溜まっていない
- アプリの accept が正常
- 一時的な接続集中が原因
変更例
現在値の確認
sysctl net.core.somaxconn一時変更
sysctl -w net.core.somaxconn=1024永続化
/etc/sysctl.conf
net.core.somaxconn = 1024段階的に上げるのが基本です。
変更後に必ず確認すること
- listen overflow が止まったか
- レイテンシが悪化していないか
- アプリ応答が遅れていないか
やってはいけない対応
- 根拠なく 65535 にする
- 他のキューを見ない
- 攻撃と混同する
「解決した」と判断する基準
- 接続失敗が消える
- listen overflow が増えない
- 負荷時も応答が安定
まとめ
- somaxconn は accept キューの上限
- 変更には明確な条件がある
- アプリ性能確認が最優先
somaxconn は
「最後に触るパラメータ」
これを守るだけで、
不要な障害を確実に減らせます。
あわせて読みたい
SYN flood と負荷増大の見分け方
Linux サーバで、 SYN-RECV が大量に溜まっている 新規接続が遅い サーバ負荷が上がっている この状態を見ると、 「SYN flood 攻撃では？」 と疑いがちです。 しかし実…
あわせて読みたい
Linuxでacceptキューが溢れる時の見方
Linux サーバで、 接続が遅い ときどき接続エラーが出る SYN-RECV が溜まっている といった状況を見ると、 acceptキューが溢れているのでは？ と疑うことになります。 …
あわせて読みたい
net.ipv4.tcp_max_syn_backlog を触る前の判断基準
Linux のネットワークチューニングで、 SYN-RECV が溜まっている 接続が遅い・不安定 といった状況を見ると、 tcp_max_syn_backlog を増やせば解決するのでは？ と考え…