Предел числа сайтов в панели управления: когда панель тормозит сильнее сайтов

MAATRIX

Сервер с полусотней сайтов, где сами сайты живут спокойно — CPU не загружен, память не кончается, диск не упирается в IOPS, — а веб-интерфейс панели управления открывается по десять секунд, список доменов подгружается с видимой паузой, а создание нового аккаунта зависает на полминуты. Это не редкий частный случай, а закономерность: у панелей управления хостингом есть собственная стоимость, которая растёт вместе с числом сайтов быстрее, чем растёт нагрузка от самих сайтов. Разберём, откуда берётся этот эффект, как отделить его от реальной нагрузки и когда имеет смысл переходить на голую конфигурацию без панели.

Почему панель тормозит раньше, чем сайты

Сайт — это статические файлы или процесс приложения, который ест ресурсы пропорционально трафику: нет запросов — нет нагрузки. Панель управления устроена принципиально иначе: у неё есть операции, которые требуют пройти по *всем* размещённым сайтам разом, независимо от того, обращается к ним кто-то в этот момент или нет.

Типичные примеры такой архитектуры:

• Список доменов/аккаунтов в интерфейсе. Чтобы отрисовать таблицу со статусом каждого сайта (место на диске, квота, статус SSL, последний бэкап), панель на каждый рендер либо читает состояние из своей базы, если она поддерживается в актуальном виде фоновыми задачами, либо опрашивает файловую систему и конфиги напрямую — линейная операция, растущая вместе с числом сайтов.
• Генерация статистики трафика. Панели традиционно строят отчёты по посещаемости через разбор логов веб-сервера — раньше чаще инструментами вроде awstats или webalizer, сейчас чаще собственным парсером панели. В любом случае это проход по логам каждого домена, и объём работы растёт с числом доменов и объёмом их логов одновременно.
• Проверка квот и использования диска. Периодический пересчёт «сколько места занимает каждый аккаунт» без встроенных квот ФС — это обход дерева каталогов каждого сайта.
• Пересборка конфигурации веб-сервера и почты. Многие панели не пишут в конфиг точечно при изменении одного сайта, а перегенерируют файлы целиком или большими блоками — стоимость зависит от общего числа сайтов, а не от того, какой именно вы изменили.
• Проверка сертификатов и их автопродление. Обход всех доменов с проверкой срока действия сертификата — тоже линейная операция по всему списку.

Общая черта всех этих механизмов: их стоимость определяется не трафиком на сайты, а количеством *объектов*, которыми панель управляет. Сайт с нулевым трафиком всё равно попадает в каждый такой обход наравне с самым нагруженным доменом. Поэтому сервер с ничтожной реальной нагрузкой от посетителей, но большим числом доменов, может ощущать заметные тормоза именно в панели — при том что «полезная» часть сервера простаивает.

Что панель пересканирует на каждую операцию

Ключевой вопрос — что именно из перечисленного выше происходит по расписанию в фоне, а что — синхронно, прямо в момент, когда вы кликаете кнопку в интерфейсе. Разница принципиальна для восприятия проблемы.

Фоновые задачи (обычно через cron) обычно не блокируют интерфейс напрямую, но конкурируют с сайтами за CPU и диск в моменты своего запуска — если такая задача идёт по всем сотням доменов раз в час, вы получите регулярный всплеск нагрузки по расписанию, который на графике мониторинга виден как пила, не связанная с трафиком на сайты. Проверить, какие cron-задачи панель заводит от своего имени, можно так:

