Virtual Hosting Resource Limit Triggered: How to Determine What Is Missing
We analyze SPEED, PMEM, IO, IOPS, EP, and NPROC in CloudLinux: what data to request from support, how peaks differ from faults, and when upgrading a plan is truly justified.
In this article
- Focus on limit triggers, not just high graphs
- Six limits answer different questions
- Why I/O and IOPS cannot be combined into a single disk
- Clarify: does the limit apply to the account or to the domain?
- What to send to support
- When to change the tariff plan versus when to search for the root cause
- What result counts as sufficient
Если панель виртуального хостинга сообщает об исчерпании ресурсов, не начинайте с просьбы «добавить процессор». В CloudLinux один аккаунт может одновременно иметь несколько независимых пределов: по процессору, памяти, скорости и числу операций диска, входящим запросам и процессам. Решение принимают по тому лимиту, у которого за время проблемы появились срабатывания — faults.
Для разговора с поддержкой достаточно пяти фактов: какой аккаунт или домен учитывался, название лимита, его значение, фактический пик и число faults за один и тот же интервал. Средний график за сутки без этих данных легко показывает спокойствие именно тогда, когда сайт коротко упирался в потолок.
Ниже речь только о хостинге с CloudLinux LVE — изолированной средой, которая учитывает и ограничивает ресурсы аккаунта. В другой платформе названия и логика метрик могут отличаться, поэтому сначала уточните технологию у провайдера.
Смотрите не на высокий график, а на срабатывание лимита
В пользовательской статистике CloudLinux для ресурса могут показываться usage, limit и fault: фактическое использование, настроенный предел и число срабатываний ограничителя. Fault не обязательно означает отказ HTTP-запроса: при ограничении CPU или IO работа может продолжаться медленнее. В истории дополнительно встречаются A, L и F — среднее, лимит и faults за выбранный период.
Среднее A ниже лимита ещё не исключает короткого срабатывания. Пик мог уложиться между точками агрегирования, а счётчик F уже зафиксировал достижение ограничения. Поэтому попросите историю с тем же часовым поясом и интервалом, в котором магазин тормозил или вернул ошибку.
Шесть лимитов отвечают на разные вопросы
Показатель | Что ограничивает | Как выглядит достижение предела | Что сопоставить |
|---|---|---|---|
SPEED | Долю процессорной мощности аккаунта | Сайт отвечает медленнее | Пик, лимит и faults за тот же интервал |
PMEM | Физическую память процессов | Возможны ошибки 500 или 503 | Память, faults и выполнявшееся действие |
IO | Скорость чтения и записи данных | Дисковые операции замедляются | Фактическую скорость, лимит и faults |
IOPS | Число операций ввода-вывода в секунду | Много мелких операций упираются в предел, даже без большой скорости в МБ/с | IOPS, IO и характер операции |
EP | Число одновременных входов процессов в LVE (Entry Processes); процессы, созданные внутри LVE, в этот счётчик не входят | При достижении возможна ошибка 508 | EP, его лимит, faults и число параллельных запросов |
NPROC | Общее число процессов и потоков аккаунта | Возможны ошибки 500 или 503 | NPROC, лимит, faults и список задач в этот момент |
CloudLinux документирует общее поведение так: достижение CPU или IO обычно замедляет ответ; нехватка памяти или процессов может сопровождаться ошибками 500 либо 503; предел EP может привести к 508. Код ответа — ориентир, а не диагноз: одинаковая ошибка бывает и по другим причинам.
Почему IO и IOPS нельзя складывать в один «диск»
IO ограничивает объём данных в секунду, а IOPS — число операций в секунду. Импорт большого файла способен приблизиться к IO. Множество мелких дисковых операций при работе с файловым кэшем, сессиями или файлами может упереться в IOPS при умеренном потоке данных. При этом чтение из дискового кэша в оперативной памяти CloudLinux не учитывает в лимите IO: обращения к кэшу нельзя автоматически считать физическим чтением диска. Поэтому фраза «диск занят на 20%» без единицы измерения и нужного интервала ничего не решает.
Уточните: лимит относится к аккаунту или к домену
На обычной схеме несколько сайтов одного клиента могут учитываться в общем LVE аккаунта. Тогда всплеск на тестовом сайте, задание cron или импорт в одном магазине влияет на доступный ресурс соседнего домена.
CloudLinux поддерживает отдельные LVE для доменов, но эта возможность требует CloudLinux Isolates, серверного разрешения и дополнительных компонентов. Само наличие CageFS не доказывает, что ресурсы считаются по каждому сайту отдельно. В запросе поддержке прямо укажите домен и попросите назвать область учёта: весь аккаунт или конкретный домен.
Что отправить поддержке
Интервал проблемы с датой и часовым поясом; лучше несколько минут до события и после него.
Домен, страницу или операцию: открытие карточки, оформление заказа, импорт, резервное копирование.
Код ошибки и время ответа; если есть идентификатор запроса, приложите его без секретов и персональных данных.
Таблицу или экспорт Historical Usage: usage, limit и faults по SPEED, PMEM, IO, IOPS, EP и NPROC.
Просьбу назвать точный лимит, область учёта и процесс либо задача, совпавшие по времени.
Описание недавних изменений: новый модуль, массовая загрузка, обмен с 1С, сканирование или запуск cron.
Пароли, ключи доступа, содержимое сессий покупателей и полные журналы с персональными данными в обращение не копируйте. Если поддержке нужны журналы, согласуйте безопасный канал и минимальный фрагмент.
Когда менять тариф, а когда искать причину
Повышение лимита обосновано, если faults повторяются при обычной полезной нагрузке, понятен затронутый ресурс и новый тариф действительно увеличивает именно его. Сравните не название тарифа, а SPEED, PMEM, IO, IOPS, EP и NPROC, цену первого срока и продления, резервные копии и условия поддержки.
Если faults возникли один раз во время импорта, сканирования или резервного копирования, сначала разнесите тяжёлые задачи по времени и проверьте результат. Если faults нет, а сайт медленный, причина может быть вне LVE: очередь PHP-FPM, база данных, внешний API, DNS, сеть или код приложения.
Лимиты ресурсов описаны в документации CloudLinux. Интерфейс статистики описан в документации CloudLinux Manager. Раздельный учёт доменов описан в документации CloudLinux Isolates.
Если измерения подтвердили постоянную нехватку ресурса, сравнивайте условия виртуального хостинга по конкретным лимитам, а не по обещанию «подходит для магазина».
Какой результат считать достаточным
Диагностика закончена, когда для одного события записаны домен или аккаунт, временной интервал, название лимита, его значение, фактическое использование, 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.
Focus on limit triggers, not just high graphs
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.
Six limits answer different questions
Indicator | What it limits | How reaching the limit appears | What to compare |
|---|---|---|---|
SPEED | Share of the account's CPU power | The site responds more slowly | Peak, limit, and faults for the same interval |
PMEM | Physical memory of the processes | Errors 500 or 503 may occur | Memory, faults, and the action being performed |
IO | Data read and write speed | Disk operations slow down | Actual speed, limit, and faults |
IOPS | Number of input/output operations per second | Many small operations hit the limit, even without high MB/s throughput | IOPS, IO, and Operation Type |
EP | Number of simultaneous process entries into an LVE (Entry Processes); processes created within the LVE are not included in this counter | Error 508 may occur upon reaching this limit | EP, its limit, faults, and number of parallel requests |
NPROC | Total number of processes and threads for the account | Errors 500 or 503 may occur | NPROC, limit, faults, and the list of tasks at that moment |
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.
Why I/O and IOPS cannot be combined into a single disk
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.
Clarify: does the limit apply to the account or to the domain?
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.
What to send to support
The problem interval with date and time zone; preferably several minutes before and after the event.
Domain, page, or operation: opening a card, checkout, import, or backup.
Error code and response time; if a request ID exists, include it without secrets or personal data.
A table or Historical Usage export: usage, limit, and faults for SPEED, PMEM, IO, IOPS, EP, and NPROC.
A request to specify the exact limit, the accounting area, and the process or task that coincided in time.
Description of recent changes: a new module, bulk upload, exchange with 1C, scanning, or cron job execution.
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.
When to change the tariff plan versus when to search for the root cause
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.
Resource limits are documented in CloudLinux documentation. The statistics interface is documented in CloudLinux Manager documentation. Separate domain accounting is documented in CloudLinux Isolates documentation.
If measurements confirm a persistent resource shortage, compare virtual hosting conditions based on specific limits, not on the promise of being "suitable for a store".
What result counts as sufficient
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.
Discussion 0
Share your experience and ask questions. Comments without links appear after editorial review.
No comments yet. Start the discussion.