Сервер тормозит: с чего начать диагностику

Когда звонят со словами «сервер тормозит», первое желание — сразу что-нибудь подкрутить. Так делать не надо. Сначала нужно понять, во что именно он упирается: в процессор, память, диск или сеть. Ниже порядок, по которому я иду сам. В большинстве случаев он приводит к причине минут за 5–10.

Часть команд требует root (sudo), а iostat, sar, iotop, iftop, nethogs и btop нужно ставить отдельно — в Debian и Ubuntu это пакеты sysstat, iotop, iftop, nethogs, btop. Я ставлю их на серверы заранее: на машине, которая уже еле шевелится, даже установка пакета превращается в ожидание.

1. Быстрый обзор

uptime                # load average за 1, 5 и 15 минут
nproc                 # количество ядер — для сравнения с load average
free -h               # память и swap
df -h                 # свободное место на дисках
df -i                 # свободные inode — место может «кончиться» и при пустом диске
sudo dmesg -T | tail -50   # ошибки ядра, OOM-killer, проблемы с дисками

На что я смотрю в первую очередь:

Load average заметно выше числа ядер. Процессы стоят в очереди на CPU или ждут ввода-вывода.
Мало памяти в колонке available. Именно available, а не free. Маленькое free — это нормально: Linux забирает свободную память под кэш и отдаёт её по первому требованию.
Активно используется swap. Оперативки не хватает.
Диск заполнен на 90% и больше. От этого страдают базы, логи и временные файлы.

2. Кто ест ресурсы

top                              # или htop / btop; сортировка в top: P — по CPU, M — по памяти
ps aux --sort=-%cpu | head -15   # топ процессов по CPU
ps aux --sort=-%mem | head -15   # топ процессов по памяти
vmstat 1 5                       # общая картина с интервалом в секунду

btop — всё на одном экране

В последнее время я всё чаще открываю btop вместо top и htop. Он показывает сразу четыре блока: процессор с графиком по каждому ядру, память и диски, сеть и список процессов.

sudo apt install btop   # Debian 12, Ubuntu 22.04 и новее
btop

Чем он мне удобен при разборе:

Сразу видны диски и сеть. top и htop по умолчанию показывают только процессор и память, а btop — ещё скорость чтения и записи по каждому диску и трафик по интерфейсам. Перегруженный ресурс часто видно с первого взгляда, без iostat и iftop.
Графики, а не только цифры. Видно, как нагрузка менялась последние минуты, и короткий всплеск легко отличить от постоянной перегрузки.
С процессами можно работать прямо из интерфейса. Фильтр по имени (f), дерево процессов (e), сортировка, отправка сигнала или завершение процесса (k), в том числе мышью.
Лишние блоки можно скрыть. Клавиши 1–4 включают и выключают процессор, память, сеть и процессы. Удобно, когда окно терминала маленькое.

Минусы тоже есть. По умолчанию btop не установлен, ресурсов ест чуть больше, чем top, и хочет терминал с UTF-8: в старой консоли или через медленный канал графики выглядят плохо. Так что top знать всё равно нужно — он есть на любом сервере.

Главные колонки vmstat (первую строку пропускайте, там средние значения с момента загрузки):

Колонка	Что означает	Тревожный признак
`r`	процессы в очереди на CPU	стабильно больше числа ядер
`b`	процессы в ожидании I/O	постоянно больше нуля
`wa`	время ожидания диска, %	высокое значение — узкое место в диске
`si` / `so`	обмен со swap	регулярно ненулевые значения
`st`	время, отнятое гипервизором (steal)	заметно больше нуля на ВМ — тормозит хост, а не сервер

3. Диск — самый частый виновник

iostat -xz 1 5   # пакет sysstat
sudo iotop -o    # какие процессы читают и пишут на диск

Если %util под 100, а await высокий, диск не справляется. Для SSD и NVMe я смотрю прежде всего на await: они обрабатывают запросы параллельно, и %util у них может показывать 100% при приличном запасе. Типичная картина дисковой проблемы: в строке %Cpu(s) у top высокое wa, а сам процессор при этом скучает. Тогда почти наверняка дело в дисках.

4. Память и swap

Если в free -h мало available, а в vmstat постоянно ненулевые si/so, сервер тормозит из-за свопинга.
Заодно проверяю, не прибивал ли OOM-killer процессы:

sudo dmesg -T | grep -i oom

5. Сеть

ss -s                                          # сводка по соединениям
ss -tan | awk 'NR>1 {print $1}' | sort | uniq -c   # состояния TCP
sar -n DEV 1 5                                 # трафик по интерфейсам (sysstat)
sudo iftop                                     # кто загружает канал
sudo nethogs                                   # трафик по процессам

Если соединений в состояниях TIME_WAIT, CLOSE_WAIT или SYN-RECV очень много, нужно разбираться с приложением или проверить, не идёт ли на сервер сетевая атака.

6. Приложения и логи

journalctl -p err -b                          # ошибки с момента загрузки
journalctl -u <сервис> --since "1 hour ago"   # логи конкретной службы за последний час

Смотрю логи приложения и веб-сервера (nginx, Apache, Java-сервисы): ошибки, таймауты, медленные ответы.
Для баз данных включаю журнал медленных запросов (slow_query_log в MySQL, log_min_duration_statement в PostgreSQL) и смотрю блокировки и активные запросы.
И обязательно спрашиваю, что менялось в последнее время: деплой, обновление пакетов, новые задачи в cron, рост трафика. По моему опыту, причина очень часто именно там.

Если сервер на Windows

Диспетчер задач, вкладка «Производительность»: CPU, память, диск и сеть в реальном времени.
Монитор ресурсов (resmon): какие процессы грузят диск и сеть, очереди к дискам.
Просмотр событий (eventvwr): ошибки в журналах «Система» и «Приложение».
Системный монитор (perfmon): долгий сбор счётчиков, если проблема появляется время от времени.

Коротко: мой порядок

Выяснить, когда начались тормоза и что менялось незадолго до этого.
Посмотреть uptime, top, free -h и iostat. Обычно этого хватает, чтобы понять, какой ресурс перегружен.
Найти процесс-виновника и разобраться с его логами.
И только потом что-то менять в настройках. Оптимизация вслепую чаще добавляет новых проблем, чем решает старые.