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

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

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

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

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

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

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

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

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

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

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

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

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

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