Сервер тормозит: команды первой минуты

Сервер тормозит: что делать в первую минуту

Тормозит сервер. Неважно, что на нём работает — база данных, очередь сообщений, бэкенд или всё вместе. Первая реакция — перезапустить и надеяться, что проблема исчезнет сама собой. Но если тормоза вызваны нехваткой ресурсов, перезагрузка только отложит диагностику. А когда сервер снова начнёт тормозить, данных о причине уже не будет.

Начинать нужно с того, чтобы понять, какого ресурса не хватает: процессора, памяти, диска или сети. Без этого любая команда — это гадание. Разберём, что проверять в первую минуту, что означают эти метрики и почему они не всегда говорят то, что кажется на первый взгляд.

Чего не хватает: четыре ресурса и как их проверить

Когда сервер тормозит, проблема всегда сводится к нехватке одного из четырёх ресурсов:

1. Процессор — не успевает обрабатывать запросы, процессы стоят в очереди.
2. Память — оперативной не хватает, система начинает сбрасывать страницы на диск.
3. Диск — медленный ввод-вывод, запросы встают в очередь.
4. Сеть — узкое место в соединениях или пропускной способности.

Каждый ресурс проверяется своей командой. Но прежде чем запускать их, нужно понять, что именно искать — иначе цифры останутся просто цифрами.

Процессор: средняя нагрузка и распределение времени

Первая команда, которую запускают при тормозах, — uptime. Она показывает среднюю нагрузку на систему за последние одну, пять и пятнадцать минут:

$ uptime
14:23:34 up 2 days,  3:45,  2 users,  load average: 12.34, 8.76, 4.56

Числа после load average — это среднее количество процессов, которые либо выполняются, либо ждут процессора. Но сами по себе они ничего не значат. Чтобы понять, насколько система загружена, нужно сравнить их с числом ядер процессора.

Если нагрузка превышает количество ядер в несколько раз, процессор не справляется с задачами. Но даже в этом случае важно посмотреть, на что именно тратится процессорное время. Для этого есть команда top или её более удобный аналог htop:

$ top
%Cpu(s):  5.2 us,  1.3 sy,  0.0 ni, 93.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

Вот что означают эти поля:

• us (user) — время, потраченное на выполнение пользовательских процессов. Если это значение высокое, значит, какое-то приложение активно использует процессор.
• sy (system) — время на системные вызовы. Высокое значение может говорить о проблемах с драйверами или ядром.
• id (idle) — время простоя. Если оно низкое, процессор занят.
• wa (iowait) — время ожидания диска. Если это значение высокое, проблема не в процессоре, а в диске.

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

Память: почему «мало свободной» — это нормально

С памятью всё сложнее. Многие смотрят на вывод free -m и пугаются, когда видят мало свободной памяти:

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           7820        6543         234         123        1042        1043
Swap:          2048        1234         814

Но на самом деле, мало свободной памяти — это нормально. Linux использует свободную память для кэша и буферов, чтобы ускорить работу с диском. Важнее смотреть на колонку available — сколько памяти доступно для запуска новых процессов без сброса кэша на диск.

Если available близко к нулю, а used заполняет почти всю память, система начинает использовать swap. Это и есть настоящая проблема: когда оперативная память заканчивается, процессы начинают сбрасываться на диск, и всё тормозит. Swap — это медленно, и если система активно его использует, производительность падает в разы.

Диск: ожидание ввода-вывода и очереди

Если процессор простаивает (id высокий), а система всё равно тормозит, проблема может быть в диске. Проверить это можно с помощью iostat из пакета sysstat:

$ iostat -x 1
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.23    0.00    1.34   20.45    0.00   73.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
nvme0n1           0.00     0.00  200.00  100.00 12800.00  4096.00   112.00     0.50    1.67    1.00    3.00   0.67  20.00

Главные метрики здесь:

