В три часа ночи на небольшом сайте может не быть ни одного живого посетителя, а процессор хостинга в это время занят сильнее, чем днем. На первый взгляд ситуация странная. Никто не открывает страницы, не отправляет формы и не листает каталог. Откуда тогда берется нагрузка?
Ответ обычно находится не среди посетителей. Современный сайт умеет выполнять довольно много работы самостоятельно. Пока владелец спит, создается резервная копия, WordPress проверяет обновления, плагин безопасности перебирает файлы, интернет-магазин синхронизирует остатки, система очищает старые данные, отправляет запланированные письма, а какой-нибудь давно забытый скрипт в соседней папке тоже решает, что сейчас самое подходящее время для запуска.
Ночь для сервера вообще не обязательно является временем отдыха. Наоборот, многие тяжелые задачи специально переносят на часы низкой посещаемости, чтобы они меньше мешали пользователям. Идея правильная. Проблемы начинаются, когда несколько таких задач запускаются одновременно или одна из них оказывается значительно тяжелее, чем предполагалось.
Именно поэтому письмо хостера о превышении ресурсов в 04:17 не доказывает, что на сайт внезапно пришла армия посетителей или его обязательно атаковали. Возможно, сайт просто занимался своими ночными делами.
Сайт продолжает работать, даже когда на нем никого нет
Простой HTML-сайт действительно может почти ничего не делать без посетителей. Файлы лежат на диске и ждут запроса. Но большинство современных проектов устроено сложнее. WordPress, интернет-магазины, форумы и другие CMS постоянно выполняют фоновые операции.
Один из механизмов, который позволяет запускать задачи по расписанию, называется Cron. Если не уходить в устройство операционных систем, его можно представить как будильник для сервера. В определенное время он говорит: пора выполнить вот эту команду.
Например, каждую ночь в 02:00 можно запускать резервное копирование. Раз в час обновлять данные из внешней системы. Каждые десять минут обрабатывать очередь. Раз в сутки удалять старые временные файлы.
У WordPress есть еще собственный механизм WP-Cron. Он используется для публикации записей по расписанию, выполнения некоторых обновлений и работы плагинов. Название немного обманчиво: по умолчанию это не совсем обычный системный Cron. Запуск задач может инициироваться обращениями к сайту. На активном проекте это происходит регулярно, а на малопосещаемом запланированная операция иногда выполняется позже ожидаемого просто потому, что долго не было подходящего запроса.
На некоторых сайтах WP-Cron заменяют настоящим системным заданием, которое запускает нужный обработчик через заданный интервал. Это позволяет сделать расписание более предсказуемым. Но сам факт использования системного Cron не уменьшает объем работы. Если задача тяжелая, она останется тяжелой независимо от того, каким способом ее запустили.
Хороший пример — интернет-магазин. Ночью он может выгружать заказы, получать остатки со склада, пересчитывать каталог или обновлять цены. Посетителей нет, но база данных получает тысячи операций. Со стороны панели хостинга это выглядит как вполне реальная нагрузка на CPU, память и диск.
Еще интереснее становится, если на одном аккаунте размещено несколько сайтов. Владельцу кажется, что каждый из них маленький. По отдельности это правда. Но в 03:00 первый начинает делать бэкап, второй запускает сканирование безопасности, третий формирует архив, четвертый импортирует товары. Для хостинга это уже не четыре маленьких сайта, а четыре одновременно работающих процесса.
Такая ситуация часто возникает после переноса проектов между разными площадками. Задания когда-то настраивались по инструкции, и в качестве времени выбиралось что-нибудь вроде «каждую ночь в три часа». Через несколько лет никто уже не помнит, почему именно в три, зато все сайты исправно просыпаются одновременно.
Поэтому при странных ночных пиках полезно первым делом посмотреть не посещаемость, а расписание. Панель хостинга, задания Cron, плагины резервного копирования, синхронизации, импорты и автоматические проверки иногда рассказывают о причине больше, чем счетчик посетителей.
Резервная копия может оказаться одной из самых тяжелых операций на сайте
Бэкап воспринимается как что-то спокойное и почти незаметное: система просто «сохраняет копию». На практике ей приходится прочитать большое количество файлов, получить содержимое базы данных, собрать все это в архив и записать результат на диск. Если копия отправляется во внешнее хранилище, затем добавляется передача большого объема данных по сети.
Чем больше сайт, тем заметнее работа. Особенно хорошо разрастаются WordPress-проекты с фотографиями. Сам движок занимает относительно немного места, но каталог uploads за несколько лет способен вырасти во много гигабайт. К оригинальным изображениям добавляются миниатюры разных размеров, созданные темой и плагинами.
Теперь представим ежедневный полный бэкап такого проекта. Сервер снова читает все эти файлы, архивирует их и сохраняет новый архив. Если старые копии лежат в той же директории, плохо настроенный плагин иногда может захватить в следующую копию еще и предыдущие архивы. Получается своеобразная матрешка, которая растет гораздо быстрее самого сайта.
Это один из ответов на загадку «почему на хостинге заканчивается место, хотя новых страниц почти не добавляли». Иногда контент сайта занимает меньшую часть диска, чем его резервные копии.
Создание архива нагружает не только диск. Сжатие требует процессорного времени. Работа с тысячами небольших файлов создает операции ввода-вывода. Экспорт большой базы тоже требует ресурсов. Поэтому во время резервного копирования сайт может временно отвечать медленнее, особенно на тарифе с небольшими лимитами.
Из этого не следует, что бэкапы нужно отключить ради скорости. Это примерно как снять тормоза с автомобиля ради уменьшения веса. Резервные копии нужны. Нужно лишь организовать их разумно.
Для начала стоит понять, кто вообще создает копии. Иногда бэкап уже делает сам хостер, а владелец дополнительно установил два WordPress-плагина, каждый со своим расписанием. В итоге ночью существуют три независимые системы резервирования, причем две складывают архивы прямо в аккаунт.
Дополнительная собственная копия может быть очень полезна, особенно если хранится отдельно от основного сервера. Но три одинаковых ежедневных полных архива не становятся втрое надежнее автоматически.
Имеет значение и время запуска. Если на аккаунте пять сайтов, нет необходимости заставлять их архивироваться в одну минуту. Задачи можно разнести по времени, чтобы нагрузка не складывалась.
Еще один источник неожиданностей — срок хранения. Допустим, один архив занимает 2 ГБ. Семь ежедневных копий уже требуют 14 ГБ дополнительно к самому сайту. Если хранится тридцать копий, арифметика становится еще интереснее.
Поэтому при нехватке ресурсов важно смотреть не только на тариф, но и на характер операций. В статье о CPU, RAM, I/O и лимитах хостинга мы подробно разбирали, чем отличаются разные виды ограничений. Ночной бэкап как раз хорошо показывает, почему одного показателя «сколько гигабайт дает тариф» недостаточно для оценки реальной нагрузки.
Обновления, безопасность и уборка тоже происходят без приглашения владельца
Резервные копии хотя бы легко представить. Но фоновых процессов намного больше.
WordPress и его плагины периодически проверяют обновления. В зависимости от настроек некоторые обновления могут устанавливаться автоматически. Во время установки система скачивает файлы, распаковывает их, заменяет старые версии и иногда выполняет изменения в базе данных.
Большую часть времени это проходит быстро. Но если одновременно обновляется несколько компонентов или сайт находится на медленном диске, нагрузка становится заметнее.
Плагины безопасности тоже любят ночное время. Сканирование сайта означает, что программе нужно пройти по множеству файлов, иногда сверить их с известными версиями, поискать подозрительные изменения и проверить базу. На небольшом проекте операция может быть почти незаметной. На старом WordPress с десятками тысяч файлов она превращается в серьезную работу.
При этом сам сканер безопасности способен быть причиной того, что владелец принимает за атаку. Он видит высокий I/O, активный процессор и почти нулевую посещаемость. Первая мысль — «кто-то ломает сайт». А сервер в этот момент честно проверяет сам себя.
Есть задачи по очистке. CMS и плагины накапливают временные данные, сессии, транзиенты, журналы, старые записи очередей. Кто-то должен периодически их удалять. Хорошо настроенная очистка помогает сайту. Плохо настроенная может сама стать источником проблем, если пытается за один запуск обработать огромный объем накопившихся данных.
Кэш тоже не существует вечно. Некоторые системы периодически очищают его и создают заново. После полной очистки первые запросы к страницам могут быть тяжелее обычного, потому что сервер снова формирует содержимое и записывает результат в кэш.
На контентных сайтах могут генерироваться карты сайта. В магазинах — фиды товаров для внешних площадок. Системы аналитики иногда агрегируют статистику. Плагины рассылок обрабатывают очереди писем. Оптимизаторы изображений сжимают загруженные файлы. Переводчики и индексаторы обходят контент.
Каждый отдельный процесс может быть вполне разумным. Проблему создает их сочетание.
Представим типичный WordPress, который несколько лет развивался без особого контроля. Один плагин делает бэкап в 02:00. В 02:05 начинается проверка безопасности. В 02:10 магазин импортирует каталог. В 02:15 оптимизатор пытается обработать новые изображения. Одновременно хостер запускает собственную системную задачу резервного копирования.
Ни одна операция сама по себе не является ошибкой. Но вместе они начинают конкурировать за процессор, память и диск. Сайт замедляется, задания выполняются дольше, из-за чего период их пересечения становится еще больше.
Самая неприятная ситуация возникает, когда задача не успевает закончиться до следующего запуска. Допустим, импорт должен выполняться каждые 15 минут, но из-за выросшего каталога теперь занимает 20. Если система допускает параллельные экземпляры, через некоторое время несколько импортов могут работать одновременно.
Так появляется нагрузка, которую невозможно объяснить количеством посетителей.
Поэтому расписание фоновых операций иногда полезно воспринимать как расписание взлетов в аэропорту. Если отправить все самолеты на одну полосу в одну минуту, наличие свободного аэропорта ночью не спасет.
Как найти ночную нагрузку, а не просто увеличить тариф
Когда хостер сообщает о превышении ресурсов, самое простое решение — перейти на более дорогой тариф. Иногда именно это и нужно. Если сайт вырос, посещаемость увеличилась и ресурсов объективно не хватает, дополнительная мощность решает проблему.
Но ночной пик при почти пустом сайте стоит сначала расследовать. Иначе более высокий тариф просто даст неудачно настроенному процессу больше пространства для работы.
Начните со времени. Не «сайт иногда грузит сервер», а «нагрузка появляется примерно с 02:00 до 02:40». Уже эта информация резко сужает поиск.
Затем посмотрите статистику хостинга. В зависимости от панели можно увидеть использование CPU, памяти, дисковых операций, количество процессов и иногда конкретные скрипты. Если пик повторяется ежедневно примерно в одно время, вероятность плановой задачи довольно высока.
Следующий шаг — Cron. Посмотрите все задания в панели, даже если не помните, зачем они создавались. Сравните расписание со временем пика.
После этого проверьте WordPress. Какие плагины выполняют бэкапы, сканирование, импорт, экспорт, рассылки или оптимизацию? Есть ли у них собственное расписание? Не работают ли одновременно два решения с одинаковой функцией?
Если на аккаунте несколько сайтов, проверять нужно каждый. Нагрузка хостинга часто отображается для всего аккаунта, поэтому виновником может оказаться не основной проект, а старый сайт, который почти никто не посещает.
Именно старые проекты бывают особенно коварны. Владелец давно перестал ими заниматься, но WordPress продолжает жить: Cron запускается, плагины проверяют обновления, бот обращается к страницам, база растет, журналы записываются. Сайт может не приносить ни одного посетителя и при этом потреблять вполне реальные ресурсы.
Если причина найдена, не спешите отключать все фоновые задачи. Сначала разберитесь, нужна ли каждая из них. Резервное копирование нужно оставить, но, возможно, изменить расписание. Сканирование безопасности можно перенести на другое время. Импорт стоит оптимизировать или запускать реже. Несколько тяжелых задач можно развести по часам.
Иногда помогает изменение самого типа резервного копирования. Не всегда требуется каждый раз архивировать весь многогигабайтный сайт. Конкретная схема зависит от проекта и используемого решения, но смысл один: резервирование должно обеспечивать восстановление, а не создавать нагрузку ради самого факта создания огромного архива.
Если процесс непонятен, полезно обратиться в поддержку хостинга не с вопросом «почему тормозит?», а с конкретными данными: «каждую ночь примерно в 03:20 резко растет CPU, можете подсказать, какой процесс или скрипт работает в это время?» Такой запрос значительно проще расследовать.
И не забывайте, что медленная работа может иметь совсем другую природу. Если сайт тормозит постоянно, а не только во время фоновых задач, причина может находиться в базе, теме, плагинах, внешних сервисах или самом тарифе. Для такого случая у нас есть отдельный разбор причин медленной загрузки сайта.
После оптимизации фоновых процессов стоит снова посмотреть графики. Если ночной пик исчез или заметно уменьшился, проблема была не в недостаточной мощности хостинга как таковой. Если задачи действительно необходимы, настроены разумно, но сервер все равно регулярно достигает лимитов, тогда увеличение ресурсов уже имеет техническое обоснование.
Это важная разница. Покупать более мощный тариф стоит потому, что сайту нужна дополнительная мощность, а не потому, что никто не захотел выяснить, куда исчезает текущая.
Ночью сайт не спит, и это нормально
Сам по себе ночной расход ресурсов не является проблемой. Сервер для того и существует, чтобы работать. Если тяжелые операции специально выполняются в часы низкой посещаемости, это зачастую признак нормальной настройки.
Плохо другое: когда владелец не знает, какие процессы запускаются, несколько задач мешают друг другу, архивы бесконтрольно копятся на диске, а любой пик автоматически лечится покупкой следующего тарифа.
Полезно хотя бы один раз составить для своего сайта небольшую карту фоновой жизни. Когда делаются бэкапы? Где они хранятся? Есть ли системный Cron? Какие плагины запускают свои задачи? Когда работает импорт? Есть ли автоматическое сканирование? Что происходит с почтовыми очередями?
Для одного небольшого WordPress список может занять пять минут. Для нескольких сайтов на одном аккаунте он уже способен объяснить множество странностей.
А еще такая проверка хорошо показывает реальную ценность ресурсов хостинга. Посещаемость является только одной частью нагрузки. Два сайта с одинаковым количеством посетителей могут требовать совершенно разной мощности, потому что один просто отдает кэшированные страницы, а второй постоянно импортирует данные, создает архивы и работает с большой базой.
Поэтому выбирать хостинг только по дисковому пространству или обещанию подходит для десяти сайтов не очень полезно. Важно, что эти сайты делают.
Если после проверки становится понятно, что проект действительно перерос текущие ограничения, тогда уже имеет смысл сравнивать более подходящие варианты размещения. Но сначала лучше убрать случайную нагрузку. Переезд на новый сервер вместе с тремя одновременно работающими бэкапами не превращает их в хорошую настройку.
И в следующий раз, увидев на графике загадочный пик в четыре утра, не спешите искать ночных посетителей. Возможно, в этот момент сайт просто решил прибраться, проверить себя на вирусы, собрать чемодан с резервной копией и заодно обновить каталог. Все по отдельности полезно. Главное, чтобы он не пытался сделать это одновременно.
