Бывает, сервер или рабочая машина начинает «думать» дольше обы | Linux для чайника

Бывает, сервер или рабочая машина начинает «думать» дольше обычного: команды висят, интерфейс лагает, SSH отвечает с задержкой. Не паникуем — 90% случаев решаются системной диагностикой.

Полный чек-лист, когда что-то тормозит:

Шаг 1: Общая картина — что жрёт ресурсы прямо сейчас
Сразу запускаем htop (если нет — sudo apt install htop или dnf install htop).
Что смотреть:
• CPU: если все ядра на 100% — ищем процесс вверху списка (сортировка по %CPU — нажми F6 → %CPU).
• RAM/Swap: если Swap активно используется (жёлтая полоска) — нехватка памяти, процесс убивает OOM-killer.
• Load Average (вверху): три числа — 1/5/15 мин. Если на 4-ядерной машине >8-12 — перегрузка.

Альтернатива без htop: top (Shift+P — сортировка по CPU, Shift+M — по MEM).

Шаг 2: Память — free и vmstat
free -h # сколько реально свободно
vmstat -w 1 10 # каждую секунду 10 раз

Ключевые колонки в vmstat:
• r — процессы в очереди на CPU (если > числа ядер — CPU bottleneck)
• b — процессы в uninterruptible sleep (обычно I/O wait)
• si/so — swap in/out (если не нули — памяти не хватает)
• wa — % CPU в I/O wait (высокий — диски тормозят)

Шаг 3: Диски — iostat и iotop
iostat -xz 1 10 # расширенная стат-а каждую сек.
iotop # как htop, но для I/O (нужен root)

В iostat смотрим:
• %util близко к 100% — диск загружен полностью
• await > 20-30 ms — медленный отклик (SSD должно быть <1 ms)
• svctm устарело, но если высокое — проблемы

Если NVMe/SSD, а util 100% — часто виноваты большие логи или бэкапы.

Шаг 4: CPU детально — mpstat и pidstat
mpstat -P ALL 1 10 # нагрузка по каждому ядру
pidstat -u 1 10 # CPU по процессам со временем

Поможет понять: один поток жрёт одно ядро или нагрузка равномерная.

Шаг 5: Исторические данные — sar (sysstat)
Если проблема не постоянная:
sar -u 10 5 # CPU сейчас
sar -r # память за день
sar -d # диски за день
sar -n DEV # сеть

Sysstat по умолчанию собирает данные каждые 10 мин — золотой источник для ночных тормозов.

Шаг 6: Конкретный процесс — strace и perf
Если виновник известен (например, mysqld или java):
strace -p PID -c
# системные вызовы и сколько времени на них
perf top -p PID
# что именно в CPU жрёт (нужен kernel-headers)
perf record -p PID -g sleep 10; perf report
# профилирование

Шаг 7: Ядро и аппаратные проблемы
dmesg -T --follow
# последние сообщения ядра с читаемыми датами
cat /proc/interrupts
# если один IRQ очень высокий — драйвер/устройство

Частые виновники: ошибки диска, перегрев, сетевые драйверы.

Шаг 8: Сеть — если тормозит только удалённо
iftop # кто сколько трафика жрёт
nethogs # по процессам
ping -c 4 google.com
mtr google.com # трассировка + пинг