Прямой ответ
Диагностика «тормозит сервер» — не гадание, а обход ресурсов по порядку: CPU → память → диск → сеть (USE-метод: для каждого ресурса — утилизация, насыщенность, ошибки). Первые три команды дают 80% картины: top/htop (что грузит CPU и сколько памяти), free -h (свободная память и swap — активный swap почти всегда диагноз), iostat -x 1 (диск как узкое место — самая частая находка на дешёвых VPS). Ключевой навык — читать, а не смотреть: load average сравнивается с числом ядер (load 4 на 4 ядрах — норма, не «загрузка 400%» в панике), wa% в top — время ожидания диска (высокое — проблема не в CPU), а «мало свободной памяти» в Linux — норма (page cache занимает свободное; смотреть надо available и swap-активность). Цель обхода — ответить на один вопрос: какой ресурс исчерпан и какой процесс его исчерпал, — после чего чинится процесс, а не «перезагружается сервер».
Шаг 1. CPU и load: кто и сколько
htop (или top): колонка CPU по процессам — кто ест; строка состояний — us (пользовательский код), sy (ядро — высокое sy подозрительно: контекст-свитчи, сеть), wa (ожидание I/O — высокое значит проблема в диске, а не процессоре), st (steal — гипервизор отбирает CPU соседей; на VPS ненулевой st — разговор с провайдером). Load average (1/5/15 минут) — число задач, претендующих на CPU и диск; сравнение с nproc: load ≤ ядер — система справляется. Отдельная ловушка: процессы в D-состоянии (непрерываемый сон — ожидание I/O) входят в load — «load 20 при нулевом CPU» — это диск, переходите к iostat. Для детализации по потокам — top -H, для истории (а не момента) — sar/atop (ставятся заранее: постфактум истории нет — аргумент в пользу мониторинга).
Шаг 2. Память: свободная ≠ доступная
free -h: смотреть строку available (сколько реально доступно с учётом сбрасываемого кеша), а не free (page cache «съедает» свободную память по построению — это норма). Диагностические сигналы: активный swap (si/so в vmstat 1 ненулевые — система реально свопится, отсюда и тормоза; на серверах приложений swap обычно отключают или минимизируют со swappiness), OOM-убийства — journalctl -k | grep -i oom («процесс умер сам» почти всегда OOM-killer с записью), растущее потребление одного процесса (RSS в top по времени — признак утечки; для Python-приложений следующий шаг — профилировщик памяти). Быстрый топ по памяти: ps aux --sort=-%mem | head. Ловушка контейнеров: лимиты cgroup не видны в free/top хоста — внутри контейнера смотрите /sys/fs/cgroup/.../memory.max и события OOM юнита (systemd-лимиты).
Шаг 3. Диск: самое частое узкое место
iostat -x 1 (пакет sysstat): %util (доля времени устройства занятого — ~100% на однопоточной нагрузке SATA/SAS означает насыщение; для NVMe-массивов метрика менее показательна), await/r_await/w_await (средняя задержка операций в мс — единицы для SSD, десятки-сотни — проблема), aqu-sz (очередь запросов). Кто виноват — iotop (по процессам) или pidstat -d 1. Типовые находки на серверах приложений: база с диском без кеша батареи/дешёвым VPS-диском (латентность записи убивает TPS), логи без ротации, заполнившие диск (df -h — банальная, но регулярная причина «всё легло»: ENOSPC ломает и БД, и логи; ротация логов — профилактика), бэкап-джоб в разгар дня. Отдельно — иноды: df -i (миллион мелких файлов исчерпывает иноды при свободных гигабайтах).
Шаг 4. Сеть и соединения
ss -s (сводка: сколько соединений, какие состояния), ss -tan state time-wait | wc -l (десятки тысяч TIME_WAIT — симптом, обычно лечится настройками приложения/keepalive, а не ядра), ss -tlnp (кто и что слушает — заодно аудит открытых портов). Трафик по интерфейсам — sar -n DEV 1/iftop; потери и ретрансмиты — netstat -s | grep -i retrans (растущий процент — сетевые проблемы ниже уровнем). Прикладной уровень: латентность до зависимостей изнутри сервера (curl -w до внешних API — «тормозит сервис» часто означает «тормозит чужой API», и диагностика упирается в таймауты/кеш — паттерны); nginx перед приложением даёт готовую статистику задержек в логах (конфиг).
Практический сценарий: «сайт открывается по 10 секунд»
Обход за пять минут. htop: CPU 15%, но load 12 на 4 ядра и wa 60% — система стоит в ожидании диска. iostat -x 1: w_await 180 мс, %util 99% — диск насыщен записью. pidstat -d 1: топ писателя — postgres (300 записей/с) и… скрипт бэкапа, стартовавший в 14:00 по cron (накладка расписания на рабочую нагрузку — классика). Быстрое лечение: остановить бэкап-задачу (ionice -c3 на будущее + перенос расписания на 03:00 — cron-практика); сайт ожил за секунды. Долгосрочное: vmstat 1 на неделю (sar/atop пишут историю — в следующий раз диагноз по архиву, а не «в моменте»), лимиты на бэкап-джоб (ionice/системный таймер с IO-весом), алерт на w_await > 50мс в мониторинге — следующая деградация найдётся до жалоб пользователей. Разбор показал и общий принцип: симптомы (медленный сайт) и причина (диск под бэкапом) живут на разных этажах — обход ресурсов находит связь между ними.
FAQ
Load 10 — сервер умирает? Смотря сколько ядер: load/nproc ≤ 1 — норма; 1–2 — под нагрузкой; больше — деградация. И помните про D-состояния: высокий load при низком CPU — это диск, лечится не «добавить CPU».
Памяти «свободно 200 МБ» — добавлять? Смотрите available и swap-активность: свободная память в page cache — работающая память. Тревога — когда available мал И si/so ненулевые И есть OOM в логах; иначе «мало свободной» — признак здорового кеша.
Какие инструменты поставить заранее? Минимальный набор постфактум-диагностики: sysstat (sar — история CPU/диска/сети), atop (снапшоты процессов каждые 10 минут — «что было в 04:00» отвечается без догадок), iotop/iftop. Ставятся за минуту, окупаются в первый же инцидент.
Сервер на VPS тормозит, а метрики «нормальные» — что ещё проверить?
Steal time (st в top/vmstat) — гипервизор отбирает CPU у вашей VM в пользу соседей; и дисковые латентности хостовой СХД (await растёт при вашем низком IOPS). Оба случая — повод для тикета провайдеру с цифрами, а не «переезд по кругу».
Источники: man top/iostat, USE-метод (Brendan Gregg) — ссылки в шапке.