Сервер на Linux «тормозит». Как вы будете искать причину?
Короткий ответ
- Сначала уточнить симптом: что именно и у кого тормозит
- Быстрый обзор: uptime, load average, dmesg на ошибки
- CPU: top/htop, user vs system vs iowait
- Память: free, наличие свопа, OOM-killer в логах
- Диск: iostat, высокая утилизация и latency
- Сеть: ss, retransmits, ошибки интерфейсов
- Сверить с метриками мониторинга: когда началось и что менялось
Диагностика идёт методично по ресурсам — CPU, память, диск, сеть — а не случайными командами.
Как сказать вслух
пример ответаСначала я уточняю, в чём именно выражается проблема и когда она началась. Потом смотрю общую картину: load average, ошибки ядра, кто ест процессор и память. Дальше проверяю по очереди CPU, память, диск и сеть — обычно виновник находится в одном из них, например высокий iowait или сработавший OOM-killer. Параллельно сверяюсь с графиками мониторинга и недавними деплоями, потому что чаще всего «тормоза» совпадают с каким-то изменением.
Подробный ответ
Основной ответ
Начинаю с формализации симптома: латентность запросов, фоновые задачи или всё сразу. Затем экспресс-осмотр по методологии USE (utilization, saturation, errors): uptime и load average в сравнении с числом ядер; top/htop — распределение CPU между user, system, iowait и steal; free -h и vmstat — память, своп, частота page faults; dmesg и journalctl — OOM-killer, ошибки дисков; iostat -x — утилизация и await по дискам; ss -s и счётчики интерфейсов — сеть. Для углубления — pidstat, perf, strace по конкретному процессу. Обязательно сопоставляю со временем деплоев и графиками в мониторинге: аномалия почти всегда коррелирует с изменением.
Ключевые моменты
- Load average. В Linux включает процессы в uninterruptible sleep, поэтому высокий LA при свободном CPU часто означает проблемы с диском.
- Методология USE. Для каждого ресурса проверить утилизацию, насыщение и ошибки — это защищает от хаотичного тыканья командами.
- OOM и своп. Активный своппинг и записи OOM-killer в dmesg — типичные причины внезапной деградации.
- Корреляция с изменениями. Вопрос «что менялось?» решает большинство инцидентов быстрее, чем профилирование.
Практический контекст
Один из самых частых практических вопросов на middle-позиции: интервьюер проверяет системность мышления и знание конкретных команд. В реальности этот сценарий случается еженедельно — деградация после релиза, забитый диск, утечка памяти. Сильный ответ — последовательность действий с объяснением, что означает каждый показатель, а не просто список утилит.
Частые ошибки
- Начинают с перезагрузки сервера вместо диагностики
- Называют команды без понимания, что означают их показатели (например, load average)
- Забывают про iowait и дисковую подсистему, ограничиваясь CPU и памятью