Представь: клиенты жалуются, сайт виснет, а ты едешь на метро и думаешь — что сломалось? Первое правило — не паниковать. Паника заставляет тыкать вкогдом где попало и терять время. Сохрани спокойствие и следуй простой структуре проверки.
Первое, что нужно сделать — понять масштаб проблемы
Вопросы: тормозит весь сервер или только один сайт? Только веб или и SSH/FTP тоже медленные? Это важно, потому что решение для «недоступна база данных» отличается от решения для «полный диск».
Включи простые инструменты и взгляни на состояние за 5 минут
Команды: top (или htop), free -m, df -h, iostat (или vmstat), dmesg | tail, journalctl -u сервис --since "10 minutes ago".
Не знаешь команды? Просто запусти top и посмотри на столбцы CPU, MEM и %wa — они скажут, кто страдает.
На что смотреть в top?
Высокий CPU у одного процесса — возможно зациклившаяся задача. %wa высокий — значит диск жрёт время ожидания, то есть I/O. Много процессов в состоянии D (uninterruptible sleep) — это чаще всего проблемы с диском или NFS-подвисания. Видишь это — двигайся в сторону диска.
Проверь диск и inode'ы
df -h покажет, заполнен ли диск. df -i покажет, не закончились ли inodes — да, такое бывает: логов много, места вроде есть, а новые файлы создать нельзя. Частая причина тормозов: диск 100% занят или /var/log огромные логи.
Проверь память и своп
free -m покажет, есть ли активный swap. Если своп активно используется и система медленная — это троттлинг из-за свопинга. Частая картина: утечка памяти в PHP-FPM или в приложении — процессы растут и система начинает тормозить.
Посмотри логи
dmesg может показать OOM-killer — ядро убило процессы из-за нехватки памяти. journalctl или /var/log/syslog подскажут ошибки служб, проблемы с сетью или с файловыми системами. Иногда причина очевидна: cron запустил бэкап и он уперся в ошибку.
Случай из практики: у клиента тормозил сайт раз в день. Я увидел в top — один PHP-FPM процесс занял 100% CPU и память росла. Оказалось, крон запускал импорт в базу с петлей. Решение — ограничить одновременные воркеры и поставить lock на cron. После этого лаги ушли.
Если виноват диск — что делать быстро?
Останови ненужные сервисы, очисти временные и старые логи: rm /var/log/*.gz или logrotate вручную. Найди большие файлы командой du -sh /* | sort -h или du -h /var | sort -hr | head. Если это база данных — включи бэкап в off-peak или перенеси на другой диск.
Если виноват процесс — как временно справиться?
Перезапусти сервис (systemctl restart имя). Но сначала посмотри, не критично ли это для пользователей. Иногда достаточно gracefully reload (systemctl reload) чтобы не потерять сессии. Если проблема повторяется — настрой автоограничение (systemd LimitRSS) или пересмотри конфигурацию сервиса.
Сеть может быть причиной.
ss -tunap покажет открытые соединения и нагрузки
Если видишь тысячи соединений на один процесс — возможно DDoS или misbehaving бот. Временно включи rate-limit в nginx/iptables, добавь fail2ban или заблокируй IP-адреса.
План на первые 15 минут, 1 час и 24 часа.
Первые 15 минут — определить масштаб и снять базовые показатели (CPU, RAM, I/O, диск, логи).
В час — локализовать сервис и дать временное решение: рестарт, очистка диска, блокировка IP.
В 24 часа — разбираться основательно: профайлинг, лимиты, релокация данных, обновление конфигурации.
Как избежать в будущем?
Мониторинг с алертами — не обязательно сложный. Даже простой cron, собирающий top, df и free и шлёт на почту при пороге, помогает. Настрой лимиты процессов, ротируй логи, ограничь cron'ы и не запускай тяжелые операции в пиковое время.
И напоследок — дорожная карта для фрилансера:
1) всегда сначала определяй масштаб; 2) собирай факты, а не домыслы;
3) принимай минимально инвазивные меры для восстановления;
4) планируй постоянное решение на следующий день. Это работает надежно и экономит время и нервы.
Не пугайся, если в первый раз не поймёшь причину
Сохраняй логи, делай снимки состояния и возвращайся с данными. Часто проблема видна в вещах на поверхности: диск полный, своп активен, один процесс пожирает ресурсы. Следуй структуре — и сервер вернётся в строй быстрее, чем кажется.