Утром сайт работал как обычно. Днем в почте появилось сообщение от хостинг-провайдера: аккаунт создает повышенную нагрузку на сервер, допустимые ресурсы превышены. Еще через некоторое время сайт начал открываться с перебоями или оказался временно ограничен.
Владелец идет в панель управления и видит странную картину. Дискового пространства полно. Трафик не закончился. Тариф оплачен до конца года. Посещаемость вчера была почти такой же, как неделю назад.
За что тогда блокировка?
Причина в том, что виртуальный хостинг ограничен не только гигабайтами диска. На одном физическом сервере работают сайты множества клиентов, поэтому провайдер контролирует использование процессора, базы данных, памяти, процессов и других ресурсов. Конкретный набор ограничений зависит от хостера и тарифа.
Например, Timeweb прямо указывает, что каждый тариф виртуального хостинга имеет допустимые лимиты нагрузки на процессор и базы данных, причем нагрузка рассчитывается суммарно по сайтам аккаунта. При систематическом превышении провайдер может ограничить доступ к сайтам.
Но письмо о нагрузке еще не означает, что вашему проекту обязательно нужен VPS.
Иногда сайт действительно вырос из тарифа. А иногда один сломавшийся плагин способен за несколько часов создать такую нагрузку, которую не создавали тысячи обычных посетителей.
Что вообще означает нагрузка на хостинге
Когда посетитель открывает обычную HTML-страницу, серверу нужно выполнить определенную работу. В случае динамического сайта процесс сложнее: веб-сервер принимает запрос, запускается PHP, CMS выполняет код, обращается к MySQL или MariaDB, получает данные и формирует ответ.
Один такой запрос может быть очень легким.
Но теперь представим тысячу одновременных запросов. Или один запрос, который выполняет крайне неэффективный код и заставляет процессор долго работать. Или страницу каталога, которая каждый раз делает десятки тяжелых запросов к базе.
Все это потребляет вычислительные ресурсы.
Поэтому два сайта с одинаковой посещаемостью могут создавать совершенно разную нагрузку. Простой информационный сайт с хорошим кэшем способен обслуживать значительный трафик, а небольшой интернет-магазин с неудачным фильтром товаров может упираться в ограничения при сравнительно скромной аудитории.
Даже внутри одного аккаунта ситуация бывает неочевидной. Если на тарифе размещены пять сайтов, хостер может считать их нагрузку вместе. Один забытый тестовый WordPress в подкаталоге способен портить жизнь основному проекту.
Отсюда первое правило: высокая нагрузка не равна высокой посещаемости.
Почему свободное место на диске здесь вообще ни при чем
Представьте автомобиль с почти пустым багажником, который пытается подняться в крутую гору. Свободный объем багажника ничего не говорит о мощности двигателя.
На хостинге похожая ситуация.
Дисковое пространство показывает, сколько данных можно хранить. CPU определяет вычислительную работу. База данных имеет собственную нагрузку. Могут существовать ограничения на память, число одновременно работающих процессов, количество файлов и другие параметры.
Поэтому тариф с 50 ГБ NVMe вовсе не обязан выдерживать более тяжелый PHP-код, чем тариф с 20 ГБ.
При сравнении хостинга большие цифры диска заметны лучше всего, поэтому именно на них часто смотрят новички. Но для динамического сайта производительность может упереться совсем в другой ресурс.
Если провайдер прислал предупреждение, сначала выясните точное название превышенного показателя. CPU? MySQL? Память? Процессы? Одновременные подключения?
Без этого фраза «сайт создает нагрузку» остается слишком общей.
Посещаемость не выросла, а нагрузка выросла в пять раз
Вот здесь начинается самое интересное расследование.
Вчера на сайт пришло 3000 человек. Сегодня тоже примерно 3000. Почему график CPU внезапно красный?
Потому что люди являются далеко не единственными клиентами веб-сервера.
Сайт постоянно посещают поисковые роботы. Его сканируют боты. Интернет-магазины могут обходить парсеры цен. Автоматические программы ищут уязвимые страницы WordPress, пробуют стандартные адреса входа, обращаются к XML-RPC, перебирают URL и проверяют известные уязвимости.
Официальная документация WordPress отдельно предупреждает, что brute force, хотлинкинг изображений и DoS-атаки способны увеличивать серверную нагрузку. Там же рекомендуется идентифицировать и блокировать вредоносный трафик.
Есть и совершенно легитимные роботы. Если сайт содержит сотни тысяч страниц, интенсивный обход тоже создает запросы.
Поэтому счетчик посетителей в аналитике не показывает всю работу сервера.
Если нагрузка появилась внезапно, серверные access-логи становятся одним из самых полезных источников информации. В них можно увидеть, какие URL запрашиваются, как часто, с каких адресов и какими User-Agent.
Например, обнаруживается, что один IP делает десятки запросов в секунду к поиску WordPress. Или неизвестный бот бесконечно перебирает параметры фильтра интернет-магазина.
Покупка более мощного тарифа в такой ситуации означает фактически покупку ресурсов для чужого бота.
WordPress способен нагрузить сервер сам
Допустим, подозрительного трафика нет.
Следующий кандидат находится внутри сайта.
Официальное руководство WordPress по производительности прямо отмечает влияние темы и плагинов на работу сайта и рекомендует выборочно отключать расширения, чтобы определить, какое из них заметно влияет на производительность.
Здесь важна не цифра «установлено 37 плагинов» сама по себе.
Тридцать небольших расширений могут работать легче одного плохо написанного. Значение имеет то, что конкретный плагин делает при каждом запросе.
Представим модуль статистики, который записывает в базу каждый просмотр. Или фильтр каталога, строящий сложный запрос по десяткам параметров. Или плагин, который при открытии страницы обращается к медленному внешнему API и ждет ответа.
Отдельный класс проблем создают фоновые процессы.
WordPress использует WP-Cron для запуска запланированных задач. Плагины подключают к нему свои события: отправку писем, очистку данных, публикацию записей, синхронизацию, резервное копирование и другие операции.
Если задача выполняется слишком часто, зависает или запускает тяжелую обработку, серверная нагрузка может появляться периодически и без роста числа посетителей.
Характерный признак: каждый день примерно в 03:00 график CPU взлетает, а через час возвращается в норму.
Тогда вместо смены хостинга стоит сначала выяснить, что запускается в это время.
Резервная копия тоже может положить сайт
Бэкап кажется пассивной операцией: взять файлы и сохранить копию.
На практике крупный сайт нужно прочитать с диска, иногда упаковать в архив, выгрузить базу, сжать данные и отправить их в другое хранилище. Все это требует ресурсов.
Если одновременно плагин резервного копирования, импорт товаров и антивирусный сканер решили поработать ночью, сервер может получить очень неприятный пик.
Еще тяжелее бывает массовая обработка изображений.
Вы поменяли тему, которая зарегистрировала новые размеры миниатюр, и запустили регенерацию для 30 000 фотографий. PHP начинает читать исходники, масштабировать изображения и записывать новые файлы. Процессор работает совсем иначе, чем при обычном просмотре страницы.
Такая нагрузка сама по себе не свидетельствует о плохом хостинге. Вы просто попросили сервер выполнить большую вычислительную работу.
Вопрос в том, позволяет ли тариф выполнять ее с приемлемой скоростью и не мешает ли она посетителям.
Кэш иногда решает проблему удивительно быстро
Представим информационный сайт, где большинство посетителей видит одинаковые статьи.
Без страничного кэша при каждом открытии WordPress запускает PHP, загружает компоненты CMS, выполняет запросы к базе и собирает HTML.
Тысяча просмотров означает тысячу повторений похожей работы.
Страничный кэш сохраняет готовый результат и позволяет отдавать его значительно дешевле.
WordPress в официальной документации называет кэширование одним из основных способов снижения нагрузки. Для относительно статических страниц готовые файлы могут обслуживаться без полного выполнения PHP и WordPress при каждом запросе.
Именно поэтому сайт способен внезапно начать превышать лимиты после того, как кэш отключили, неправильно настроили или он перестал работать из-за конфликта.
Но здесь тоже нельзя нажимать все кнопки подряд.
Корзина интернет-магазина, оформление заказа, личный кабинет и другие персонализированные страницы требуют аккуратных исключений. Если закэшировать их неправильно, проблема с CPU быстро сменится куда более неприятной проблемой с чужими данными или некорректной корзиной.
Для сложных сайтов используется и постоянный объектный кэш, например Redis или Memcached. Он помогает уменьшать повторные обращения к базе. Но устанавливать Redis вслепую на любой сайт только после письма хостера не нужно.
Сначала диагноз, потом лекарство.
Что делать сразу после письма от хостера
Первое действие звучит скучно: не паниковать и не начинать переезд в тот же вечер.
Откройте мониторинг ресурсов в панели. У Timeweb, например, доступна динамика нагрузки за последние 2 часа, сутки, 7 и 30 дней. Подобные графики позволяют увидеть не только сам факт превышения, но и его характер.
Ровная высокая линия и резкие короткие пики рассказывают разные истории.
Запишите время начала проблемы. Сравните его с посещаемостью, публикациями, обновлениями, импортами и резервными копиями.
Если хостер показывает CPU и MySQL отдельно, посмотрите, какой график растет.
Затем изучите логи запросов. Ищите необычно частые обращения к одному URL, подозрительных роботов и всплески автоматического трафика.
Если сайт на WordPress, вспомните последние изменения. Что обновлялось? Какой плагин установили? Не включали ли сканирование, генерацию изображений, импорт или новый модуль статистики?
Если проблема началась сразу после конкретного изменения, это очень сильная зацепка.
На тестовой копии можно выборочно отключать подозрительные плагины и измерять результат. Делать такой эксперимент на рабочем интернет-магазине в середине дня без резервной копии не лучшая идея.
И обязательно спросите поддержку не просто «почему заблокировали сайт», а какие процессы, скрипты или запросы создавали наибольшую нагрузку. Хорошая техническая информация от хостера иногда сокращает расследование с нескольких часов до десяти минут.
Когда проблема находится в MySQL
Процессор сайта и база данных тесно связаны, но это не одно и то же.
Страница может выполнять тяжелый SQL-запрос, который перебирает огромную таблицу без подходящего индекса. PHP при этом ждет результат, а база выполняет дорогую работу.
Особенно чувствительны каталоги с фильтрами, поиск, статистика, сложные выборки по метаданным WordPress и некоторые отчеты WooCommerce.
Если именно нагрузка MySQL регулярно выходит за пределы, простое увеличение PHP-лимитов проблему не исправит.
Нужно найти тяжелые запросы.
На собственном VPS для этого используют slow query log и другие инструменты профилирования базы. На виртуальном хостинге доступ может быть ограничен, поэтому полезно обратиться в поддержку или использовать диагностические инструменты WordPress на тестовой среде.
Иногда решение удивительно маленькое: правильный индекс превращает многосекундный запрос в быстрый.
Иногда виновата архитектура плагина, и проще заменить расширение.
А иногда база действительно стала настолько большой и активной, что проекту требуется больше ресурсов.
Нужно ли сразу переходить на VPS
Представим, что сайт постоянно использует почти весь допустимый CPU. Никаких атак нет. Кэш работает. Код проверен. База оптимизирована. Посещаемость растет месяц за месяцем.
Тогда переход на более производительный тариф или VPS выглядит естественным.
Но есть другая ситуация.
Сайт год работал при нагрузке 20 процентов. В понедельник установили новый плагин. Во вторник нагрузка стала 150 процентов. В среду хостер прислал предупреждение.
Переезд на VPS в этом случае может просто дать ошибочному процессу больше ресурсов для потребления.
Сначала устраните аномалию.
Более мощный хостинг нужен, когда нагрузка является нормальным следствием работы проекта, а не симптомом неисправности.
При выборе VPS учитывайте и другое: на виртуальном хостинге значительную часть администрирования берет на себя провайдер. На неуправляемом VPS следить за веб-сервером, PHP, базой, обновлениями, безопасностью, резервным копированием и мониторингом придется самостоятельно или с помощью администратора.
Поэтому VPS не является просто «следующим тарифом с большим CPU».
Как отличить выросший сайт от сломанного сайта
Полезно посмотреть на историю.
Если нагрузка растет постепенно вместе с посещаемостью, заказами, количеством товаров и активностью пользователей, это нормальный рост проекта.
Если график изменился за один день без понятной причины, ищите событие.
Обновление WordPress. Новый плагин. Массовый импорт. Изменение темы. Запуск рекламной кампании. Новый бот. Атака. Сломавшийся cron. Ошибка интеграции.
Другой хороший показатель это эффективность кэша.
Если главная и статьи практически статичны, но каждый просмотр полностью запускает WordPress, у сайта есть очевидный резерв.
Если же это сервис с авторизованными пользователями, персональными данными и динамическими ответами, доля некэшируемых запросов естественно выше.
Смотрите также на время ответа. Рост CPU одновременно с резким ухудшением TTFB часто означает, что сервер уже не успевает обрабатывать очередь запросов.
И не забывайте о нескольких сайтах в аккаунте. Иногда владелец оптимизирует главный проект неделю, а виновником оказывается заброшенный сайт пятилетней давности, который активно атакуют боты.
Что точно не стоит делать
Не устанавливайте пять «оптимизаторов» одновременно. Несколько систем кэширования и минификации способны конфликтовать и усложнить диагностику.
Не удаляйте случайные таблицы базы, cron-события и системные файлы по совету из старого форума.
Не блокируйте всех поисковых роботов только потому, что в логах много автоматических запросов.
Не увеличивайте интервалы всех фоновых задач без понимания их назначения. Некоторые из них отвечают за реальные функции сайта.
Не отключайте резервное копирование навсегда ради снижения CPU. Лучше изменить расписание, способ создания копий или вынести хранение, если именно бэкап создает тяжелый пик.
И главное, не воспринимайте ограничение хостера как личный конфликт с провайдером.
На виртуальном сервере ресурсы разделяются между клиентами. Если один аккаунт способен бесконтрольно занять процессор, пострадают остальные сайты на машине. Ограничения как раз нужны, чтобы этого не происходило.
Другой вопрос, насколько прозрачны лимиты конкретного тарифа и достаточно ли провайдер помогает разобраться в причине.
Письмо о нагрузке иногда оказывается полезным предупреждением
Сначала оно выглядит как неприятность. Но именно такое сообщение часто обнаруживает проблему, которая до этого месяцами оставалась незаметной.
Сломанный cron мог ежедневно съедать процессор ночью. Плагин делал тысячи лишних запросов к базе. Боты бесконечно перебирали фильтры магазина. Кэш перестал работать после обновления.
Сайт еще открывался, поэтому никто не обращал внимания.
Лимит заставил посмотреть на систему внимательнее.
Если хостинг сообщил о превышении нагрузки, выясните три вещи: какой ресурс превышен, в какое время это происходит и какой процесс или тип запросов совпадает с пиком.
После этого обычно становится понятно направление действий.
А уже затем решайте, что дешевле и правильнее: исправить код, настроить кэш, заблокировать вредоносный трафик, оптимизировать базу, перенести тяжелую фоновую задачу или действительно перейти на более мощный тариф.
Хороший VPS не исправляет плохой плагин.
Но хорошо оптимизированный сайт тоже не может бесконечно расти на самом младшем виртуальном тарифе.
Задача владельца не избежать нагрузки вообще. Работающий сайт всегда потребляет ресурсы. Нужно понять, является ли эта нагрузка полезной работой реальных посетителей или сервер занят тем, за что совершенно незачем платить.
