Лимиты shared-хостинга: CPU, память, процессы и ошибка 503

На виртуальном хостинге ограничивают четыре вещи: процессорное время, суммарную память процессов PHP, скорость диска и число одновременных процессов. Ошибка 503 в вечерний час пик почти всегда означает упор в процессор, а не поломку сайта.

Сайт открывается нормально утром, а каждый день около семи вечера, ровно когда трафик в пике, отдаёт 503 или белый экран на десять-пятнадцать минут. Поддержка хостинга отвечает «у вас превышение лимитов», но не говорит, каких именно и что с этим делать. Разбираю, какие лимиты вообще стоят на виртуальном хостинге, как увидеть расход своими глазами, кто их обычно съедает и что реально помогает без немедленного перехода на VPS.

За шесть лет обслуживания сайтов малого бизнеса эта жалоба, наверное, третья по частоте после «сайт не открывается» и «плагин что-то тормозит». Разница в том, что здесь проблема не в коде сайта, а в договоре между вами и хостингом: он продал место в общем доме и честно ограничил, сколько вы можете шуметь.

Какие лимиты вообще стоят на виртуальном хостинге

Shared-хостинг это один физический сервер, на котором живут сотни аккаунтов одновременно. Чтобы один сайт не положил остальных, хостер режет ресурсы на уровне контейнера каждого аккаунта. Технология у большинства массовых хостеров называется CloudLinux LVE (Lightweight Virtual Environment), но суть одна и на других решениях.

Лимит	Что ограничивает	Типичное значение на массовых тарифах	Что видит посетитель при превышении
CPU	Процент процессорного времени на аккаунт	25-100 процентов одного ядра	Замедление, потом 503
Physical Memory	Суммарная память всех PHP-процессов аккаунта	512 МБ — 2 ГБ	Fatal error, белый экран, 503
Entry Processes	Число одновременных PHP-процессов	8-20	Отказ новых подключений, 503
I/O	Скорость чтения-записи на диск	1-10 МБ/с	Зависание при загрузке файлов, долгий ответ
IOPS	Число операций чтения-записи в секунду	512-1024	Общее торможение при пиковой нагрузке

Важный нюанс: лимиты считаются не на сайт, а на аккаунт хостинга целиком. Если на одном тарифе живёт три сайта клиента, они делят один и тот же потолок памяти и процессов между собой.

Как это выглядит для посетителя

Разные лимиты дают разные симптомы, и по симптому можно примерно понять, во что вы упёрлись, ещё до того, как открыли графики:

• 503 Service Unavailable — чаще всего превышение Entry Processes: сервер физически не может открыть ещё один процесс PHP под ваш аккаунт, новые запросы ставятся в очередь или отбрасываются.
• 508 Resource Limit Is Reached — фирменный код CloudLinux LVE, почти всегда означает упор в CPU или память конкретно вашего контейнера, а не сервера целиком.
• Белый экран без текста ошибки — PHP-процесс убит по памяти на середине выполнения, ответ не успел сформироваться.
• Долгая загрузка, потом обрыв соединения — запрос встал в очередь на ограниченный пул процессов и не дождался освобождения.

Если браузер иногда показывает предупреждение о недоступности сайта, а не просто белый экран, для начала стоит исключить более прямолинейную причину, прочитав про что означает, если сайт упал ночью: иногда дело не в лимитах, а в банальном падении процесса или сбое хостинга.

Где смотреть графики расхода и как поймать час пик

В cPanel это раздел «Использование ресурсов текущего аккаунта» (CloudLinux LVE Manager), там отдельные графики по CPU, памяти, числу процессов и I/O с историей обычно за последние сутки. В ISPmanager аналогичный раздел называется «Статистика ресурсов». В личных кабинетах Timeweb и Beget графики находятся в разделе конкретного сайта или тарифа.

Если графиков в панели нет, а доступ есть только по SSH, быстрая проверка текущей нагрузки:

top -u $(whoami)
cat /proc/loadavg

Чтобы поймать сам момент упора в лимит постфактум, ищите характерные строки в error.log:

grep -iE "exceeded|resource temporarily unavailable|out of memory" /home/user/logs/error.log | tail -50

Часовой пик у большинства сайтов малого бизнеса приходится на 10:00-12:00 (рабочий трафик) и 19:00-21:00 (вечерний трафик с телефонов), но у интернет-магазинов бывает смещение к выходным и к моментам рекламных рассылок. Сопоставьте время из графика ресурсов с временем жалоб от клиента или с собственным мониторингом, обычно совпадение прямое.

Кто реально съедает ресурсы

По моей практике в девяти случаях из десяти виноват не трафик от живых посетителей, а один из следующих источников:

• Боты и парсеры. SEO-краулеры конкурентов, парсеры цен, а в последние пару лет ещё и боты AI-компаний, которые обходят сайт целиком без всякого кэша в браузере, генерируя нагрузку сопоставимую с тысячами реальных визитов.
• WP-Cron, который запускается на каждом хите. Штатный механизм WordPress проверяет отложенные задачи при каждом заходе посетителя, если сайт не настроен иначе. На сайте с трафиком это лишний PHP-процесс на каждый визит.
• admin-ajax.php под нагрузкой. Корзина WooCommerce, живой поиск, счётчики «сейчас смотрят» — всё это синхронные AJAX-запросы, которые держат отдельный PHP-процесс на время выполнения.
• Поиск по сайту без индекса. Штатный поиск WordPress и многих других CMS выполняет полнотекстовый LIKE-запрос по всей таблице записей, при большом каталоге это заметная нагрузка на каждый ввод в строку поиска.
• Синхронные обращения к внешним API. Плагины антиспама, курсов валют, доставки, которые дергают внешний сервис прямо во время генерации страницы и держат процесс открытым, пока не дождутся ответа.

