Превышение лимитов — состояние хостингового аккаунта, при котором потребление ресурсов (CPU, оперативная память, дисковое пространство, трафик, количество соединений с БД) выходит за рамки, определённые тарифным планом. Реакция хостера зависит от типа ресурса и политики провайдера: от мягкого ограничения (throttling) до полной блокировки аккаунта.
Виды лимитов и последствия превышения
| Ресурс | Способ измерения | Последствие превышения |
|---|---|---|
| CPU | Секунды CPU в час/сутки | Процессы замедляются или принудительно завершаются |
| RAM | МБ в момент пика | OOM Killer убивает процессы, PHP возвращает 503 |
| Трафик (исходящий) | ГБ в месяц | Шейпинг скорости или блокировка до конца месяца |
| Диск | ГБ (inode) | Запись новых файлов заблокирована, сайт падает |
| Соединения с БД | Одновременных подключений | Ошибка «Too many connections», сайт недоступен |
| Inodes | Количество файлов/директорий | Невозможно создать новые файлы (в т.ч. временные) |
На shared hosting CPU-лимиты — наиболее частая причина проблем. WordPress с десятками плагинов и кэшем может потреблять 30–60 секунд CPU в сутки — некоторые хостеры устанавливают лимит 20–30 секунд. При превышении сайт получает ответ 503 Service Unavailable.
На VPS ситуация иная: ресурсы выделены гарантированно, и «превышение» касается только трафика и диска. Трафик свыше включённого в тариф тарифицируется дополнительно (обычно 2–5 руб./ГБ). При заполнении диска VPS вешаются процессы, требующие записи — nginx/php-fpm начнут падать.
Как работает мониторинг лимитов
Хостеры измеряют CPU-нагрузку через механизмы ядра Linux: cgroups (control groups) — технология изоляции и ограничения ресурсов. Каждый аккаунт помещается в отдельную cgroup с лимитами CPU (cpu.cfs_quota_us), памяти (memory.limit_in_bytes) и I/O. При превышении cgroups автоматически ограничивают процесс, не завершая его — это отличается от OOM Killer, который убивает процессы при нехватке памяти.
Трафик считается через NetFlow или iptables-счётчики. При приближении к лимиту (биллинг-панель обычно уведомляет на 80%, 90%, 100%) клиент получает email-уведомление.
История
Концепция ресурсных лимитов в хостинге появилась вместе с появлением shared hosting в 1990-е, когда один сервер обслуживал тысячи клиентов. Ранние системы просто убивали процессы при превышении. С появлением cgroups в ядре Linux 2.6.24 (2008) хостеры получили точный инструмент дросселирования без падения процессов. Контейнеризация через Docker и LXC в 2010-е сделала изоляцию ресурсов ещё точнее.
На что обращать внимание
При частых превышениях CPU на shared hosting — сначала профилируйте: медленные SQL-запросы, N+1 проблема в ORM, отключённый OPCache — часто дают 10-кратный прирост без смены тарифа. Включите Redis-кэш для WordPress — снизит число PHP-запросов на 60–80%. Если лимиты превышаются регулярно — переходите на VPS: стоимость отличается в 2–5 раз, но ресурсы гарантированы. Следите за inodes: бэкап-плагины WordPress (BackupBuddy, UpdraftPlus) создают тысячи мелких файлов и быстро исчерпывают inode-лимит даже при достаточном дисковом пространстве.
Как избежать превышения
Оптимизация ресурсов на shared hosting: включите OPcache для PHP (снижает CPU в 5-10 раз), Redis для кэша объектов (снижает запросы к БД), CDN для статики (разгружает сервер). На VPS при систематическом превышении: вертикальное масштабирование (upgrade тарифа в биллинге) или горизонтальное (дополнительные ноды). Docker с --memory и --cpus ограничивает ресурсы контейнера. Контейнеризация через LXC/Docker позволяет провайдеру изолировать клиентов — превышение одного не влияет на других. Тарифный план с оплатой по факту (pay-as-you-go) подходит при нерегулярных пиках нагрузки.