Нагрузка на сервер: кто съедает лимиты хостинга и что резать первым

Что такое нагрузка на сервер и в чём её меряют

Нагрузка на сервер — это объём ресурсов железа, который сайт забирает под свою работу: процессорное время на сборку страниц, оперативная память под PHP-процессы, дисковые операции и обращения к базе данных. На виртуальном хостинге эти ресурсы делятся между десятками соседей на одной машине, поэтому у каждого аккаунта стоит потолок. Пока сайт в него укладывается, о нагрузке никто не вспоминает. Как только вылезает — приходит письмо от хостера с предупреждением, а часть посетителей видит ошибку 503 или 508 вместо страницы.

Смотрят нагрузку в панели хостинга, в разделе с названием вроде «Использование ресурсов» или «Статистика нагрузки». Там четыре ключевые цифры: процессорное время (в CP, попугаях провайдера или процентах ядра), память на процесс, количество одновременных процессов и операции с диском. У хостеров на CloudLinux это лимиты LVE, и рядом с графиком обычно есть колонка со срабатываниями лимита — она говорит больше, чем усреднённый красивый график за месяц.

Снаружи перегруз выглядит как выросший TTFB: сервер думает над первым байтом ответа по полторы-три секунды вместо привычных 200-300 мс, причём ровно в те часы, когда на сайте больше всего живых людей. Второй симптом — сайт «плавает»: одна страница открывается мгновенно, соседняя висит десять секунд, обновил — снова быстро.

Сразу очерчу границу темы. Здесь только серверная сторона: лимиты, логи, процессы, база, боты. Вес картинок, шрифты и скрипты, которые тормозят уже в браузере посетителя, я разбирал отдельно — в материале про скорость загрузки сайта. Сжатие JPEG никак не поможет против парсера, который выкачивает каталог в тридцать потоков.

Лимиты хостинга: процессор, память, процессы, диск

Тариф виртуального хостинга за 200-500 рублей в месяц обычно даёт примерно одно-два ядра, около гигабайта памяти на процесс и 20-30 одновременных входящих процессов. У провайдеров цифры различаются, суть одна: лимитов несколько, и упереться можно в любой из них по отдельности. Что означает каждый:

• Процессорное время (CPU, CP, SPEED). Заканчивается первым в подавляющем большинстве случаев. Когда лимит выбран, хостинг притормаживает ваши процессы, и страница, которая собиралась 300 мс, начинает собираться три секунды.
• Память на процесс (PMEM). В неё упираются импорт товаров, генерация YML-фида, бэкап-плагины, экспорт заказов. Признак — белый экран или ошибка 500 на одном конкретном действии, притом что остальной сайт работает нормально.
• Одновременные процессы (EP, NPROC). Самый обидный лимит. Каждый долгий запрос держит слот, и когда все двадцать слотов заняты ботами, живой посетитель получает 508 Resource Limit Is Reached, хотя процессор в этот момент почти свободен.
• Диск и inodes. Логи, кэш плагинов, старые бэкапы внутри сайта съедают и место, и лимит на количество файлов. Миллион мелких файлов замедляет вообще все операции, включая бэкап самого хостера.
• База данных. Отдельные ограничения на число соединений и на время запроса. Один тяжёлый запрос с сортировкой по неиндексированному полю выстраивает остальные в очередь.

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

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

Как найти источник нагрузки: логи доступа и медленные запросы

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

• Топ IP-адресов. awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20. Если один адрес выдал 40 тысяч запросов за час при трёх тысячах живых визитов в сутки, дальше можно не искать.
• Топ User-Agent. Тот же приём по полю с агентом. Здесь вылезают SEO-краулеры, парсеры цен и «браузеры» с пустым или самописным агентом.
• Топ URL. Показывает, какие адреса дёргают чаще всего. Если в верхушке /wp-cron.php, /xmlrpc.php, /wp-login.php или /?s=, вы уже знаете, что чинить.

