Как диагностировать тормоза Linux-сервера без перезагрузки вслепую
Когда Linux-сервер начинает работать заметно медленнее, это быстро превращается в общую проблему: команды выполняются с задержкой, веб-сайт открывается десятки секунд, а пользователи и коллеги требуют немедленного объяснения. Первая реакция неопытного администратора часто предсказуема - перезагрузить систему. Иногда это действительно временно возвращает сервер к нормальной работе, но причины сбоя при этом остаются неизвестными. Через некоторое время ситуация повторяется.
Гораздо надежнее провести первичную диагностику Linux сервера прямо во время неполадки. В большинстве случаев источник замедления связан с одним из четырех ресурсов: процессором, оперативной памятью, дисковой подсистемой или сетью. Задача администратора - определить, какой именно компонент стал узким местом, и только после этого принимать решение о дальнейших действиях.
С чего начать проверку
Первый инструмент для оперативного анализа - команда `top`:
```bash
top
```
В верхней части экрана отображаются средняя нагрузка и состояние процессора. Показатель `load average` содержит значения за последние 1, 5 и 15 минут. Их необходимо сопоставлять с числом ядер: например, значение 4.0 на четырехъядерной машине примерно соответствует полной загрузке вычислительных ресурсов.
Особое внимание стоит уделить следующим показателям:
- `us` - время, затраченное на пользовательские процессы;
- `sy` - нагрузка, связанная с операциями ядра;
- `wa` - ожидание дисковых операций;
- `%CPU` в списке процессов - позволяет быстро обнаружить наиболее "прожорливое" приложение.
Если сумма `us` и `sy` долго держится выше 80-90%, процессор работает на пределе. Высокий `wa`, особенно выше 10-20%, чаще говорит уже не о нехватке CPU, а о проблемах с диском.
Более удобной альтернативой считается `htop`:
```bash
htop
```
Утилита показывает загрузку каждого ядра отдельно, визуализирует потребление памяти, отображает дерево процессов и позволяет завершить зависшую задачу без ручного запоминания PID. Для подробного подхода к анализу производительности Linux сервера такие средства особенно полезны на первом этапе.
Проверка оперативной памяти
Нехватка RAM часто становится причиной каскадного замедления. Когда физическая память заканчивается, ядро начинает переносить данные в swap - область на диске, которая значительно медленнее оперативной памяти.
Быструю оценку можно получить командой:
```bash
free -h
```
Тревожными признаками будут почти нулевое значение `free`, показатель `available` менее 10% от общего объема RAM и заметное использование swap. Сам факт наличия занятого swap еще не всегда означает проблему: Linux может сохранять там давно не используемые страницы. Важнее понять, идет ли активный обмен данными.
Для этого подойдет:
```bash
vmstat 2 5
```
Команда выполнит пять измерений с интервалом в две секунды. В колонках `si` и `so` отображаются операции загрузки страниц из swap и выгрузки в него. Если оба показателя стабильно отличаются от нуля, системе, вероятно, не хватает памяти. Параметр `r` показывает очередь процессов, ожидающих выполнения. Приблизительное правило - она не должна длительно превышать удвоенное число ядер.
Анализ дисковой подсистемы
Диск может стать узким местом даже тогда, когда процессор почти свободен. Это происходит при интенсивной записи логов, работе баз данных, резервном копировании, массовой обработке файлов или деградации накопителя.
Чтобы увидеть процессы, активно обращающиеся к диску, используется `iotop`:
```bash
sudo iotop -o
```
Ключ `-o` оставляет на экране только задачи с текущими операциями ввода-вывода. В первую очередь проверяйте значения `DISK READ`, `DISK WRITE` и процент ожидания I/O.
Общую картину дает `iostat`:
```bash
sudo iostat -x 1 5
```
Ключевые поля:
- `util` - доля времени, когда устройство занято; значения выше 80-90% указывают на перегрузку;
- `await` - среднее время ожидания операции в миллисекундах; более 20-30 мс может говорить о медленном накопителе или очереди запросов;
- `r/s` и `w/s` - число операций чтения и записи в секунду.
Такой подход помогает понять, почему тормозит Linux сервер: из-за конкретного процесса, высокой очереди запросов или проблем самого устройства.
Статистика за прошлые периоды
Иногда неисправность проявляется не в момент проверки. Например, сервер периодически замедляется ночью, когда запускается резервное копирование. В этом случае полезен пакет `sysstat`.
Для Ubuntu и Debian:
```bash
sudo apt install sysstat
```
Для CentOS и RHEL:
```bash
sudo yum install sysstat
```
После настройки сбора статистики можно использовать `sar`:
```bash
sar -u
sar -r
sar -b
```
Первая команда показывает историю загрузки CPU, вторая - использование памяти, третья - активность дисковой подсистемы. Возможность посмотреть состояние системы час назад или в момент предыдущего сбоя делает `sar` важной частью постоянного мониторинга Linux сервера.
Практический алгоритм диагностики
При обнаружении замедления удобно двигаться от общего к частному:
1. Зафиксировать время сбоя и симптомы: медленные запросы, ошибки, зависание отдельных сервисов.
2. Запустить `uptime`, `top` или `htop` и оценить load average, CPU и iowait.
3. Проверить память с помощью `free -h` и `vmstat`.
4. Проанализировать диск через `iotop` и `iostat`.
5. Если проблема неочевидна, изучить статистику `sar`.
6. Сопоставить результаты с журналами systemd и приложений:
```bash
journalctl -p warning..alert
```
7. Проверить сеть: ошибки интерфейса, потерю пакетов, заполнение канала и задержки до ключевых узлов.
Сетевые проблемы нередко маскируются под общую медлительность сервера. Если CPU, RAM и диск находятся в норме, стоит проверить интерфейсы командами `ip -s link`, `ss -s`, а также протестировать доступность соседних узлов с помощью `ping` и `mtr`.
Что делать после обнаружения причины
Если перегружен процессор, сначала определите процесс-виновник и выясните, почему он потребляет ресурсы: некорректный запрос, бесконечный цикл, неудачное обновление или слишком агрессивное расписание задач. При нехватке памяти следует найти приложения с растущим потреблением, ограничить их ресурсы и проверить настройки кэшей.
Дисковую нагрузку часто снижают переносом временных файлов, настройкой ротации логов, оптимизацией запросов к базе данных и разнесением интенсивных операций по разным накопителям. Однако перед заменой оборудования важно исключить программные причины и проверить состояние файловой системы и SMART.
Только после сбора фактов имеет смысл переходить к оптимизации Linux сервера: настраивать лимиты, планировщик, параметры виртуальной памяти, файловые дескрипторы и сервисы автозапуска. Редактировать системные параметры "наугад" опасно - это может скрыть симптом и усложнить дальнейший поиск.
В результате правильная диагностика превращается не в хаотичный набор команд, а в последовательную процедуру. Сначала определяется перегруженный ресурс, затем - конкретный процесс или подсистема, после чего проверяются журналы и история. Такой порядок позволяет сохранить данные о сбое, избежать необоснованной перезагрузки и устранить не только последствия, но и саму причину проблемы. geschniegelt
