«Почему всё тормозит?» Первые шаги при диагностике нагруженного Linux-сервера

Проблема

Вы заходите на сервер по SSH, а команды выполняются с задержкой. Сайты открываются медленно, база данных отвечает через раз, а пользователи заваливают жалобами. Знакомая ситуация? Первое желание перезагрузить машину (а вдруг поможет). Но перезагрузка это крайняя мера, которая уничтожает информацию о текущем состоянии и не решает причину.

Как за 5-10 минут понять, что именно «жрёт» ресурсы: процессор, память, диск или сеть? Для этого у сисадмина есть джентльменский набор консольных утилит. Сегодня разберём самые ходовые: top/htop, iotop, iftop и быстрый взгляд в логи.

Решение

Мы будем действовать как детектив: последовательно проверять версии.

1. Сначала оценим общую нагрузку и процессы (CPU/RAM).
2. Если процессор и память в порядке, проверим диск (вдруг кто-то усиленно читает/пишет).
3. Затем глянем сеть (возможно, идёт массовая загрузка или DDoS).
4. В конце заглянем в системные логи — там часто бывают подсказки (ошибки диска, проблемы с ядром).

Все инструменты, кроме top, скорее всего, потребуют установки, но это делается одной командой.

Пошаговая инструкция

Шаг 1. Общая картина: top / htop

Начнём с классики. Введите в терминале:

bash

top

или более продвинутый вариант (если установлен):

bash

htop

Что смотрим в top:

text

top - 14:23:45 up 12 days,  3:21,  2 users,  load average: 8.15, 6.24, 4.38
Tasks: 245 total,   3 running, 242 sleeping,   0 stopped,   0 zombie
%Cpu(s): 65.5 us, 12.2 sy,  0.0 ni, 20.3 id,  1.0 wa,  0.0 hi,  1.0 si,  0.0 st
KiB Mem : 16267352 total,  1052240 free,  8123456 used,  7141656 buff/cache
KiB Swap: 16777212 total, 16777212 free,        0 used.  5145676 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 7890 mysql     20   0  ­8.5g   2.1g  25600 S  1300 13.5 112:34.56 mysqld
 1234 www-data  20   0  521456 102456  32456 R  45.0  0.6   5:23.12 php-fpm
 4321 root      20   0  300000  45000  12000 S  15.0  0.3   2:01.45 apache2
...

Ключевые показатели:

• load average (средняя нагрузка): три числа за 1, 5 и 15 минут. Если числа превышают количество ядер процессора (например, 8 ядер, а load > 8) система перегружена. В примере load 8.15 при 8 ядрах? уже на грани.
• %Cpu(s): обращаем внимание на wa (iowait) — если высокий (больше 5–10%), значит процессор часто ждёт ответа от диска. sy (system) время, потраченное ядром (если > 30%, возможны проблемы с драйверами или сетью).
• Строка процессов: сортировка по умолчанию по %CPU. Сразу видим «пожирателя» — в примере это mysqld с 1300% CPU (использует 13 ядер!). Дальше можно разбираться, почему MySQL так грузит сервер (медленные запросы, отсутствие индексов).

В htop всё то же самое, но красивее: можно листать процессы стрелками, сортировать по разным колонкам, убивать процессы F9. Удобно сразу увидеть, сколько ядер загружено (графики вверху).

Шаг 2. Дисковая подсистема: iotop

Если в top вы заметили высокий wa (iowait) или подозреваете, что диск узкое место, запускаем iotop. Он показывает, какие процессы больше всего читают/пишут с диска.

Установка (если нет):

bash

# Debian/Ubuntu
sudo apt install iotop
# CentOS/RHEL
sudo yum install iotop

Запуск:

bash

sudo iotop -o

Флаг -o (only) показывает только те процессы, которые прямо сейчас что-то делают с диском.

Пример вывода:

text

Total DISK READ: 50.25 M/s | Total DISK WRITE: 120.36 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 7890 be/4 mysql      40.15 M/s   90.20 M/s  0.00 % 95.45 % mysqld
 1234 be/4 www-data   10.10 M/s    0.00 M/s  0.00 % 12.34 % php-fpm
...

Видим, что mysqld активно читает и пишет, причём процент времени с IO (последний столбец) у него почти 100% диск перегружен базами данных.

Если iotop ничего не показывает, а подозрения на диск остались, используйте iostat -x 1 (из пакета sysstat). Там можно посмотреть await (время ответа диска) и %util (загрузка диска) — если > 90%, диск точно забит.

Шаг 3. Сеть: iftop

Теперь проверим, не «упирается» ли сервер в сеть. iftop показывает трафик по соединениям в реальном времени.

Установка:

bash

# Debian/Ubuntu
sudo apt install iftop
# CentOS/RHEL
sudo yum install iftop

Запуск:

bash

sudo iftop

Интерфейс похож на top, но для сети. Вы увидите список IP-адресов, с которыми идёт обмен, и скорости передачи/приёма.

На что смотреть:

• Общая загрузка канала (пики вверху экрана). Если приближается к лимиту (100 Mbit/s, 1 Gbit/s), то причина тормозов сеть.
• Кто больше всего генерирует трафик. Может оказаться, что неизвестный хост качает с сервера большой файл или идёт бэкап в неположенное время.

Для более детального анализа можно использовать nethogs, который группирует трафик по процессам (а не по IP).

Шаг 4. Логи — чёрный ящик с подсказками

Иногда проблема не в нагрузке, а в ошибках. Например, диск сыпется, и ядро постоянно пытается перечитать сектора. Или кто-то ломится по SSH.

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

• dmesg — кольцевой буфер сообщений ядра. Содержит аппаратные ошибки, проблемы с дисками, сбои файловых систем.bashdmesg | tail -20 dmesg | grep -i errorЕсли видите строки типа Buffer I/O error, ata hardware error — срочно проверяйте SMART диска.
• /var/log/syslog (Debian/Ubuntu) или /var/log/messages (CentOS) основные системные логи. Ищем по слову error или failed за последние минуты.bashtail -50 /var/log/syslog | grep -i error
• /var/log/auth.log или /var/log/secure — попытки входа. Если видите множество попыток входа с разных IP — возможно, идёт подбор паролей (брутфорс), что создаёт нагрузку на SSH.bashtail -100 /var/log/auth.log | grep -i «Failed password»
• Логи конкретных приложений (nginx, apache, mysql) — они обычно лежат в /var/log/nginx/error.log, /var/log/mysql/error.log и т.д.

Итог: шпаргалка по первым действиям

Заключение

Перезагрузка сервера — это как выключение телевизора и включение обратно: иногда помогает, но причину не устраняет. Потратив 10 минут на диагностику с помощью top, iotop, iftop и логов, вы либо точно найдёте виновника, либо поймёте, что проблема глубже (требуется профилирование приложений, настройка БД, апгрейд железа).

Со временем вы научитесь по первым цифрам понимать, куда копать. Главное — не паниковать и методично проверять все версии.

Если у вас есть похожий случай из практики — поделитесь в комментариях! Всегда интересно разобрать реальную историю.