Разбор вывода ss на нагруженной машине

14 апреля 2026

ss -tan при десятках тысяч соединений выдаёт простыню. Порядок, которым я её обычно разбираю.

Гистограмма состояний

ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c | sort -rn

Тысячи TIME-WAIT на сервере означают, что соединения закрывает он сам. Для клиента с короткими соединениями это штатная картина.

CLOSE-WAIT копится, когда приложение не закрывает сокет после закрытия с той стороны. Искать в коде.

SYN-RECV в заметном количестве бывает при неразгребаемой очереди accept и при сканировании.

Очереди слушающих сокетов

У LISTEN колонки Recv-Q и Send-Q означают текущую длину очереди accept и её максимум:

ss -ltn
State  Recv-Q Send-Q Local Address:Port
LISTEN 0      511          0.0.0.0:80
LISTEN 128    128          0.0.0.0:8080

Во второй строке очередь заполнена. Дальше ядро начнёт отбрасывать соединения. В мониторинге это выглядит как таймауты у клиентов при чистом логе приложения.

Кто держит соединения

ss -tan state established | awk '{print $5}' | \
  sed 's/:[0-9]*$//' | sort | uniq -c | sort -rn | head

Один адрес с несоразмерной долей обычно означает клиента без пула соединений либо балансировщик, переставший распределять нагрузку.

Внутренности сокета

ss -tin добавляет rtt, cwnd и счётчики повторных передач. Полезно, когда уже известно, какое соединение интересует.

ss читает netlink. netstat разбирает /proc/net/tcp, и на сотнях тысяч сокетов разница во времени выполнения выходит на порядок. Если в скриптах мониторинга остался netstat, замена снимает заметную нагрузку с ноды.