Квоты на шаред-хостинге: как измерить, сколько вам на самом деле дали

MAATRIX

В тарифе написано «неограниченный трафик» и «CPU без ограничений», но сайт подвисает ровно в момент всплеска посетителей, а фоновый скрипт обрывается без внятной ошибки в логе. Реального описания вашей квоты панель хостинга почти никогда не показывает — за словом «unlimited» обычно стоит cgroups-лимит или лимит CloudLinux LVE, число которого хостер вслух не называет. Дальше — как измерить, что вам выделено на самом деле, не выходя за рамки своего аккаунта, и как отличить обычный всплеск нагрузки от упора в потолок, который назначили не вы.

Почему «unlimited» — это маркетинг, а не техническая характеристика

Экономика шаред-хостинга держится на переподписке: на одном физическом сервере живут сотни аккаунтов, и провайдер закладывает, что одновременно нагружают CPU далеко не все. «Unlimited» исторически означало «нет жёсткого числа в мегабайтах трафика или гигабайтах диска в прайсе» — но к вычислительным ресурсам это давно не относится буквально. Почти все современные шаред- и реселлер-хостинги на Linux ограничивают каждый аккаунт через cgroups напрямую или через надстройку CloudLinux (LVE — Lightweight Virtual Environment), и делают это осознанно: без лимита один PHP-скрипт с бесконечным циклом положит CPU всем соседям по серверу.

Формальная квота обычно прописана не в тарифе, а в Acceptable Use Policy — «fair usage», «разумное использование», иногда с абстрактной фразой вроде «ресурсы, сопоставимые с типичным сайтом такого объёма». Конкретные числа (доля CPU, лимит процессов, память на процесс) хостер публикует редко: это одновременно защита от юридических претензий и способ не давать конкурентам ориентир для демпинга. Отсюда вывод: цифру придётся не искать в документации, а измерять самому — благо для этого достаточно обычного доступа внутри аккаунта, без прав root.

Что реально скажет ulimit -a

Если у хостинга есть SSH или хотя бы Terminal в панели (jailshell в cPanel тоже подходит), первая команда — ulimit -a. Она показывает лимиты, которые PAM (pam_limits) навесил на вашу оболочку, и это не абстракция, а конкретные цифры, которые хостер задал именно для вас:

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 150
virtual memory          (kbytes, -v) unlimited

Значения у каждого хостера свои, но логика чтения одинаковая:

• -u (max user processes) — сколько процессов и потоков одновременно может иметь ваш пользователь. Это частая причина «fork failed» или зависших очередей: воркер пытается поднять пятый параллельный процесс, а лимит — четыре.
• -n (open files) — лимит файловых дескрипторов на процесс. При 1024 nginx или PHP-FPM с большим числом одновременных соединений упрётся быстрее, чем кажется.
• -m / -v (memory size) — на многих шаред-хостингах здесь стоит unlimited, потому что реальный лимит памяти управляется не через ulimit, а через cgroup снаружи процесса. Не спешите радоваться «безлимиту» — это просто значит, что измерять память нужно другим способом (см. следующий раздел).
• -t (cpu time) — лимит процессорного времени на один процесс в секундах. Если стоит конкретное число, а не unlimited, долгий скрипт (импорт, генерация отчёта) будет принудительно убит по истечении этого времени независимо от загрузки сервера.

Важная деталь: ulimit -a без флага показывает soft-лимиты, а ulimit -Ha — hard-лимиты, до которых процесс теоретически может себя поднять сам (ulimit -n 4096), если hard-лимит это позволяет. На шаред-хостинге soft и hard обычно совпадают — то есть поднять их самостоятельно нельзя, это и есть ваш потолок.

Cgroups и /proc: ищем свой реальный слепок ресурсов

Ulimit — только часть картины: это лимиты уровня процесса, а квоты CPU и памяти на шаред-хостинге почти всегда реализованы через cgroups на уровне контейнера или LVE-обёртки. Если у вас есть доступ к shell, стоит проверить, что видно в /proc и /sys/fs/cgroup — многие хостеры это не закрывают, потому что файлы read-only и не раскрывают ничего о соседях.

Сначала определите версию cgroups и свой путь:

$ cat /proc/self/cgroup
0::/user.slice/user-1000.slice/lve/1000

Дальше, если это cgroups v2 (единая иерархия), полезные файлы лежат по пути из вывода выше, внутри /sys/fs/cgroup/...:

Если сервер на устаревшей cgroups v1, ищите аналоги в /sys/fs/cgroup/cpu/cpu.cfs_quota_us и cpu.cfs_period_us (то же соотношение quota/period), /sys/fs/cgroup/memory/memory.limit_in_bytes и /sys/fs/cgroup/cpuset/cpuset.cpus (список ядер, к которым у вас вообще есть доступ). Подробный разбор механики quota/period и того, что происходит в момент упора — в статье как cgroups ограничивают контейнер.

