В статистике — несколько десятков посетителей за день. В панели хостинга — процессор загружен на 100%, растёт нагрузка на диск, а сайт периодически открывается по десять секунд. На первый взгляд одно противоречит другому: кому перегружать сервер, если на сайте почти никого нет?
На самом деле счётчик аналитики и сервер измеряют разные вещи. Счётчик видит в основном людей, которые открыли страницу в браузере. Сервер же обрабатывает всё: запросы роботов, фоновые задания сайта, резервное копирование, проверку файлов, импорт товаров и работу базы данных.
Иногда один неудачно настроенный процесс создаёт больше нагрузки, чем сотня обычных посетителей.
Боты, которых нет в статистике
Поисковые роботы, сканеры уязвимостей и сборщики данных не всегда отображаются в Метрике или другой системе аналитики. Но каждый их запрос доходит до веб-сервера и может запускать PHP, обращаться к базе данных и создавать новые записи в журнале.
Особенно заметна нагрузка, когда робот перебирает тяжёлые страницы:
-
поиск по сайту;
-
фильтры каталога;
-
карточки товаров с большим количеством модулей;
-
старые адреса, возвращающие сложную страницу ошибки;
-
страницы авторизации и административной панели;
-
URL с разными параметрами, которые не попадают в кэш.
Первым делом стоит открыть журнал обращений к сайту. Если за короткий промежуток времени один адрес или один тип робота запросил тысячи похожих страниц, причина перегрузки уже почти найдена.
Блокировать весь подозрительный трафик подряд не нужно. Среди роботов могут быть поисковые системы и полезные сервисы. Ограничения лучше вводить для конкретных адресов и сценариев, подтвердивших чрезмерную активность.
Фоновые задания могут запускаться посетителями
WordPress и Joomla умеют выполнять запланированные операции: публиковать материалы, очищать данные, обновлять каталоги, отправлять уведомления и запускать задания расширений.
Часть таких операций может проверяться при обычном обращении к сайту. Поэтому первый посетитель после периода тишины иногда невольно запускает накопившуюся очередь заданий. Внешне это выглядит странно: человек открыл одну страницу, а процессор и база данных получили работу сразу от нескольких плагинов.
Проверять нужно не только системный cron, но и планировщик внутри CMS. В WordPress стоит посмотреть список событий WP-Cron, а в Joomla — раздел Scheduled Tasks и историю их выполнения.
Если тяжёлое задание должно запускаться раз в сутки, лучше назначить ему отдельное время. Главное — не допускать одновременного запуска резервного копирования, импорта товаров, проверки безопасности и очистки базы.
Ночная перегрузка часто оказывается резервным копированием
Резервная копия — это не простое копирование нескольких файлов. Система может одновременно:
-
читать тысячи файлов сайта;
-
выгружать базу данных;
-
создавать архив;
-
проверять его;
-
отправлять копию на удалённое хранилище;
-
удалять старые архивы.
В этот момент активно работают процессор и диск. Если несколько сайтов создают копии в одно и то же время, сервер может заметно замедлиться даже при полном отсутствии посетителей.
Характерный признак — пики нагрузки появляются примерно в один и тот же час. В таком случае полезнее разнести задания по времени, чем сразу покупать более дорогой тариф.
Отдельно нужно проверить, не хранит ли плагин резервного копирования архивы внутри каталога сайта. Бывает, что следующая копия включает предыдущие архивы и с каждым запуском становится всё больше.
Один тяжёлый запрос к базе может заменить сотни посетителей
Количество посетителей само по себе мало говорит о сложности сайта. Простая страница-визитка и интернет-магазин с фильтрами создают совершенно разную нагрузку.
Проблемный модуль может при каждом открытии страницы просматривать большую таблицу, пересчитывать остатки или искать данные без подходящего индекса. В результате один запрос выполняется несколько секунд и удерживает ресурсы базы.
На Joomla причиной нередко становятся разросшиеся таблицы сессий, журналов или данных сторонних расширений. На WordPress — плагины поиска, статистики, безопасности, импорта и интернет-магазина.
Для диагностики полезен журнал медленных запросов MySQL. Он показывает не просто факт загрузки базы, а конкретные запросы, которые выполняются слишком долго или просматривают много строк. Без такой проверки совет «добавить оперативной памяти» остаётся гаданием.
Процессор свободен, но сайт всё равно тормозит
Не всякая перегрузка связана с процессором. Сервер может ждать, пока диск прочитает файл, запишет журнал или обработает очередь операций. В панели это иногда отображается как I/O wait — ожидание дисковых операций.
Такое происходит при одновременной работе резервного копирования, базы данных, антивирусного сканирования и больших журналов. Увеличение количества процессорных ядер здесь почти ничего не изменит: процессы продолжат ждать диск.
Похожая ситуация возникает с внешними сервисами. Например, сайт при оформлении заказа обращается к CRM, платёжной системе или службе доставки. Если внешний сервис отвечает медленно, рабочие процессы PHP остаются занятыми. Посетителей мало, процессор не всегда загружен полностью, но новые страницы начинают ждать своей очереди.
Как связать симптом с вероятной причиной
Нагрузка появляется каждый день в одно время.
Проверяем cron, планировщик CMS, резервные копии, импорт и проверку безопасности.
В журнале много одинаковых запросов.
Ищем активного робота, сканер или неправильно настроенную интеграцию.
Процессор загружен во время работы каталога или поиска.
Проверяем PHP, плагины и медленные запросы к базе данных.
Процессор занят слабо, но сайт отвечает долго.
Смотрим нагрузку на диск, очередь операций и обращения к внешним сервисам.
Заканчивается оперативная память и используется swap.
Проверяем количество процессов PHP, базу данных и фоновые задания. Swap — это использование диска вместо оперативной памяти, поэтому после его включения сервер обычно резко замедляется.
Пики начались после установки расширения.
Временно отключаем именно это расширение и повторяем проверку. Не стоит одновременно менять кэш, версию PHP и тариф: после нескольких изменений уже невозможно понять, что действительно помогло.
Порядок диагностики без лишней суеты
Сначала зафиксируйте точное время перегрузки. Фраза «сайт иногда тормозит» почти бесполезна, а интервал «с 03:05 до 03:20» уже можно сопоставить с журналами и графиками.
Затем действуйте по порядку:
-
Сравните время перегрузки с посещаемостью.
-
Посмотрите журнал обращений к сайту.
-
Проверьте задания WordPress, Joomla и системного cron.
-
Сверьте расписание резервного копирования, импорта и проверки файлов.
-
Проверьте медленные запросы к базе данных.
-
Определите, упирается сервер в процессор, память или диск.
-
Измените только одну предполагаемую причину и повторите наблюдение.
Если у вас нет доступа к системным показателям, отправьте поддержке не общий вопрос, а конкретный: «Какой процесс создавал нагрузку на CPU и диск с 03:05 до 03:20: PHP, MySQL, резервное копирование или другое задание?»
Такой запрос обычно даёт намного больше информации, чем просьба «посмотреть, почему тормозит сайт».
Когда более мощный сервер действительно нужен
Переход на другой тариф оправдан, если после устранения ошибок нормальная работа проекта всё равно постоянно упирается в доступные ресурсы. Например, сайту регулярно приходится обрабатывать большой каталог, выполнять импорт, строить отчёты или обслуживать несколько тяжёлых фоновых процессов.
Если графики и журналы показывают постоянную нехватку процессора или производительности диска, у QCKL можно подобрать HiCPU VDS на Intel Xeon E-2388G с NVMe либо выделенный сервер. Диагностику, мониторинг и резервное копирование при необходимости можно вынести в отдельное администрирование.
Но сам переезд не исправит зацикленное задание, тяжёлый SQL-запрос или агрессивного робота. На более мощном сервере такая проблема просто дольше остаётся незаметной.
Низкая посещаемость не означает, что сервер бездействует. Прежде чем увеличивать тариф, нужно назвать процесс, который потребляет ресурсы. Тогда станет понятно, что действительно требуется: ограничить робота, изменить расписание, исправить запрос к базе или добавить вычислительную мощность.