Второй источник правды — медленные запросы к базе. При доступе к MySQL включите slow query log с порогом в одну секунду и соберите его за сутки. Обычно набирается 5-10 однотипных запросов, и это фильтр каталога, встроенный поиск или отчёт какого-нибудь плагина статистики. На WordPress то же самое ловится плагином Query Monitor: он показывает время генерации страницы, количество запросов и хуки, которые их порождают. Больше сотни запросов на обычную страницу — уже повод разбираться.

Третий срез — время. Наложите пики нагрузки на расписание: бэкап хостера, ночная выгрузка товаров, обмен с 1С, рассылка, переиндексация. Половина «загадочных» ночных полок оказывается двумя плановыми задачами, которые кто-то поставил на одну и ту же минуту. Разнести их на 20 минут — бесплатное решение, которое работает годами.

Боты, краулеры и парсеры: кто выкачивает сайт круглосуточно

На проектах, где я разбирал перегруз, боты стабильно давали от половины до трёх четвертей обращений к серверу. В Яндекс Метрике этого трафика почти не видно: счётчик срабатывает через JavaScript, парсер забирает голый HTML и уходит дальше. Картина «в Метрике 700 визитов, в логах 200 тысяч запросов» — совершенно рядовая история для небольшого магазина.

Кто там обычно пасётся: коммерческие SEO-краулеры (Ahrefs, Semrush, MJ12bot, DotBot), сборщики данных для ИИ, парсеры цен от конкурентов, скрипты перебора паролей на /wp-login.php и /xmlrpc.php, плюс сами поисковики. Яндекс и Google трогать нельзя, их обход — это ваша индексация; для них есть настройка скорости обхода в Вебмастере. Остальных фильтруем по нарастающей:

• robots.txt. Коммерческие краулеры Disallow и Crawl-delay уважают, их можно замедлить или выгнать одной строкой. Яндекс директиву Crawl-delay с 2022 года игнорирует, скорость обхода задаётся в Вебмастере. Парсеры цен и сборщики контента на robots.txt смотрят факультативно, поэтому это только первый слой.
• Блокировка по User-Agent на уровне nginx или .htaccess. Запрос отсекается до запуска PHP, то есть до самой дорогой части. Поэтому такой блок эффективнее плагина-защитника, который сам стартует внутри WordPress и тратит те же ресурсы.
• Ограничение частоты запросов. В nginx это limit_req по IP, порядка 2-5 запросов в секунду с небольшим burst. Живому человеку хватает с запасом, парсер в тридцать потоков упирается в потолок и отваливается.
• Закрыть служебные точки входа. xmlrpc.php отключаем, если не пользуетесь мобильными приложениями и пингбэками. Доступ к wp-login.php ограничиваем по IP или закрываем basic-авторизацией на уровне веб-сервера — перебор паролей тогда даже не доходит до PHP.

Проверять, настоящий ли перед вами робот поисковика, нужно через обратный DNS по IP. User-Agent подделывается одной строкой, PTR-запись на чужом хосте подделке не поддаётся. Про то, как ботовый мусор портит ещё и аналитику с рекламой, я подробно писал в разборе фродового трафика и ботов: там про Метрику и Директ, здесь про процессорное время.

WP-Cron, тяжёлые плагины и внутренние скрипты

Встроенный планировщик WordPress работает на посетителях: почти каждый заход дёргает wp-cron.php, который проверяет, не пора ли выполнить запланированные задачи. При полусотне визитов в сутки это незаметно. Когда на сайт приходит краулер и делает тысячу запросов за десять минут, тот же механизм порождает сотни лишних PHP-процессов, и на графике вырастает ровная полка.

Лечится двумя действиями, и оба обязательны. В wp-config.php добавляем define('DISABLE_WP_CRON', true); — запуск планировщика на посетителях выключается. Затем вешаем системный крон, который дёргает wp-cron.php по расписанию, раз в 5-15 минут. Если забыть второй шаг, тихо отвалятся отложенные публикации, бэкапы, синхронизация остатков и письма: обнаруживают это обычно через месяц, когда клиент спрашивает, почему статьи не вышли.

