Linux: десять команд, когда «сервер тормозит»

Жалоба почти всегда одна и та же — «всё медленно». Задача не найти причину вообще, а сузить область за минуты. Ниже порядок, в котором я реально смотрю машину: сначала то, что отвечает на вопрос «что именно занято», и только потом детали.

1. Загрузка: uptime и средняя

Начинаю с одного числа — средней загрузки. Оно не говорит «процессор занят», оно говорит «сколько задач ждут ресурс».

$ uptime
 14:22:07 up 21 days,  3:04,  1 user,  load average: 12.04, 8.71, 4.02

Три числа — за 1, 5 и 15 минут. Здесь видно нарастание: 4 → 8 → 12. Если бы было 12 → 12 → 12 — проблема старая и стабильная, а не всплеск.

2. Кто ест процессор

$ top -b -n 1 -o %CPU | head -20
$ ps aux --sort=-%cpu | head -12

top в пакетном режиме (-b -n 1) удобен тем, что его можно прокрутить и вставить в тикет. Обращаю внимание не только на %CPU, но и на TIME+: процесс с низким текущим CPU, но большим суммарным временем — фоновый прожорливый задачник.

Если виноват не процессор, а ожидание диска, в top это видно как высокий wa в строке Cpu(s). Тогда иду в раздел про диск.

3. Память: смотреть не только free

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           15Gi       11.2Gi       0.3Gi       310Mi       3.8Gi       3.5Gi
Swap:          2.0Gi       1.9Gi       0.1Gi

Столбец free вводит в заблуждение — Linux отдаёт свободную память под кэш. Смотрю на available: 3.5Gi из 15Gi — уже тесновато.

Своп почти полный — это плохой знак. Когда система начинает активно свопить, всё тормозит независимо от загрузки CPU. Проверяю, кто толкает память:

$ ps aux --sort=-rss | head -12
$ grep -E '^(VmSwap|VmRSS)' /proc/<PID>/status

Если своп растёт при свободной памяти — проверьте vm.swappiness. Значение 60 по умолчанию агрессивно для серверов; 10–20 обычно достаточно.

4. Диск: нехватка места и ожидание

Две разные проблемы, которые часто путают.

Место кончилось:

$ df -h
$ du -xh --max-depth=2 /var 2>/dev/null | sort -h | tail -15

-x в du не даст залезать на смонтированные разделы — иначе сводка по /var вдруг включает в себя целый бэкап-диск.

Диск не успевает:

$ iostat -x 1 3
$ vmstat 1 5

Ключевой столбец в iostat — %util и await. На NVMe %util может быть 100% при остаточной очереди — там смотрю именно на await. В vmstat интересует столбец wa — доля времени ядра в ожидании ввода-вывода.

5. Сеть и соединения

$ ss -s
$ ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn
$ cat /proc/net/sockstat

Если ss -s показывает тысячи TIME-WAIT — обычно это норма для нагруженного HTTP-сервера. А вот рост SYN-RECV и CLOSE-WAIT — уже повод копать: первый намекает на незавершённое рукопожатие, второй — на приложение, которое не закрывает соединения.

Пакетные потери и ретраи смотрю так:

$ nstat -az | grep -E 'TcpRetransSegs|TcpExtListenDrop|UdpInErrors'
$ ss -tan state time-wait | wc -l

6. Дескрипторы и «пропал» процесс

Иногда процесс жив, но ничего не делает — уперся в лимит открытых файлов.

$ ulimit -n
$ ls /proc/<PID>/fd | wc -l
$ journalctl -u <service> --since "1 hour ago" | grep -i "too many open files"

И последняя команда, когда всё остальное молчит — что реально происходило с машиной в момент проблем:

$ sar -u -r -q -n DEV 1 1      # если sysstat установлен
$ journalctl --since "30 min ago" -p warning

sysstat стоит поставить заранее: без него через полчаса после инцидента спрашивать уже нечего.

Если после этих шести шагов картина не сложилась — почти наверняка проблема не в ресурсах машины, а на уровне приложения или внешнего сервиса. Тогда смотрю не метрики, а логи и трассировку запросов.