Блог
VPS · практикаVPS и хостинг 10 мин чтения

VPS тормозит: что делать при высокой нагрузке — по шагам

Load average 15 при 2 CPU, ppа сайт лежит. Разбираем алгоритм диагностики: CPU, RAM, диск, сеть, БД. Утилиты, интерпретация, порядок действий.

Клиенты жалуются, сайт тормозит, мониторинг рисует красное. С чего начать диагностику? В голове — 20 возможных причин, 30 утилит, ощущение «сейчас не то время выбирать теорию».

Дадим прямолинейный алгоритм: что смотреть, в каком порядке, что значат цифры. Не «все возможные ситуации», а быстрый чек-лист от опытных админов.

Шаг 1: понять, что именно тормозит

Первые 30 секунд — определить симптом. top или htop:

htop
# Смотрим:
#   load average — 3 числа, за 1/5/15 мин
#   %CPU, %MEM у верхних процессов
#   swap использование (если swap = full, беда)

free -h
# Смотрим:
#   available RAM (не used! available учитывает кэш)
#   swap usage

df -h
# Полный диск? Тормоза + странные ошибки
На заметку

Расшифровка load average: число процессов в очереди на CPU или в состоянии D (uninterruptible sleep, обычно ждут I/O). На VPS с 2 CPU load=2 — уже 100%. Load=15 — очередь в 7 раз больше, чем можно обработать.

Шаг 2: CPU-bound или I/O-bound?

Ключевая развилка. Смотрим на %us (user) и %wa (iowait) в top:

  • %us высокий, %wa низкий — процессы CPU-bound. Оптимизировать код или добавить CPU.
  • %wa высокий — процессы ждут диск. Тормозит I/O — оптимизировать БД, добавить кэш, апгрейдить диск.
  • %sy высокий — kernel-работа. Обычно много context-switch или системных вызовов. Проверьте pidstat -w.
  • %si высокий (soft-irq) — сетевая обработка. Смотрите на количество пакетов/сек.
# Более детально по I/O
iostat -x 5
# %util > 90% — диск на пределе
# await > 20ms — медленный отклик
# svctm — время обслуживания одной операции

iotop
# Кто именно ест диск

Шаг 3: если CPU-bound

Определите главного пожирателя:

  • PHP-FPM — часто плохой код или отсутствие OPcache. Проверьте phpinfo(), включите OPcache, посмотрите slow-log FPM.
  • MySQL/MariaDB — плохие запросы без индексов. SHOW PROCESSLIST, SET GLOBAL slow_query_log=ON.
  • Nginx/Apache — часто DDoS или скрапер. Смотрите access.log, топ IP.
  • Node.js / Python — memory leak в приложении, стабильно растёт RAM → swap.
  • Cron — параллельно запустились несколько тяжёлых. Проверьте pgrep -a.
# Топ CPU-жоров прямо сейчас
ps aux --sort=-%cpu | head -10

# Что делают эти процессы?
strace -p <PID> -c   # summary syscalls
perf top -p <PID>     # где горячий код (нужен sudo)

Шаг 4: если I/O-bound

Медленный диск — топ-3 причины:

  • MySQL innodb_buffer_pool_size маленький — вся БД читается с диска. Установите 50-70% RAM для чистой DB-машины.
  • Full-scan запросы — отсутствие индексов. EXPLAIN для каждого медленного запроса.
  • Swap-thrashing — не хватает RAM. Всё уходит на swap на медленном диске. Спасение — апгрейд RAM, оптимизация памяти приложением, swappiness=10.
  • Logs/каталоги переполнены — миллионы мелких файлов замедляют ФС. Ротация, cleanup.
  • Reboot после kernel-обновления — иногда disk-cache холодный, первый час всё медленное.
Совет

Быстрая проверка: fio --name=r --rw=randread --bs=4k --size=1G --iodepth=32 --numjobs=4 --runtime=30 --time_based --group_reporting. NVMe VPS должен давать 30000+ IOPS. Если <5000 — диск проблемный.

Шаг 5: если сеть тормозит

Признаки: ping внутри VPS — миллисекунды, снаружи — сотни. Или высокая packet loss.

# Скорость канала
iperf3 -c bouygues.iperf.fr

# Packet loss и route
mtr -rzc 100 <target-ip>

# Открытые соединения
ss -tuna | wc -l
ss -tuna | awk '{print $6}' | sort | uniq -c | sort -rn | head

# Кто ест трафик
iftop -i eth0
На заметку

Типовые причины: DDoS (см. /blog/ddos-zaschita-vps-2026), утечка соединений в приложении, скрапер, проблема у хостера (open ticket).

Шаг 6: быстрые quick-wins

Если нужно сейчас снять пик:

  • Включить Cloudflare Under Attack Mode — 30 секунд, снимает 80% ботов.
  • Nginx rate-limit — на самые дорогие endpoint-ы.
  • Отключить фоновые задачи на время пика (индексация, отчёты, backup).
  • Restart тяжёлых процессов — если memory-leak, временно спасёт.
  • Прогреть кэш — если пик после restart, часто просто нужно время на прогрев OPcache/Redis.
  • Апгрейд VPS — у нас переход на следующий тариф за 15 минут через панель.

Шаг 7: не забыть про постмортем

После сглаживания пика — не забыть разобраться в root cause. Записать: что случилось, когда, симптомы, что помогло, что делать чтобы не повторилось. Через месяц забудете, через полгода наступите на те же грабли.

Частые вопросы

Load average 10 при 4 CPU — это критично?
Да, очередь в 2.5 раза больше пропускной. Нормально: load = число ядер или чуть меньше.
Сайт лёг, а VPS показывает %CPU=5%
Часто — I/O bound (диск) или БД (проверьте `SHOW PROCESSLIST`). Или заблокирован файрволом/rate-limit.
Как отличить DDoS от роста трафика?
У DDoS нет реалистичных user-agent, много единичных IP или /24, характерные URL. Настоящий рост — распределён по /24, гео близко к вашему.
Стоит ли ждать «само рассосётся»?
Иногда — да (краткий пик от нового поста в СМИ). Но чаще — реагируйте. Простой = деньги.