Дальше плагины. Тяжелее всего ведут себя конструкторы страниц, которые собирают вёрстку на каждый хит; плагины статистики, пишущие каждый визит в базу; блоки «похожие записи» и «с этим товаром покупают» с выборкой на лету; бэкап-плагины, стартующие в дневной пик; два SEO-плагина, установленные одновременно. Метод отбора виновника банальный и честный: отключил один — посмотрел график полчаса — включил обратно. За вечер обходится десяток кандидатов.

Отдельная статья расходов — админка. Heartbeat API стучит в admin-ajax.php каждые 15-60 секунд у каждой открытой вкладки, и редактор, забытый открытым на ночь, даёт тысячи запросов к серверу. Туда же идут автообновления, проверки лицензий и обращения к внешним API, которые держат PHP-процесс в ожидании ответа по несколько секунд. На сайте с тремя-четырьмя редакторами это заметная доля потребления, особенно по лимиту одновременных процессов.

Поиск по сайту, фильтры каталога и база: где сайт душит сам себя

Встроенный поиск WordPress ищет по тексту записей запросом с LIKE и процентами с обеих сторон. Индексы в такой конструкции бесполезны, поэтому база честно перебирает все записи целиком. На блоге в 300 статей это 50 мс, на каталоге в 20 тысяч товаров с описаниями — уже секунды. Теперь добавьте бота, который долбит /?s= случайными словами в двадцать потоков: сервер уходит в полку за несколько минут, и никакая оптимизация картинок тут не поможет.

Рабочие решения по порядку: поставить на параметр поиска ограничение частоты и закрыть его от обхода, отдать поиск внешнему движку вроде Elasticsearch или Sphinx, а на небольших сайтах просто выключить штатный поиск, если им никто не пользуется. Пользуются или нет — видно по логам за пять минут: считаете долю запросов с /?s= от живых людей и принимаете решение по цифре.

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

Третье — состояние самой базы. Проверьте объём автозагружаемых опций (в WordPress это строки wp_options с autoload='yes'): нормой считаю до мегабайта, при четырёх-пяти каждая страница сайта тащит этот груз в память при каждом хите. Туда же — просроченные транзиенты, по сорок ревизий на статью, логи плагинов на миллион строк, таблицы от давно удалённых расширений. Чистка базы плюс индексы на поля, по которым идёт фильтрация, часто снимают четверть нагрузки без единой правки в шаблонах.

Что отключать первым и когда пора менять тариф

Порядок действий важен: сначала то, что даёт максимум эффекта за минимум времени. Мой стандартный маршрут на перегруженном сайте выглядит так:

• Кэш страниц. Самое сильное действие из всех. Nginx с fastcgi_cache или страничный кэш на стороне сайта отдаёт готовый HTML, минуя PHP и базу. На контентном проекте это снимает 80-95% нагрузки за час работы.
• Боты и перебор паролей. Блок по User-Agent, ограничение частоты, закрытые wp-login.php и xmlrpc.php. Второе по эффекту действие, обычно ещё минус треть запросов.
• WP-Cron на системный планировщик плюс разнесение тяжёлых задач на ночь и по разным минутам.
• Ревизия плагинов. Выключить неиспользуемое, заменить самых прожорливых, убрать дубли по функциям.
• Поиск, фильтры, база. Индексы, чистка autoload и транзиентов, лимиты на параметры в URL.

После этого измеряйте честно, по графику ресурсов за неделю до и за неделю после; ощущение «вроде стало шустрее» здесь бесполезно. В моей практике порядок такой: перегруженный сайт на виртуальном хостинге после этих пяти шагов уходит с полки в 90-100% на спокойные 20-40%, и вопрос тарифа снимается на год-полтора.

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

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

Главное

Нагрузка на сервер почти никогда не берётся из воздуха: за полкой на графике стоит конкретный источник — краулер в тридцать потоков, планировщик WordPress, плагин статистики или запрос к базе без индекса. Порядок работы простой: снять лог за час инцидента, сделать три среза (топ IP, топ User-Agent, топ URL), включить кэш страниц, отсечь ботов, перенести крон на системный планировщик и почистить плагины с базой. На перегруженном сайте этот маршрут обычно снимает потребление с 90-100% до 20-40% и откладывает переезд на дорогой тариф на год-полтора. Начните с логов сегодня — до того, как хостер пришлёт третье письмо.