Высокая нагрузка на процессор: как найти причину

MAATRIX

Сервер тормозит, сайт еле отвечает, а нагрузка на процессор держится у сотни процентов. Причина почти всегда конкретна: какой-то процесс, запрос или процесс-пришелец съедает ресурс. Ниже — как за несколько минут найти виновника, отличить реальную перегрузку от ложной тревоги и понять, что делать: оптимизировать, снять процесс или наращивать мощность.

Первым делом: смотрим, кто грузит процессор

Не гадайте — посмотрите. Основной инструмент для этого — интерактивный монитор процессов, который сразу показывает главных потребителей:

htop

Если htop не установлен, поставьте его или используйте штатный top. Отсортируйте процессы по загрузке процессора и посмотрите на верхние строки: обычно один-два процесса и создают всю нагрузку. Запомните их имена и владельца — это отправная точка расследования. Если наверху ваш веб-сервер или интерпретатор приложения, дело в самом приложении или в тяжёлых запросах к нему. Если это база данных — она захлёбывается на неоптимальных запросах. А вот незнакомый процесс с непонятным именем, грузящий процессор на полную, — тревожный признак, к которому мы ещё вернёмся.

Обратите внимание и на показатель load average — среднюю нагрузку за 1, 5 и 15 минут. Его нужно сравнивать с числом ядер: значение, равное числу ядер, означает полную, но здоровую загрузку, а вдвое большее говорит, что задачи стоят в очереди и система не справляется. Три числа показывают динамику: если минутное сильно выше пятнадцатиминутного, нагрузка растёт прямо сейчас, если ниже — пик уже позади и ситуация выправляется.

Учимся читать нагрузку правильно

Высокая загрузка процессора не всегда означает проблему именно с процессором. Ключ к пониманию — распределение нагрузки по типам, которое показывает top в строке CPU. Показатель user — это полезная работа ваших программ, system — работа ядра, а вот iowait — время, которое процессор простаивает в ожидании диска. Высокий iowait означает, что упор вовсе не в вычисления, а в медленный или перегруженный диск, и наращивать ядра бессмысленно.

Ещё один коварный показатель — steal time. Если он заметен, значит ваш виртуальный сервер не получает процессорное время, потому что его забирают соседи по физическому железу на перепроданном хостинге. В этом случае проблема не в вашем сервере и не в вашем коде — вам просто не отдают оплаченные ресурсы. Умение различать user, iowait и steal сразу направляет расследование в верную сторону и избавляет от бессмысленного апгрейда там, где он не поможет.

Частые причины высокой нагрузки

Перечислим типовые сценарии, чтобы вы узнавали их с ходу. Первый и самый частый — тяжёлые запросы к базе данных: один неоптимальный запрос без индекса способен нагрузить процессор сильнее, чем весь остальной трафик. Второй — наплыв посетителей или ботов на сайт без кэширования, когда каждый запрос запускает тяжёлую генерацию страницы. Третий — фоновые задачи и cron, которые запустились не вовремя или зациклились.

Четвёртый сценарий заслуживает особого внимания — взлом. Если процессор грузит незнакомый процесс, особенно от имени веб-сервера или с бессмысленным именем, вероятен майнер криптовалюты, которого подсадили через уязвимость. Такой процесс часто маскируется и перезапускается сам. Пятый, уже упомянутый, — не ваш процесс вовсе, а нехватка отданных ресурсов из-за соседей на перепроданном хостинге. Знание этих пяти причин превращает диагностику в проверку короткого списка гипотез, каждую из которых легко подтвердить или отбросить.

Диагностика по шагам

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

tail -f /var/log/nginx/access.log

Отдельно проверьте нагрузку на диск, если видите высокий iowait. Инструмент статистики ввода-вывода покажет, какой раздел загружен и насколько:

iostat -x 1

Если наверху незнакомый процесс, не спешите его просто убивать — сначала запишите его имя, путь к исполняемому файлу и владельца, чтобы понять природу. Убитый вслепую майнер вернётся через минуту, если не найти и не закрыть способ, которым он попал на сервер. Диагностика — это не только «кто грузит», но и «почему он тут оказался».

Полезно также посмотреть на нагрузку во времени, а не только в моменте. Разовый всплиск при сборке проекта, ночном бэкапе или запуске тяжёлого отчёта — это нормально и не требует вмешательства. Проблема — когда высокая нагрузка держится постоянно или регулярно повторяется в одно и то же время. Совпадение пиков с расписанием cron сразу выдаёт задачу-виновника, а ровное плато без явного источника чаще говорит о том, что сервер просто работает на пределе. Поэтому, найдя процесс, сопоставьте моменты нагрузки с журналом задач и графиком трафика — это отделяет случайный всплеск от системной проблемы, которую нужно решать по-настоящему.

Ещё один шаг, о котором забывают, — проверить количество процессов и потоков, а не только их загрузку. Иногда процессор грузит не один тяжёлый процесс, а сотни лёгких: например, приложение бесконтрольно плодит воркеров или подключения. В этом случае суммарная нагрузка складывается из множества мелких, и убивать их поодиночке бесполезно — нужно менять настройку числа процессов у самого приложения. Такой сценарий легко пропустить, глядя только на верхние строки монитора, поэтому иногда стоит оценить общую картину, а не только лидеров списка.

Когда виноват не процесс, а сам сервер

Иногда после всех проверок оказывается, что отдельного пожирателя нет, а нагрузка размазана по многим процессам и держится стабильно высокой. Это честный сигнал, что проекту стало тесно: реальный трафик и объём работы переросли текущую конфигурацию. Здесь оптимизация уже выжата, и вопрос переходит в плоскость ресурсов.

Отдельно стоит вернуться к steal time. Если он высокий, никакие ваши действия не помогут — процессорное время забирает не ваш код, а сосед по железу. Это прямой признак перепроданного хостинга, и единственное настоящее решение — перейти на сервер с гарантированными ресурсами, где выделенные ядра принадлежат только вам. Платить за оптимизацию там, где провайдер просто не отдаёт оплаченное, бессмысленно.

Что делать: оптимизация или мощность

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

И только когда оптимизация исчерпана, а нагрузка реальна и постоянна, приходит очередь наращивать мощность — добавить ядра или перейти на более крупный тариф. Здесь важно, чтобы провайдер позволял апгрейд без переезда и давал гарантированные, а не «до» ресурсы. Сервер, где ядра ваши и никем не делятся, ведёт себя предсказуемо, и вы точно знаете, что платите за то, что реально получаете.

Профилактика: чтобы не застало врасплох

Лучшая защита от внезапной перегрузки — мониторинг, который предупреждает заранее. Настройте наблюдение за загрузкой процессора и load average с оповещением при устойчивом превышении порога: тогда вы отреагируете, пока сайт ещё работает, а не когда он уже лёг. Регулярно просматривайте журнал медленных запросов — он показывает узкие места до того, как они станут аварией.

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

Частые вопросы