# Задачи системного cron-пользователя, под которым работает панель
crontab -u root -l | grep -i -E 'panel|isp|cpanel|plesk'
cat /etc/cron.d/* 2>/dev/null | grep -i -E 'panel|isp|cpanel|plesk'

# Активность в момент выполнения — какие процессы панели ели ресурсы
ps aux --sort=-%cpu | head -20

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

Отдельная категория — создание и удаление сайта. В большинстве панелей это не изолированная операция «создать одну запись», а транзакция, которая трогает несколько подсистем разом: DNS-зону, виртуальный хост веб-сервера, почтовый домен, файловую систему, права доступа, иногда — перечитывание общей конфигурации веб-сервера целиком. Если перегенерация конфига устроена как полная пересборка, а не точечная правка, время создания одного нового сайта на сервере с полусотней доменов будет заметно больше, чем на пустом сервере — хотя логически это одна и та же операция.

Как отличить нагрузку панели от нагрузки самих сайтов

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

Порядок диагностики:

# 1. Кто ест CPU и память прямо сейчас — процессы панели видны по имени
top -o %CPU
# или с сортировкой и без интерактива
ps aux --sort=-%cpu | head -30
ps aux --sort=-%mem | head -30

# 2. Кто ест диск — веб-процессы сайтов или процессы панели
iotop -o -b -n 5

# 3. Соотнести всплески CPU/диска с расписанием cron панели
grep CRON /var/log/syslog | tail -50
# или, если панель ведёт собственный лог
tail -f /usr/local/<панель>/logs/*.log 2>/dev/null

Практичный способ разделить нагрузку — сравнить два состояния сервера: пиковый трафик на сайты в обычное время суток и момент запуска фоновой задачи панели (статистика, квоты, бэкап-индексация). Если нагрузка растёт заметно сильнее в момент задачи панели, чем в момент пикового трафика на сайты, — узкое место в панели.

Второй способ — временно, на малонагруженном окне, отключить конкретную фоновую задачу панели через её настройки (генерацию статистики и авто-квоты обычно можно выключить или разредить в интерфейсе) и посмотреть, снизилась ли базовая нагрузка сервера в покое. Если да — источник найден, и дальше решаете точечно: реже считать статистику, кешировать значения на странице списка доменов, переносить бэкапы на менее пиковое время — необязательно сразу отказываться от панели целиком.

Третий признак — время отклика веб-интерфейса панели в сравнении со временем ответа сайтов через тот же веб-сервер. Если сайты отвечают быстро, а порт интерфейса панели — заметно медленнее при той же общей загрузке, это прямое указание, что тормозит панель как отдельное приложение (обычно она работает на своём веб-сервере или воркере, отдельном от nginx, который обслуживает сайты).

Симптомы: где это видно на практике

Набор типичных признаков того, что предел — именно в панели, а не в самих сайтах:

• Список доменов/аккаунтов в интерфейсе открывается заметно дольше, чем несколько лет назад на этом же сервере, хотя сами сайты работают штатно.
• Создание нового сайта или домена занимает секунды на пустом сервере и десятки секунд — на сервере с большим числом уже существующих доменов.
• В графике мониторинга видна регулярная «пила» CPU/диска в одно и то же время суток или с одинаковым интервалом, не совпадающая с пиками трафика на сайты — характерный след фоновой задачи по расписанию.
• Файловый менеджер или бэкап-модуль панели зависает или отвечает с заметной задержкой именно на операциях, которые требуют обхода списка всех сайтов (например, общий бэкап всех аккаунтов, а не одного конкретного).
• SSH и работа с самими файлами сайтов напрямую (без панели) остаются быстрыми, а операции через веб-интерфейс панели — нет. Это разделение — сильный сигнал, что дело не в диске и не в сети, а в логике самой панели.

Стоит отдельно отметить: медленный веб-интерфейс панели — не то же самое, что медленные сайты. Часто администратор сервера видит тормоза в своей же панели и делает вывод «сервер перегружен», хотя посетители сайтов вообще ничего не замечают — узкое место затрагивает только административный интерфейс, а не отдачу контента.

Когда панель становится узким местом, а когда ещё рано

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

Важная оговорка: это ориентир на порядок величины, а не измеренный бенчмарк — конкретные цифры сильно зависят от версии и настроек панели, от объёма логов на сайт, от диска (NVMe заметно снисходительнее к обходу файловой системы, чем сетевое хранилище) и от того, насколько активно вы используете функции, требующие полного обхода. Проверяйте на своём сервере методами из предыдущего раздела, а не полагайтесь на чужую таблицу.

Отдельно стоит развести «панель тормозит» и «сервер перегружен». Если по метрикам CPU, памяти и диска сервер загружен близко к пределу вне зависимости от того, панель это или сайты, — вопрос не в архитектуре панели, а в том, сколько сайтов вообще можно повесить на один сервер физически при данном объёме ресурсов. Переход на голую конфигурацию не добавит CPU или памяти — он снимет только ту часть нагрузки, которую создаёт сама панель поверх нагрузки от сайтов.

Голый nginx + ansible: что даёт отказ от панели

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

Структура на файловой системе выглядит примерно так же, как и без панели вообще, только управляется не руками, а плейбуком:

/etc/nginx/sites-available/
├── site1.example.com.conf
├── site2.example.com.conf
└── ...

Ansible-роль на один сайт — шаблон конфига плюс задачи создания каталога, выпуска сертификата и включения хоста:

# roles/nginx-site/tasks/main.yml
- name: Конфиг виртуального хоста
  template:
    src: site.conf.j2
    dest: "/etc/nginx/sites-available/{{ site_domain }}.conf"
  notify: reload nginx

- name: Каталог сайта
  file:
    path: "/var/www/{{ site_domain }}"
    state: directory
    owner: "{{ site_user }}"

- name: Включить хост
  file:
    src: "/etc/nginx/sites-available/{{ site_domain }}.conf"
    dest: "/etc/nginx/sites-enabled/{{ site_domain }}.conf"
    state: link
  notify: reload nginx

Добавление нового сайта — это запуск плейбука с одной новой переменной site_domain, а не транзакция, трогающая конфигурацию всех уже существующих доменов. reload nginx перечитывает конфигурацию быстро и не зависит линейно от числа доменов так, как зависит полная пересборка конфигурации панелью — механизм include в nginx не требует пересобирать файлы других сайтов при добавлении одного нового. Где у самого nginx проходит реальный технический предел по числу виртуальных хостов — в статье сколько доменов повесить на один сервер.

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

Плата за это — то, что раньше делала панель одним кликом, теперь требует явного описания в плейбуке: SSL, почтовые домены, бэкапы, права доступа, ротация логов. Что именно перестаёт работать «само» при уходе от панели и как закрыть каждый пункт руками — в статье переезд с cPanel на голый сервер. Там же видна и обратная сторона — эта работа не бесплатна по времени инженера, и для небольшого числа сайтов она может быть дороже, чем накладные расходы панели, которые вы пытаетесь устранить.

Частые вопросы