Почему сайт создаёт высокую нагрузку на процессор сервера и как найти причину
Почему сайт перегружает сервер: поиск причины высокой нагрузки, проверка PHP-процессов, WordPress, ботов и WP-Cron
Получите консультацию / коммерческое предложение
оператор АМУРА сейчас в сети
Почему сайт создаёт высокую нагрузку на процессор сервера и как найти причину
Сайт может годами работать стабильно, а затем неожиданно начать перегружать сервер. В панели управления растёт нагрузка на процессор, страницы открываются медленно, админка WordPress зависает, появляются ошибки 500 и 502, а хостинг присылает предупреждения о превышении допустимых ресурсов.
Владелец сайта часто делает очевидный вывод: сервер стал слабым и нужно срочно переходить на более дорогой тариф. Но увеличение мощности решает проблему далеко не всегда. Если сайт атакуют боты, WordPress запускает тысячи фоновых задач или один PHP-процесс зависает на несколько часов, дополнительная память и процессорные ядра лишь временно отсрочат повторение аварии.
Высокая нагрузка на CPU — это не сама проблема, а симптом. Чтобы действительно исправить ситуацию, необходимо определить, какой сайт, файл, запрос, плагин или внешний бот создаёт нагрузку.
Как проявляется перегрузка сервера
Первые признаки обычно замечают посетители сайта. Страницы начинают открываться дольше обычного, оформление заказа в интернет-магазине зависает, формы обратной связи не отправляются, а вместо сайта периодически появляется сообщение об ошибке.
В панели сервера при этом можно увидеть высокий показатель Load Average, большое количество процессов PHP, рост потребления оперативной памяти и активное использование swap.
Особенно опасна ситуация, когда десятки процессов php-cgi или php-fpm продолжают работать по 10, 20, 60 минут и дольше. Обычный запрос к странице сайта должен завершаться значительно быстрее. Если процесс живёт десятки минут и занимает сотни мегабайт памяти, значит запрос завис, выполняет тяжёлую операцию или ожидает ответа от другого сервиса.
Постепенно свободная оперативная память заканчивается. Сервер начинает переносить данные в swap — специальную область на диске. Диск намного медленнее оперативной памяти, поэтому система замедляется ещё сильнее. Возникает цепная реакция: старые процессы не успевают завершаться, новые продолжают запускаться, очередь растёт, а сервер практически перестаёт отвечать.
Почему WordPress может создавать высокую нагрузку на процессор
Сам по себе WordPress не обязательно является причиной перегрузки. На одном сервере могут стабильно работать десятки сайтов. Проблема возникает, когда определённый запрос запускает тяжёлую цепочку операций.
На практике высокая нагрузка чаще всего связана с несколькими сценариями.
Массовые запросы ботов и поисковых роботов
Не каждый робот, который обращается к сайту, является полезным поисковым ботом. Некоторые сканируют формы авторизации, перебирают уязвимые адреса, атакуют xmlrpc.php или создают тысячи обращений к динамическим страницам.
Особенно тяжёлыми могут быть запросы к интернет-магазину WooCommerce. Обычная информационная страница часто кешируется и почти не нагружает сервер. Корзина, оформление заказа, добавление и удаление товаров работают иначе. Для каждого такого запроса WordPress запускает PHP, обращается к базе данных, создаёт или обновляет пользовательскую сессию, пересчитывает корзину и выполняет код плагинов.
Если бот начинает массово открывать ссылки вида:
/cart/?add-to-cart=...
или:
/cart/?remove_item=...
сервер обрабатывает их почти как действия реального покупателя.
В одном из недавних случаев на сайте было зафиксировано более 200 тысяч запросов к корзине WooCommerce. Робот обходил динамические ссылки добавления и удаления товаров, а каждый запрос запускал ресурсоёмкую обработку WordPress.
Параллельно другой адрес отправил десятки тысяч запросов к xmlrpc.php. В результате на сервере одновременно появились десятки PHP-процессов, каждый из которых потреблял значительный объём памяти.
Атаки на XML-RPC
Файл xmlrpc.php является штатной частью WordPress. Он используется для удалённого взаимодействия с сайтом, мобильных приложений, публикации материалов и некоторых интеграций.
Но на большинстве обычных корпоративных сайтов и интернет-магазинов его возможности не используются. При этом именно xmlrpc.php регулярно становится целью автоматических атак.
Боты могут отправлять тысячи запросов для подбора паролей, проверки доступности сайта или выполнения массовых обращений через механизм pingback. В журнале сервера такие запросы часто выглядят как обычные POST-обращения, однако при большом количестве они создают серьёзную нагрузку.
Если XML-RPC не нужен проекту, доступ к нему целесообразно ограничить на уровне веб-сервера. Важно блокировать запрос до запуска WordPress и PHP. Установка очередного защитного плагина не всегда помогает: чтобы плагин отклонил запрос, сервер сначала должен загрузить WordPress, подключить базу данных и выполнить PHP-код.
Неконтролируемый WP-Cron
WordPress использует встроенную систему фоновых задач — WP-Cron. Через неё запускается публикация запланированных материалов, отправка уведомлений, проверка обновлений, обработка задач WooCommerce, очистка временных данных и работа некоторых плагинов.
По умолчанию wp-cron.php может запускаться во время посещения сайта. При нормальной нагрузке это обычно незаметно. Но во время атаки или массового обхода страниц каждый новый запрос способен инициировать проверку фоновых задач.
Если предыдущая задача не завершилась или постоянно возвращает ошибку, запускаются новые процессы. В журналах можно увидеть тысячи обращений к wp-cron.php с собственного IP-адреса сервера.
Получается замкнутый цикл:
внешний бот открывает страницу, WordPress запускает cron, задача зависает или завершается ошибкой, следующий запрос запускает ещё один процесс.
Правильнее отключить автоматический запуск WP-Cron при посещениях и настроить системный cron по расписанию, например один раз в 5 или 10 минут. Тогда количество фоновых запусков становится контролируемым и не зависит от активности ботов.
Почему перезагрузка сервера не решает проблему
Когда сайт перестаёт отвечать, владелец или администратор часто перезапускает Apache, PHP, MySQL или весь сервер.
После перезагрузки нагрузка действительно может снизиться. Зависшие процессы исчезают, оперативная память освобождается, сайт снова начинает работать.
Но если причина не устранена, через несколько минут или часов ситуация повторяется.
Бот снова обращается к корзине. XML-RPC снова принимает тысячи запросов. WP-Cron запускает проблемную задачу. Плагин продолжает создавать ошибки.
Перезагрузка полезна как аварийная мера, но она уничтожает часть диагностической информации. До перезапуска желательно зафиксировать:
- список процессов с наибольшим потреблением CPU;
- пользователей, от имени которых запущены процессы;
- время жизни PHP-процессов;
- адреса запрашиваемых страниц;
- IP-адреса посетителей;
- User-Agent ботов;
- ошибки Apache, Nginx, PHP и MySQL;
- состояние оперативной памяти и swap.
Без этих данных поиск причины превращается в догадки.
Как определить, какой сайт нагружает сервер
Если на сервере размещено несколько проектов, сначала необходимо связать процессы с конкретным системным пользователем.
Панели управления обычно запускают PHP каждого сайта от отдельного пользователя. Благодаря этому можно увидеть, какой аккаунт потребляет больше всего процессорного времени.
Далее анализируются процессы этого пользователя: сколько их запущено, как долго они работают, сколько памяти занимают и в каком состоянии находятся.
После этого изучаются журналы доступа сайта. В них можно найти:
- самые часто запрашиваемые URL;
- наиболее активные IP-адреса;
- User-Agent посетителей;
- количество обращений к
xmlrpc.php; - запросы к корзине WooCommerce;
- запуски
wp-cron.php; - массовые обращения к
wp-login.php; - ошибки 500, 502, 503 и 504.
Такой анализ позволяет отличить реальную посещаемость от автоматической атаки.
Например, тысяча открытий обычных страниц из поиска может почти не создавать нагрузки при работающем кешировании. А несколько сотен запросов к корзине, поиску по сайту или фильтру товаров способны загрузить сервер значительно сильнее.
Почему нельзя бездумно блокировать всех роботов
После обнаружения атаки возникает желание закрыть сайт от всех ботов. Это опасное решение.
Если заблокировать Яндекс, Google и другие полезные поисковые системы, страницы начнут выпадать из индекса. Пострадают позиции и органический трафик.
Необходимо ограничивать именно проблемные действия:
- запретить ботам выполнять операции с корзиной;
- закрыть ненужный XML-RPC;
- ограничить частоту запросов;
- блокировать конкретные IP-адреса и диапазоны;
- фильтровать подозрительные User-Agent;
- закрыть технические и служебные URL;
- настроить защиту до запуска PHP;
- сохранить доступ к обычным страницам для поисковой индексации.
Особенно важно не полагаться только на файл robots.txt. Добросовестные поисковые роботы учитывают его правила, но атакующие программы могут полностью их игнорировать.
Какие последствия вызывает постоянная нагрузка на сервер
Даже если сайт пока продолжает открываться, высокая нагрузка постепенно создаёт новые проблемы.
Снижение позиций в поиске
Медленный сервер ухудшает время ответа страниц. Поисковый робот не всегда может полноценно обойти сайт, часть запросов получает ошибки, а новые материалы индексируются медленнее.
Если сайт регулярно возвращает 500 или 502, поисковая система может временно сократить частоту обхода. При продолжительных проблемах страницы начинают терять видимость.
Потеря заявок и заказов
Посетитель не будет ждать, пока страница откроется через 20–30 секунд. Он вернётся в поиск и выберет конкурента.
Для интернет-магазина последствия ещё серьёзнее. Пользователь может добавить товар в корзину, но не перейти к оформлению. Может зависнуть оплата, не отправиться уведомление или не сохраниться заказ.
Переполнение диска
Журналы ошибок и доступа во время атаки растут очень быстро. Если свободное место закончится, MySQL может прекратить запись данных, почта перестанет приниматься, а сайты начнут возвращать ошибки.
Блокировка аккаунта хостингом
На виртуальном хостинге превышение лимитов часто приводит к автоматическому ограничению ресурсов. На VPS или выделенном сервере ограничения может не быть, но перегрузка одного сайта замедлит все остальные проекты.
Повреждение базы и незавершённые операции
При аварийной перезагрузке или нехватке памяти процессы могут быть завершены во время записи данных. Большинство современных систем умеет восстанавливаться, но риск повреждения таблиц, незавершённых заказов и потерянных изменений сохраняется.
Как временно снизить нагрузку
Аварийное устранение обычно начинается с завершения зависших процессов конкретного сайта. Важно не останавливать PHP для всех проектов, если проблема относится только к одному аккаунту.
Далее блокируются наиболее опасные запросы, отключается ненужный XML-RPC, ограничивается доступ к динамическим URL корзины для ботов и переводится WP-Cron на системное расписание.
После этого проверяется, появляются ли новые тяжёлые процессы. Если нагрузка снова растёт, необходимо продолжать анализ: смотреть запросы в реальном времени, проверять плагины, cron-задачи и базу данных.
Просто увеличить сервер с 4 до 8 ядер — не полноценное решение. При массовой атаке новые ресурсы также будут быстро заняты.
Что входит в полноценное устранение проблемы
Правильная работа с высокой нагрузкой включает не одну команду и не установку универсального защитного плагина.
Необходимо:
- определить сайт, который создаёт нагрузку;
- установить конкретный процесс и тип запроса;
- найти источники трафика;
- отделить поисковых роботов от атакующих ботов;
- проверить WordPress, плагины, тему и базу;
- остановить аварийное размножение процессов;
- настроить ограничения на уровне Nginx или Apache;
- перевести фоновые задачи на контролируемый cron;
- проверить логи после внесения изменений;
- убедиться, что защита не мешает поисковой индексации, заказам и работе сайта.
Только после этого можно говорить, что причина устранена, а не временно скрыта.
Нужен ли более мощный сервер
Иногда — да. Если сайт действительно получает высокий объём реального трафика, содержит большой каталог, сложные фильтры, интеграции с 1С и внешними сервисами, увеличение ресурсов может быть оправдано.
Но сначала нужно устранить аномальные запросы и программные ошибки.
Нет смысла оплачивать более дорогой сервер, чтобы он быстрее обрабатывал десятки тысяч атак на xmlrpc.php или бесконечные запросы роботов к корзине.
После оптимизации нередко выясняется, что текущей мощности достаточно, а основная проблема заключалась в неправильной конфигурации и отсутствии защиты динамических страниц.
Помощь при высокой нагрузке на сайт
Если сервер постоянно загружен, WordPress работает медленно, появляются ошибки 500 и 502, а хостинг сообщает о превышении ресурсов, проблему необходимо диагностировать до очередной перезагрузки.
Специалисты АМУРВЕБ анализируют процессы PHP и MySQL, журналы сервера, активность ботов, работу WP-Cron, плагины WordPress, WooCommerce и настройки веб-сервера. Мы определяем не только сайт-виновник, но и конкретный запрос или механизм, который создаёт нагрузку.
За прошедший месяц мы помогли решить подобные проблемы более чем 20 владельцам сайтов. В одних случаях причиной становились атаки на XML-RPC, в других — массовый обход корзины WooCommerce, зависшие PHP-процессы, ошибки плагинов, переполненные журналы или неконтролируемые фоновые задачи WordPress.
Главная задача — не просто временно снизить показатели CPU, а устранить источник нагрузки, сохранить работоспособность сайта и не навредить его продвижению в Яндексе и Google.
Аудит, диагностика и лечение сайтов/серверов.
Какие сайты делаем мы
Вопрос — Ответ (FAQ)
Стоимость работ — 9 000 ₽. В эту сумму входит диагностика нагрузки, поиск сайта и процессов, создающих проблему, анализ журналов, выявление опасных запросов, настройка защиты и проверка результата после внесённых изменений.
Мы определяем, какой сайт нагружает сервер, какие PHP-процессы потребляют ресурсы и какие запросы их запускают. Причиной могут быть атаки на xmlrpc.php, массовый обход корзины WooCommerce, неконтролируемый WP-Cron, ошибки плагинов, зависшие скрипты или проблемы с базой данных.
Мы определяем, какой сайт нагружает сервер, какие PHP-процессы потребляют ресурсы и какие запросы их запускают. Причиной могут быть атаки на xmlrpc.php, массовый обход корзины WooCommerce, неконтролируемый WP-Cron, ошибки плагинов, зависшие скрипты или проблемы с базой данных.
Потребуется доступ к серверу по SSH с правами root. Он необходим для просмотра системных процессов, нагрузки на CPU и память, журналов веб-сервера, конфигурации PHP, Apache или Nginx и других данных, недоступных из панели WordPress.
В большинстве случаев — нет. Доступ к административной панели WordPress позволяет проверить плагины и настройки сайта, но не даёт возможности полноценно определить нагрузку на уровне сервера, связать процессы с конкретным сайтом и безопасно изменить серверную конфигурацию.
Да. Перед началом работ заключается договор, в котором фиксируются стоимость, перечень работ, порядок предоставления доступов и обязательства сторон.
Доступ используется только для выполнения согласованных работ. После завершения диагностики и настройки защиты пароль можно изменить. При необходимости для работы может быть создан отдельный временный пользователь с необходимыми административными правами.
Сначала мы устанавливаем конкретную причину нагрузки. После этого устраняем или ограничиваем источник проблемы и проверяем состояние сервера. Если нагрузку создают боты, cron-задачи, зависшие процессы или неправильные настройки, результат обычно виден сразу. Если проблема связана с архитектурой сайта, устаревшим кодом или нехваткой ресурсов при реальной посещаемости, потребуется отдельный план оптимизации.
Обычно длительное отключение не требуется. Некоторые активные запросы или зависшие процессы могут быть кратковременно завершены, но остальные сайты на сервере по возможности продолжают работать. Необходимость технической паузы заранее согласовывается с владельцем.
Да. Мы работаем с WordPress, WooCommerce, Elementor и сайтами, размещёнными на VPS или выделенных серверах. Также можно диагностировать сервер, на котором одновременно размещено несколько проектов.
Срок зависит от причины и текущего состояния сервера. Первичную диагностику и аварийное снижение нагрузки во многих случаях удаётся выполнить в день обращения. Если требуется проверка плагинов, базы данных, фоновых задач и длительное наблюдение, работа может занять больше времени.
В зависимости от ситуации мы блокируем вредоносные запросы, ограничиваем доступ к техническим адресам, отключаем ненужный XML-RPC, настраиваем системный запуск WP-Cron, завершаем зависшие процессы, проверяем плагины и устраняем ошибки, из-за которых разрастаются журналы или повторно запускаются тяжёлые операции.
Не всегда. Сначала необходимо устранить аномальную нагрузку. Нет смысла оплачивать дополнительные ресурсы, если сервер расходует их на сотни тысяч запросов ботов, атаки на WordPress или зависшие PHP-процессы. Решение о расширении сервера принимается только после диагностики реальной нагрузки.
Наши клиенты и партнеры
Запрос коммерческого предложения
Ассистент AMUR сейчас в сети