• %iowait — время ожидания диска. Если это значение высокое, процессор тратит много времени на ожидание завершения операций ввода-вывода.
• await — среднее время ожидания ввода-вывода. Если оно высокое, диск не справляется с нагрузкой.
• %util — процент времени, когда диск был занят. Если это значение близко к пределу, диск работает на максимуме.

Если %iowait высокий, а %util близок к пределу, диск не справляется с нагрузкой. Это может быть из-за медленного диска, большого количества одновременных запросов или проблем с очередью. В этом случае стоит проверить, какие процессы активно используют диск, с помощью iotop.

Сеть: число соединений и пропускная способность

Сеть редко бывает узким местом, но если сервер тормозит из-за большого количества соединений, это можно проверить с помощью ss или netstat:

$ ss -s
Total: 1234 (kernel 2345)
TCP:   4567 (estab 1234, closed 3333, orphaned 0, synrecv 0, timewait 0/0), ports 0

Если число установленных соединений (estab) близко к максимальному лимиту системы, сервер может не справляться с нагрузкой. Также стоит проверить пропускную способность с помощью iftop или nload. Если сеть действительно является узким местом, можно увидеть, что трафик упирается в предел канала.

Когда виноват не сам сервер

Даже если все метрики в порядке, проблема может быть не в сервере. Вот несколько распространённых причин, почему тормозит не сам сервер, а что-то вокруг него:

1. Соседний контейнер — если сервер работает в виртуализации или контейнерах, соседний процесс может съедать ресурсы. Например, если на одном хосте запущено несколько виртуальных машин, одна из них может забирать все ресурсы процессора или диска.
2. Ограничения по ресурсам — например, если контейнер ограничен по CPU или памяти, он может тормозить даже если на хосте ресурсов достаточно. В этом случае нужно проверять не только метрики внутри контейнера, но и на уровне хоста.
3. Медленный сосед по диску — если на одном физическом диске работает несколько виртуальных машин, одна из них может забивать очередь запросов. В этом случае диск будет тормозить для всех.

Чтобы проверить это, нужно посмотреть нагрузку на уровне хоста, а не внутри контейнера или виртуальной машины. Например, если внутри контейнера iowait высокий, но на хосте он низкий, проблема может быть в соседнем контейнере.

Что записать до перезапуска

Если сервер тормозит, а причина неочевидна, важно сохранить данные до перезапуска. Иначе после рестарта всё пропадёт, и диагностика станет невозможной.

Вот что нужно записать:

1. Вывод top или htop — какие процессы съедают ресурсы. Это поможет понять, какое приложение вызывает проблему.
2. Вывод dmesg — системные сообщения об ошибках. Здесь могут быть подсказки о проблемах с железом или драйверами.
3. Логи приложений — если тормозит конкретный сервис, его логи могут содержать подсказки. Например, если база данных тормозит, стоит посмотреть её логи на предмет медленных запросов.
4. Метрики диска — iostat -x и df -h для проверки свободного места. Если диск заполнен, это может быть причиной тормозов.
5. Метрики сети — ss -s и iftop для проверки соединений. Если сеть перегружена, это может быть причиной проблем.

Эти данные помогут понять, что произошло, даже если сервер перезагрузится.

Тупик: перезагрузить и надеяться

Самый распространённый тупик — перезагрузить сервер и надеяться, что проблема исчезнет. Если тормоза вызваны нехваткой ресурсов, перезагрузка только отложит диагностику. А когда сервер снова затормозит, данных о причине уже не будет.

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

Позиция редакции

Тормоза сервера — это всегда нехватка одного из четырёх ресурсов: процессора, памяти, диска или сети. Начинать диагностику нужно с того, чтобы понять, какого ресурса не хватает, а не с перезагрузки или гадания на кофейной гуще.

Но есть одно условие, при котором этот подход не сработает: если проблема не в ресурсах, а в логике работы приложения. Например, если сервис завис на мьютексе или бесконечном цикле, метрики ресурсов могут быть в порядке. В этом случае нужно смотреть логи и трассировки приложения, а не только системные метрики.

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