Высокая загрузка процессора на VPS может быть вызвана реальными посетителями, ботами, тяжелым PHP-кодом, запросами MySQL, cron или посторонним процессом. Перезапуск освобождает ресурсы на время, но уничтожает важный контекст и не устраняет источник.

Сначала зафиксируйте время, load average, CPU по процессам, память, I/O и частоту запросов. Затем сопоставьте пики с access log, slow log базы, PHP-FPM и расписанием фоновых задач. Ограничения вводите после подтверждения причины.

Что проверить в первую очередь

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

  • Снимите uptime/load, top/ps, vmstat и iostat, чтобы не спутать CPU с ожиданием диска.
  • Определите процесс, пользователя и команду, потребляющие ресурс.
  • Сравните время пика с access log, cron, очередями и медленными запросами базы.
  • Проверьте свободную память и swap: нехватка RAM может усиливать нагрузку.

Почему возникает проблема

У подобных сбоев редко бывает одна универсальная причина. На итог одновременно влияют конфигурация приложения, окружение, данные, кеш, права и внешние сервисы. Проверка должна идти от внешнего симптома к конкретному уровню, на котором впервые появляется неверное состояние.

  • Боты запрашивают тяжелые фильтры, поиск, несуществующие URL или XML-RPC без кеша.
  • PHP-FPM запускает слишком много воркеров или один код входит в дорогой цикл.
  • MySQL выполняет запросы без индекса, сортирует большие наборы или ждет блокировку.
  • Несколько cron-задач стартуют одновременно и обрабатывают один объем повторно.
  • Взломанный аккаунт или файл запускает майнер, рассылку или другой посторонний процесс.

Пошаговая диагностика

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

  • Соберите короткие снимки процессов несколько раз, а не один top после завершения пика.
  • Сгруппируйте access log по URL, IP, user-agent, коду ответа и времени обработки.
  • Включите slow query log на ограниченный период и разберите EXPLAIN тяжелых запросов.
  • Проверьте статус PHP-FPM, очередь, max children и slowlog.
  • Сверьте cron/systemd timers и исследуйте новые исполняемые файлы и сетевые соединения.

Как отличить трафик, код и базу

Одинаковые 100% CPU требуют разных исправлений. Связь нагрузки с запросом или задачей важнее общего процента.

  • CPU растет вместе с одним URL — профилируйте обработчик, запросы и кеш этого маршрута.
  • mysqld лидирует по CPU — ищите запросы, индексы, временные таблицы и объем выборки.
  • php-fpm потребляет CPU без внешнего трафика — проверяйте cron, очереди и внутренние вызовы.
  • Нагрузка идет от множества подозрительных запросов — применяйте rate limit, кеш и антибот после анализа.
  • Неизвестный процесс или соединение требует отдельного расследования целостности сервера.

Как исправить проблему

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

  • Ограничьте дорогие маршруты по частоте и закешируйте безопасные одинаковые ответы.
  • Оптимизируйте подтвержденные запросы базы и добавьте индексы после проверки плана.
  • Настройте PHP-FPM по доступной памяти и включите slowlog для зависших запросов.
  • Разведите фоновые задачи по времени, добавьте lock и пакетную обработку.
  • При признаках компрометации изолируйте сервер, смените секреты с чистого устройства и восстановите доверенную версию.

Безопасный порядок внедрения

  • Сохраните резервную копию затрагиваемых файлов, базы и конфигурации, а также заранее опишите способ отката.
  • Воспроизведите сбой на тестовой записи, учетной записи или отдельном окружении без реальных платежей и рассылок.
  • Вносите по одному логическому изменению, фиксируя его в системе контроля версий или журнале работ.
  • Не отключайте права, проверку входных данных и защитные механизмы только ради исчезновения сообщения об ошибке.
  • После выкладки контролируйте логи, метрики и ключевой пользовательский сценарий, а не только открытие одной страницы.

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

Успешный разовый тест еще не доказывает исправление. Нужны повторный запуск, крайние случаи и проверка после очистки кеша, перезапуска процесса или новой сессии. Для критичных сценариев полезно сохранить автоматический тест или хотя бы короткий регрессионный чек-лист.

  • При том же тестовом трафике CPU, время ответа и очередь PHP-FPM остаются в допустимых пределах.
  • Slow log не содержит прежнего тяжелого запроса или его время заметно уменьшилось.
  • Cron не запускается параллельно и корректно продолжает работу после сбоя.
  • За сутки мониторинг не фиксирует прежних пиков и роста 5xx/таймаутов.

Типичные ошибки при исправлении

  • Убивать первый тяжелый процесс без сохранения команды, запроса и времени.
  • Слепо увеличивать CPU/RAM, оставляя бесконечный цикл или запрос без индекса.
  • Блокировать всех неизвестных user-agent и задевать поисковых роботов и клиентов.
  • Отключать журналы именно во время расследования, теряя доказательства.

Как предотвратить повторение

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

  • Настройте метрики CPU, RAM, I/O, load, 5xx и времени ответа с историей.
  • Используйте rate limit и кеш для дорогих публичных маршрутов.
  • Проверяйте новые запросы EXPLAIN и нагрузочным тестом до релиза.
  • Добавляйте lock, лимиты и метрики выполнения всем регулярным задачам.

Что подготовить для разбора

  • Краткое описание ожидаемого и фактического поведения без паролей, токенов и персональных данных.
  • Точное время и последовательность действий, после которых появляется проблема.
  • Версии приложения, окружения и зависимостей, а также перечень последних изменений.
  • Фрагменты журналов с контекстом до и после ошибки; секреты в них необходимо скрыть.
  • Описание уже выполненных проверок и способ безопасно повторить проблему.

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

Поможет ли добавить еще одно ядро?

Иногда даст запас, но не исправит бот-атаку, цикл или запрос без индекса. Сначала нужно определить расход на единицу полезной работы.

Почему load высокий, а CPU не 100%?

Процессы могут ждать диск или сеть. Поэтому вместе с CPU смотрят iowait, vmstat, iostat и состояние процессов.

Когда нужна помощь специалиста

Если VPS перегружается и причина не видна, я могу снять профиль нагрузки, сопоставить процессы с запросами и задачами, устранить подтвержденное узкое место и настроить мониторинг, чтобы проблема не возвращалась незаметно.