CPU, RAM и диск: симптомы проблем сервера

Высокий CPU: сайт отвечает медленнее

Когда CPU постоянно занят, запросы начинают ждать своей очереди. Backend медленнее обрабатывает страницы, API отвечает дольше, cron-задачи конкурируют с пользовательскими запросами. На графиках сайта это часто видно как рост TTFB, а затем как timeout или 503.

Важно отличать короткий пик от устойчивой перегрузки. Короткий пик при деплое или бэкапе может быть нормальным. Но если CPU держится высоко в рабочее время, а пользователи жалуются на медленный сайт, нужно искать причину: тяжёлые запросы, рост трафика, фоновые задачи или недостаток ресурсов.

• проверьте процессы, которые потребляют CPU
• сравните пики CPU с ростом TTFB
• посмотрите cron-задачи и время бэкапов
• оцените, хватает ли CPU-ядер для текущей нагрузки

Нехватка RAM: swap, OOM и нестабильные процессы

RAM влияет на всё: приложение, базу данных, кеши, очереди, web-сервер. Когда памяти не хватает, сервер может начать использовать swap. Это резко замедляет работу. В худшем случае OOM killer завершает процесс, и сайт начинает отдавать 502 или 503.

Проблемы RAM часто проявляются постепенно. После релиза память растёт, через несколько часов процесс падает, потом перезапускается и цикл повторяется. Без графика кажется, что сайт “иногда сам падает”. С графиком видно, что перед каждым падением память подходила к лимиту.

• проверьте, используется ли swap
• ищите OOM-события в системных логах
• смотрите тренд памяти после деплоев
• настройте уведомление до критического лимита

Заполненный диск: маленькая проблема с большими последствиями

Диск может заполниться логами, бэкапами, временными файлами, дампами, кешем, пользовательскими загрузками или Docker images. Когда свободного места не остаётся, ломаются операции записи: сессии, логи, база данных, загрузка файлов, кеширование и очереди.

Опасность диска в том, что сайт может долго работать нормально, а затем резко начать отдавать ошибки. При этом CPU и RAM выглядят приемлемо. Поэтому мониторинг диска должен предупреждать заранее и показывать скорость роста, а не только текущее значение.

• следите за процентом занятости и свободными GB
• проверяйте скорость роста за сутки и неделю
• настройте ротацию логов
• контролируйте бэкапы и временные файлы

Как связать ресурсные метрики с ошибками сайта

Сами по себе CPU, RAM и диск не говорят, что пользователь видел ошибку. Их нужно связывать с внешним мониторингом сайта: HTTP-статусом, TTFB, SSL и доступностью. Тогда становится понятно, повлияла ли нагрузка на реальный пользовательский сценарий.

Например, если CPU вырос, но TTFB остался нормальным и 5xx нет, это может быть допустимая фоновая задача. Если RAM дошла до лимита и через минуту появились 502, связь очевиднее. Если диск заполнен и база начала отдавать ошибки, нужно лечить не только приложение, но и инфраструктуру.

• сравнивайте метрики сервера с HTTP-статусами
• смотрите момент начала инцидента
• анализируйте восстановление после снижения нагрузки
• не делайте вывод по одной метрике без контекста

Какие пороги использовать

Пороги зависят от проекта, но можно начать с практичных ориентиров. CPU выше 90% долгое время — повод проверить нагрузку. RAM выше 85-90% — риск swap или OOM. Диск выше 80% — нужно планировать очистку, выше 90% — реагировать срочно. Но главное — не абсолютный порог, а повторяемость и влияние на сайт.

После нескольких недель мониторинга пороги стоит подстроить под нормальное поведение сервера. Если проект всегда использует 70% RAM и стабилен, это его база. Если обычно CPU 10%, а затем стал 60% без объяснения, это уже сигнал, даже если до критического порога далеко.

• начинайте с warning и critical порогов
• адаптируйте пороги под обычную нагрузку
• смотрите тренд, а не только момент
• уведомляйте по состоянию, которое требует действия

Что делать, когда ресурсный инцидент уже случился

При высоком CPU сначала найдите процессы и запросы, которые создают нагрузку. При нехватке RAM проверьте OOM, swap, утечки и последние релизы. При заполненном диске не удаляйте файлы вслепую: сначала определите, что растёт быстрее всего, затем очистите безопасные логи, старые бэкапы, временные файлы или неиспользуемые образы.

После срочного восстановления нужно устранить причину. Если просто перезапустить приложение или удалить случайный лог, проблема вернётся. Настройте ротацию, лимиты, алерты, оптимизацию запросов или увеличение ресурсов, а затем наблюдайте за повторением в истории мониторинга.

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

• сначала снимите симптом, затем найдите корневую причину
• не удаляйте данные без понимания источника роста
• проверяйте логи и метрики вокруг начала инцидента
• после исправления настройте предупреждающие пороги