Что помогает без смены тарифа

Полезно начать с того же чек-листа, что применяю на клиентских сайтах, когда 503 появляется впервые:

• [ ] Включить полностраничный кэш страниц (WP Super Cache, LiteSpeed Cache при поддержке хостером), чтобы отдавать статику без запуска PHP на каждый визит
• [ ] Ограничить доступ ботов и парсеров через robots.txt и правила в .htaccess
• [ ] Перевести WP-Cron на системный крон вместо запуска при каждом хите
• [ ] Отключить лишние AJAX-вызовы (heartbeat API, cart fragments) на страницах, где они не нужны
• [ ] Проверить и почистить разбухшую базу данных, если сайт живёт больше двух-трёх лет
• [ ] Свериться с gzip и Brotli сжатием на сервере, это снижает нагрузку на канал, хотя и не напрямую на CPU

Перевод WP-Cron на системный крон делается двумя шагами. Сначала отключаем встроенный запуск:

// wp-config.php
define('DISABLE_WP_CRON', true);

Затем добавляем задание в системный crontab хостинга, например раз в 5 минут:

*/5 * * * * curl -s https://example.ru/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Такая замена убирает лишний PHP-процесс на каждый визит и переносит нагрузку на предсказуемое расписание, а не на случайные пики трафика. Про то, как в целом устроено кэширование средствами самого сервера, писал в статье про кэширование через .htaccess, а сжатие gzip и Brotli на канале, хоть и не снимает нагрузку с CPU напрямую, тоже стоит проверить заодно.

Если сайту просто три года и на нём накопилось два десятка неактуальных плагинов, разумно для начала прочитать почему WordPress тормозит после трёх лет: часто половина найденной там чистки снимает и упор в лимиты хостинга заодно, без апгрейда тарифа.

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

curl -sI https://example.ru/ | grep -i "x-cache|age:"

Если заголовка со статусом кэша нет вовсе или он показывает MISS на втором и третьем подряд запросе, кэш не отдаёт готовую страницу, а генерирует её заново каждый раз, то есть толку от него для лимитов ноль.

Когда честнее переехать

Апгрейд тарифа или переход на VPS стоит денег каждый месяц, а не разово, поэтому решение имеет смысл считать, а не принимать по ощущению. Формула простая: сравните разницу в стоимости тарифов за месяц со стоимостью потерь от простоев, которые уже происходят.

Если 503 случается пару раз в месяц на пять минут и заявок с сайта в это время почти нет, апгрейд может не окупаться. Если сайт падает каждый вечер в час пик на 15-20 минут, а именно вечером идёт основной поток заявок, разница в тарифе на VPS обычно 1500-4000 рублей в месяц против регулярной потери реальных клиентов, которые просто не дождались загрузки и ушли к конкуренту. При выборе конкретного нового тарифа стоит свериться с материалом как выбрать хостинг малому бизнесу, там разбор именно по параметрам, которые здесь и упираются в лимиты.

Отдельно стоит смотреть на тренд, а не на разовый случай. Если полгода назад лимитов хватало, а сейчас начались регулярные упоры, дело не в хостинге, а в том, что сайт вырос (больше каталог, больше плагинов, больше трафика), и рано или поздно апгрейд всё равно понадобится. Вопрос только в том, до или после серии потерянных заявок.

Возьмём конкретную прикидку. Сайт услуг с формой заявки, средний чек 25 000 рублей, конверсия из посетителя в заявку около 2 процентов. Если вечерний пик даёт обычно 300 визитов за два часа, а сайт из-за 503 недоступен 20 минут из этих двух часов, это примерно 50 потерянных визитов и, грубо, одна упущенная заявка за вечер. Одна заявка в 25 000 рублей уже перекрывает разницу в тарифе на VPS за половину месяца. Если такие падения случаются хотя бы раз в неделю, а не раз в квартал, апгрейд окупается быстрее, чем кажется на первый взгляд, и это не абстрактная рекомендация, а обычная арифметика на бумажке.

Если сайт прямо сейчас лежит в час пик и разбираться с логами и графиками самостоятельно некогда, опишите ситуацию через форму на сайте: такую диагностику делаю в рамках разовой работы или абонентского обслуживания, с конкретным ответом, где именно упор и что с этим реально делать. Тарифы на постоянное сопровождение сайта, куда входит и мониторинг подобных ситуаций, смотрите в разделе с ценами.

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

Какие лимиты стоят на виртуальном хостинге

Процессорное время в пределах доли ядра, память всех процессов PHP от 512 МБ до пары гигабайт, скорость чтения и записи на диск, число одновременных процессов. Превышение любого даёт замедление или ошибку.

Почему сайт падает каждый вечер

Потому что в час пик вы упираетесь в процессорный лимит. Утром трафика меньше, и тот же сайт открывается нормально. Смотреть надо графики расхода ресурсов в панели хостинга, а не логи ошибок.

Что съедает ресурсы чаще всего

Тяжёлые плагины, поиск по сайту без кэша, генерация страниц для ботов, крон, запущенный слишком часто, и запросы к базе без индексов. Реальные посетители обычно не главная статья расхода.

Что помогает без смены тарифа

Кэш страниц для анонимных посетителей, ограничение частоты крона, отключение лишних плагинов и блокировка назойливых парсеров. Часто этого хватает, чтобы уйти от предела.