Отдельно: не доверяйте /proc/meminfo, /proc/cpuinfo и выводу nproc без оговорок — на многих шаред-конфигурациях это данные всего физического сервера, а не вашей квоты, и обычный nproc покажет число ядер хоста, даже если реально вам выделены доли одного. Смотрите cat /sys/fs/cgroup/cpu.max и делите quota на period — это и есть ваш настоящий потолок в vCPU.

Если хостинг на CloudLinux (это большинство cPanel-провайдеров), у вас, скорее всего, есть более удобный источник — панель «Resource Usage» в cPanel. Она показывает в реальном времени CPU%, физическую и виртуальную память, I/O, IOPS, число «entry processes» и NPROC, а главное — счётчик Faults: сколько раз за период вы реально упёрлись в лимит по каждому параметру. Это самый честный индикатор из всех: если Faults по CPU растёт при обычной нагрузке — квота реально мала для вашей задачи, а не показалась мала.

Осторожные нагрузочные тесты внутри своего аккаунта

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

Проверка CPU без сторонних утилит — просто замер времени на предсказуемой задаче:

$ time php -r '$x=0; for($i=0;$i<50000000;$i++){$x+=sqrt($i);} echo $x;'

Смотрите не только на real (astral wall-clock), но и на соотношение real к user+sys. Если real заметно больше суммы user+sys при том, что вы на сервере одни (никаких параллельных заданий не запускали) — это косвенный признак, что процесс не получал CPU-время непрерывно, то есть вас притормаживали снаружи. Если под рукой есть stress-ng (на шаред-хостинге чаще нет, ставить самому не стоит — вероятно, нарушение AUP), достаточно stress-ng --cpu 1 --timeout 5s --metrics-brief в разрешённой sandbox-среде.

Проверка памяти — плавным приращением, а не одним прыжком на гигабайты:

$ php -r '$a = str_repeat("x", 100*1024*1024); echo memory_get_peak_usage(true), PHP_EOL;'

Увеличивайте 100*1024*1024 шагами по 100 МБ и смотрите, на каком шаге процесс не завершится штатно, а будет убит без вывода вообще (это и есть сигнал упора в cgroup memory.max, а не в ulimit). Проверка диска — аккуратный dd с немедленной очисткой:

$ dd if=/dev/zero of=test.bin bs=1M count=50 oflag=direct
$ rm -f test.bin

Не зацикливайте эти команды и не запускайте параллельно несколько копий — цель теста понять свой потолок, а не проверить его на прочность до бана аккаунта.

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

Прямого сообщения «вы превысили квоту CPU» шаред-хостинг чаще всего не даёт — вместо этого вы видите последствия, из которых причину нужно восстанавливать самому.

Прямого доступа к dmesg и логу ядра на шаред-хостинге у вас, как правило, нет (permission denied) — это нормально, ядро принадлежит хосту, а не вашему аккаунту. Поэтому OOM-события на шаред-хостинге приходится восстанавливать по косвенным следам: код возврата 137, пустой ответ вместо ожидаемого, обрыв ровно на характерном объёме данных. Логика, по которой ядро вообще выбирает жертву при нехватке памяти, разобрана в статье как ядро Linux выбирает, какой процесс убить — общий алгоритм тот же, но на шаред-хостинге он применяется к вашему cgroup-слайсу, а не ко всей машине.

Отдельно стоит отличать «мне не дали ресурс» от «ресурс есть, но его ест сосед по физическому серверу» — второе для VPS и для некоторых виртуализированных шаред-конфигураций проверяется через steal time (%st в top/vmstat), подробнее — в статье steal time: как понять, что сосед ест ваш CPU. Если проблема плавает без привязки к вашей собственной нагрузке — вероятно, это оно, и никакие ulimit/cgroup-измерения внутри вашего аккаунта её не покажут, потому что дело не в вашей квоте.

Когда шаред-хостинг пора менять на VPS

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

• throttled_usec в cpu.stat заметно растёт именно в часы вашей реальной нагрузки, а не случайным образом;
• Faults по CPU/памяти в панели CloudLinux (если она есть) появляются регулярно, а не разово;
• вы упираетесь в pids.max/ulimit -u при попытке масштабировать что-то штатное — очередь воркеров, параллельные cron-задачи;
• реальная измеренная квота (доля vCPU, память) меньше, чем нужно вашему проекту уже сейчас, без учёта роста;
• вы тратите больше времени на обход лимитов (кэширование через боль, дробление скриптов, чтобы уложиться в cpu time), чем на саму задачу.

Экономику самого перехода — во сколько обходится VPS против шаред-тарифа с учётом вашего времени и потерянных из-за тормозов посетителей — стоит посчитать отдельно, это разобрано в статье когда пора уходить с шаред-хостинга. Главное отличие VPS с явно выделенными ресурсами не в том, что лимитов не будет вообще — они тоже есть, просто это ваш собственный cgroup, который вы сами видите и сами настраиваете, а не чужой, скрытый за словом «unlimited». Способы измерения из этой статьи одинаково работают и там: cpu.max, cpu.stat, memory.max на VPS читаются точно так же — разница в том, что там вы точно знаете, какое число туда изначально заложили и почему.

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