Если вы админ или разработчик, который отвечает за сайт на виртуальном хостинге, наверняка сталкивались с графиками CPU, IO, inodes и загадочными «entry processes». В критические моменты панель показывает всплески, а пользователи ловят 508 Resource Limit Is Reached или периодические 500/503. В этой статье разложу по полочкам, как интерпретировать лимиты, чем они отличаются, что именно влияет на эти метрики и какие шаги реально помогают на практике.
Что это за лимиты и почему они существуют
На виртуальном хостинге ресурсы сервера делятся между многими аккаунтами. Чтобы один «шумный сосед» не забрал все CPU и диск, провайдер ограничивает ресурсы для каждого пользователя: CPU, память, дисковые операции (IO/IOPS), число процессов и файлов (inodes), а также «entry processes» (EP) — показатель параллельных «входов» в приложение.
В большинстве решений используется CloudLinux с изоляцией LVE. Это дает предсказуемость: если ваш сайт упирается в лимит, страдает только он, а не соседи. Наша задача — вовремя распознать упор в лимиты и устранить причину.
CPU: проценты чего именно
Лимит CPU в CloudLinux обычно выражается в процентах относительно одного физического ядра. Например, 100% = одно ядро. Если тариф дает 200%, вы можете использовать эквивалент двух ядер, но только в рамках лимита аккаунта (детали смотрите в описании тарифов виртуального хостинга). В пиковые моменты график CPU достигает 100% — это означает, что ваш PHP/скрипты/утилиты упираются в доступный вам предел.
Последствия: рост времени ответа, 508 при одновременной нагрузке, медленные админ-панели CMS. Частая причина — PHP без кеша, тяжелые плагины, ботовый трафик, неудачные крон-задачи, ручные импорты/экспорты в «прайм-тайм».
Важно: 100% CPU в панели — это не «сервер на 100% загружен», а «ваш лимит CPU полностью используется». Это разные вещи.
Как снизить CPU без миграции
- Включите полноформатный page cache для CMS (статическая отрисовка страниц снижает обращения к PHP).
- Удалите ресурсоемкие плагины/модули и дубликаты функционала.
- Обновите PHP до более новой ветки — прирост производительности ощутим; не забудьте включить OPcache.
- Оптимизируйте базу данных (индексы под тяжёлые SELECT, устранение N+1 в коде).
- Отключите «шумные» крон-задачи днём, перенесите на ночь, ограничьте конкуренцию с помощью блокировки.
IO и IOPS: пропускная способность диска против количества операций
IO (иногда подписан как «Disk Speed») показывает, сколько мегабайт в секунду вы можете читать/писать. IOPS — сколько дисковых операций в секунду (много мелких файлов быстро «съедают» IOPS даже при скромном объеме в мегабайтах). На виртуальном хостинге лимиты IO/IOPS защищают соседей от «дисковой бури».
Симптомы упора в IO: файлы загружаются медленно, скачивания «тормозят», резервные копии идут вечность, PHP/скрипты, работающие с большим числом файлов, резко замедляются. Упор в IOPS часто связан с множеством мелких файлов (кеши, миниатюры изображений, временные файлы).
Как снизить IO/IOPS
- Минимизируйте массивы мелких файлов. Отключите чрезмерные кеши, которые генерируют миллионы файлов, настройте TTL/очистку.
- Логи ротируйте и сжимайте; не храните тяжелые архивы в web-директориях.
- Выносите «медиа-склады» за пределы аккаунта или используйте внешнее хранилище/CDN (в провайдерской экосистеме, если доступно).
- Не запускайте тяжелые резервные копии в часы пик.
- Для CMS включите object cache (если доступен Redis/Memcached) — меньше запросов к БД и диску. Подробный разбор — в материале Redis или Memcached для PHP-кеша.
- Сократите вес и количество изображений; посмотрите гайд по современным форматам в статье WebP/AVIF и экономия диска/трафика.
Inodes: когда место есть, а файл не создать
Inodes — это счетчик файлов и директорий. На разных тарифах устанавливается лимит по количеству объектов. Можно иметь свободные гигабайты и при этом не уметь загрузить картинку, потому что лимит inodes исчерпан. Частые «пожиратели» inodes: крайний случай — кеши, миниатюры изображений, бекапы внутри web-каталога, артефакты сборки (node_modules, vendor), содержимое почтовых ящиков, старые версии, мусор от плагинов.
Если дошли до лимита inodes, почта может перестать принимать письма, загрузка файлов — падать с ошибками, работа CMS — нестабильной.
Как быстро оценить inodes и найти «пылесосы»
Если у вас есть SSH, можно посчитать количество файлов и «горячие» директории. Примеры команд:
# Сколько файлов и директорий в домашнем каталоге (примерно)
find ~ -xdev -type f | wc -l
find ~ -xdev -type d | wc -l
# Inodes на файловой системе (глобальная оценка)
df -i
# Топ директорий по количеству файлов (требует -printf)
find ~/public_html -xdev -type f -printf '%h\n' | sort | uniq -c | sort -nr | head -n 20
# Объем по каталогам (не про inodes, но помогает при наведении порядка)
du -h --max-depth=1 ~/public_html 2>/dev/null | sort -h
Обратите внимание на каталоги вида wp-content/cache, wp-content/uploads, var/cache, storage, node_modules, vendor, а также на почтовые ящики пользователя.
Профилактика переполнения inodes
- Не храните резервные копии внутри
public_html. Держите архивы вне web-корня и ограничивайте количество. - Отключите лишние размеры изображений, включите сжатие и очистку превью, если CMS генерирует слишком много миниатюр.
- Кеши настраивайте с автоочисткой. Периодическая
cron-задача может удалять файлы старше N дней. - Почтовые ящики чистите, используйте автоархивацию/сжатие.
- Исключите из деплоя артефакты разработки (
.git,node_modules,testsи т.п.).
Entry processes (EP) и NPROC: что за «процессы на входе»
Entry processes (EP) — это количество одновременных «входов» в ваше веб-приложение (обычно моменты запуска PHP или другого интерпретатора через веб-сервер). Это не «онлайн» и не число посетителей. Один пользователь может дергать несколько путей, и каждый запрос, требующий PHP, кратковременно увеличивает EP. При превышении лимита EP новые запросы начнут получать 508/503 до освобождения слотов.
NPROC — лимит общего числа процессов пользователя. Если ваш код порождает подпроцессы или одновременно работают десятки воркеров/скриптов, легко упереться в NPROC, особенно вместе с кроном.
Как уменьшить EP и избежать «шипов»
- Включите page cache: пусть как можно больше запросов отдается статикой без PHP.
- Оптимизируйте тяжелые маршруты и API — ограничьте внешние синхронные вызовы, используйте очереди.
- Сведите к минимуму количество ассетов, которые провоцируют параллельные обращения к динамике.
- Перенесите тяжелые импорты/генерации отчетов на фоновые задачи с блокировками.
- При возможности включите кеширование сессий/объектов в память, чтобы сократить длительность обработки.
Типичные симптомы и как их читать
- 508 Resource Limit Is Reached: чаще упор в EP, реже — CPU/IO. Смотрите «Faults» в панели за последние часы.
- Периодические 500/503: проверки на пике CPU и EP, затем — PHP-логи, таймауты к БД/внешним API.
- Админка «липнет»: возможен IO/IOPS (много мелких файлов), либо CPU под нагрузкой.
- Загрузка/сохранение медиа ломается: проверьте inodes и свободное место.
Практическая диагностика в условиях виртуального хостинга
Даже без root-доступа можно собрать полезную картину. Действуйте по чек-листу:
- Откройте «Resource Usage» вашей панели и проверьте, какие лимиты достигались и когда. Ищите корреляции по времени с событиями (акции, рассылки, импорты).
- Сопоставьте пики с логами web-сервера и CMS: какие урлы чаще всего обращались на пике.
- Посчитайте inodes и «топ-деревья» по количеству файлов — приведенные команды выше помогут.
- Проверьте крон-задачи: нет ли одновременных запусков одной и той же задачи, которые конфликтуют между собой.
- Сделайте «быстрые победы»: включите кеш страниц, отключите явно лишние плагины, переведите тяжелые задачи на ночь.
Надежный запуск cron без гонок
Гонки крон-задач дают всплески CPU/EP и легко «шумят» по IO. Используйте файловую блокировку:
# Пример: не запускать, если уже идёт предыдущий цикл
flock -n /home/USER/.locks/job.lock -c "/usr/bin/php /home/USER/app/cron.php"
Для тяжелых задач добавьте таймауты и журналирование длительных запусков, чтобы понимать, где «узкое горлышко».
WordPress и популярные CMS: где чаще всего болит
По опыту, в WordPress основная экономия ресурсов достигается за счет корректной конфигурации кеша страниц и оптимизации медиа. WooCommerce усложняет ситуацию динамикой корзины/кабинета — там неизбежно будет больше обращений к PHP и к БД.
- Кеш страниц на уровне CMS или веб-сервера снимает до 80% нагрузки на CPU/EP.
- Object cache сокращает обращения к БД; меньше диск и CPU.
- Своевременная чистка
wp-content/cacheи ограничение числа миниатюр спасают inodes. - Отключайте автогенерацию «лишних» превью, удаляйте неиспользуемые размеры.
- Заприте тяжелые импорты на ночь, используйте блокировки и «шедулинг» на батчи.
IO vs сетевой трафик: не путайте
Частая ошибка — путать лимит IO (диск) с исходящим трафиком (сеть). Медленное скачивание архива из CMS может быть вызвано упором в IO, а не в сеть. Если при скачивании сервер занят чтением/сжатием большого количества мелких файлов, выпрямите процесс: предварительно соберите архив, скомпонуйте данные, уменьшите число случайных чтений.
Сколько «держит» тариф: ориентиры без магии
На «бюджетном» тарифе при правильном page cache типовой сайт-визитка или блог выдерживает солидный поток чтения, потому что статическая выдача практически не трогает PHP. Как только кеш отключен или бьется динамика (поисковые роботы, сканеры, админские операции), нагрузка перескакивает на CPU/EP. Для интернет-магазинов без агрессивного кеширования предел нагрузки наступает значительно раньше — и узким местом становится связка EP+CPU и медленная БД.
Поэтому единый ответ «сколько посетителей выдержит тариф» некорректен. Смотрите на профиль нагрузки и долю кешируемой отдачи. Если графики CPU/EP плотно держатся возле лимита, а оптимизации уже внедрены, пора планировать апгрейд тарифа или переход на уровень выше.
Чек-лист быстрых оптимизаций (до апгрейда)
- Включить кеш страниц. Проверить заголовки кеширования статических файлов.
- Обновить PHP. Включить/проверить OPcache.
- Отключить ресурсоемкие плагины, пересмотреть интеграции с внешними API.
- Распланировать крон-задачи по времени. Добавить блокировки.
- Очистить кеши/превью/лог-файлы, навести порядок в
uploads. - Сократить число мелких файлов (inodes): убрать артефакты сборки, ограничить бекапы, настроить ротацию.
- Включить object cache (если доступен) для снижения нагрузки на БД и диск.
Когда пора поднимать план или менять класс платформы
Есть четыре признака, что оптимизации «съедены», а сайт упирается в потолок именно по классу платформы:
- Постоянные «faults» по CPU/EP даже после внедрения кешей.
- Стабильные пределы по IO/IOPS при нормальной архитектуре приложения (мало мелких файлов, аккуратные логи).
- Периодические «шипы» трафика, на которых вы хотите управлять ресурсами гибче (в т.ч. изоляция и вертикальный скейл).
- Лимит inodes системно мешает росту (много контента/медиа), а убрать «мелочевку» уже некуда.
В таком случае логично поднять тариф или рассмотреть платформу с гибкой изоляцией и управлением ресурсами — например, перейти на облачный VDS. Главное — прийти к этому осознанно, после наводки порядка и измерений.
Ответы на частые вопросы
EP — это количество посетителей? Нет. EP — это число одновременных «запусков» приложения. Сильный кеш снижает EP даже при большом трафике.
Почему у меня 100% CPU, но сервер «живой»? Вы упёрлись в свой лимит CPU. Это не означает, что физический сервер перегружен — лимит изоляции только ваш.
Место есть, а файлы не грузятся? Проверьте inodes. Лимит по количеству файлов может быть исчерпан при свободном пространстве.
IO «краснеет» на бекапах — это нормально? Иногда да, но старайтесь запускать бекапы вне пикового окна, исключать кеши/мусор из архива, хранить копии вне web-корня.
Шаблоны команд на каждый день
# Топ-20 директорий по количеству файлов в публичной части
find ~/public_html -xdev -type f -printf '%h\n' | sort | uniq -c | sort -nr | head -n 20
# Удалить кеш-файлы старше 3 дней (проверьте путь!)
find ~/public_html/wp-content/cache -type f -mtime +3 -delete
# Посмотреть, какие файлы росли сегодня (удобно ловить «утечки»)
find ~/public_html -xdev -type f -mtime -1 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Проверить текущие задачи пользователя
crontab -l
# Простой шаблон блокировки для cron
flock -n /home/USER/.locks/task.lock -c "/usr/bin/php /home/USER/app/task.php --once"
Итого
Лимиты CPU, IO/IOPS, inodes и entry processes на виртуальном хостинге — это не «наказание», а механизм справедливого распределения ресурсов. Понимая, что именно означает каждый показатель, вы сможете быстро отличить упор в EP от нехватки CPU, а проблему inodes — от банальной нехватки места. С нужным кешем, дисциплиной кронов и гигиеной файловой системы даже насыщенные сайты стабильно работают в рамках тарифов. И только когда оптимизации исчерпаны, имеет смысл планировать апгрейд платформы.
