На виртуальном хостинге сработал лимит ресурсов: как понять, чего не хватает

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

Для разговора с поддержкой достаточно пяти фактов: какой аккаунт или домен учитывался, название лимита, его значение, фактический пик и число faults за один и тот же интервал. Средний график за сутки без этих данных легко показывает спокойствие именно тогда, когда сайт коротко упирался в потолок.

Ниже речь только о хостинге с CloudLinux LVE — изолированной средой, которая учитывает и ограничивает ресурсы аккаунта. В другой платформе названия и логика метрик могут отличаться, поэтому сначала уточните технологию у провайдера.

В пользовательской статистике CloudLinux для ресурса могут показываться usage, limit и fault: фактическое использование, настроенный предел и число срабатываний ограничителя. Fault не обязательно означает отказ HTTP-запроса: при ограничении CPU или IO работа может продолжаться медленнее. В истории дополнительно встречаются A, L и F — среднее, лимит и faults за выбранный период.

Среднее A ниже лимита ещё не исключает короткого срабатывания. Пик мог уложиться между точками агрегирования, а счётчик F уже зафиксировал достижение ограничения. Поэтому попросите историю с тем же часовым поясом и интервалом, в котором магазин тормозил или вернул ошибку.

CloudLinux документирует общее поведение так: достижение CPU или IO обычно замедляет ответ; нехватка памяти или процессов может сопровождаться ошибками 500 либо 503; предел EP может привести к 508. Код ответа — ориентир, а не диагноз: одинаковая ошибка бывает и по другим причинам.

IO ограничивает объём данных в секунду, а IOPS — число операций в секунду. Импорт большого файла способен приблизиться к IO. Множество мелких дисковых операций при работе с файловым кэшем, сессиями или файлами может упереться в IOPS при умеренном потоке данных. При этом чтение из дискового кэша в оперативной памяти CloudLinux не учитывает в лимите IO: обращения к кэшу нельзя автоматически считать физическим чтением диска. Поэтому фраза «диск занят на 20%» без единицы измерения и нужного интервала ничего не решает.

На обычной схеме несколько сайтов одного клиента могут учитываться в общем LVE аккаунта. Тогда всплеск на тестовом сайте, задание cron или импорт в одном магазине влияет на доступный ресурс соседнего домена.

CloudLinux поддерживает отдельные LVE для доменов, но эта возможность требует CloudLinux Isolates, серверного разрешения и дополнительных компонентов. Само наличие CageFS не доказывает, что ресурсы считаются по каждому сайту отдельно. В запросе поддержке прямо укажите домен и попросите назвать область учёта: весь аккаунт или конкретный домен.

Пароли, ключи доступа, содержимое сессий покупателей и полные журналы с персональными данными в обращение не копируйте. Если поддержке нужны журналы, согласуйте безопасный канал и минимальный фрагмент.

Повышение лимита обосновано, если faults повторяются при обычной полезной нагрузке, понятен затронутый ресурс и новый тариф действительно увеличивает именно его. Сравните не название тарифа, а SPEED, PMEM, IO, IOPS, EP и NPROC, цену первого срока и продления, резервные копии и условия поддержки.

Если faults возникли один раз во время импорта, сканирования или резервного копирования, сначала разнесите тяжёлые задачи по времени и проверьте результат. Если faults нет, а сайт медленный, причина может быть вне LVE: очередь PHP-FPM, база данных, внешний API, DNS, сеть или код приложения.

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

Документированное поведение и названия показателей сверены с CloudLinux 25 октября 2026 года. Конкретные значения лимитов задаёт хостинг-провайдер; эта статья не измеряет ваш сайт и не назначает универсальный тариф.

If your virtual hosting control panel reports resource exhaustion, do not start by asking to add a processor. In CloudLinux, a single account can simultaneously have multiple independent limits: for CPU, memory, speed, disk operations, incoming requests, and processes. The solution depends on which limit triggered faults during the issue.

To contact support, five facts are sufficient: which account or domain was involved, the limit name, its value, the actual peak, and the number of faults within the same interval. Without these data, the average daily graph can easily appear calm precisely when the site briefly hit the ceiling.

The following discussion applies only to hosting with CloudLinux LVE—an isolated environment that accounts for and restricts account resources. On other platforms, metric names and logic may differ, so first confirm the technology with your provider.

In CloudLinux user statistics for a resource, you may see usage, limit, and fault: actual usage, the configured limit, and the number of limit triggers. A fault does not necessarily mean an HTTP request failed: when CPU or I/O is throttled, the process may continue but run slower. The history also includes A, L, and F: average, limit, and faults for the selected period.

An average A below the limit does not rule out a brief trigger. The peak could have occurred between aggregation points, while the F counter already recorded that the limit was reached. Therefore, request history using the same time zone and interval during which the store slowed down or returned an error.

CloudLinux documents the general behavior as follows: reaching CPU or I/O limits usually slows the response; memory or process shortages may trigger 500 or 503 errors; an EP limit can lead to a 508 error. The status code is a clue, not a diagnosis: the same error can occur for other reasons.

IO limits the volume of data per second, while IOPS limits the number of operations per second. Importing a large file can approach the IO limit. Many small disk operations during file cache usage, session handling, or file processing can hit the IOPS limit even with moderate data throughput. However, reading from the disk cache in RAM on CloudLinux does not count toward the IO limit: cache accesses cannot be automatically treated as physical disk reads. Therefore, the phrase "disk is 20% busy" without a unit of measurement and a specified time interval is meaningless.

On a standard scheme, multiple sites belonging to one client may be counted together within the account's overall LVE. In this case, a spike on a test site, a cron job, or an import in one store can affect the available resources for a neighboring domain.

CloudLinux supports separate LVEs for domains, but this feature requires CloudLinux Isolates, server-level permissions, and additional components. The mere presence of CageFS does not prove that resources are counted separately for each site. In your support request, explicitly specify the domain and ask them to name the accounting scope: the entire account or a specific domain.

Do not copy passwords, access keys, shopper session contents, or full logs containing personal data into your support request. If support needs logs, agree on a secure channel and the minimal necessary fragment.

Increasing the limit is justified if faults recur under normal load, the affected resource is clear, and the new tariff actually increases that specific resource. Compare not the tariff name, but SPEED, PMEM, IO, IOPS, EP, and NPROC, the price for the first term and renewal, backups, and support conditions.

If faults occurred only once during import, scanning, or backup, first stagger heavy tasks over time and check the result. If there are no faults but the site is slow, the cause may be outside LVE: PHP-FPM queue, database, external API, DNS, network, or application code.

Diagnostics are complete when, for a single event, the domain or account, time interval, limit name, its value, actual usage, faults, and the concurrent operation are recorded. After making changes, repeat the same check. The disappearance of a warning without a comparable time interval does not prove the cause has been resolved.

Documented behavior and indicator names were verified against CloudLinux on October 25, 2026. Specific limit values are set by the hosting provider; this article does not measure your site or assign a universal tariff.