Сайт время от времени выбрасывает белую страницу с надписью «508 Resource Limit Is Reached», через минуту оживает сам, а вы открываете графики нагрузки – и там процессор почти на нуле. Памяти тоже вагон. Логика подсказывает, что раз ресурсы свободны, ошибке взяться неоткуда, но она есть. Если коротко: вы почти наверняка упёрлись в EP – лимит на число запросов, которые аккаунт обрабатывает одновременно. Он не про то, насколько тяжёлые у вас запросы, а про то, сколько их крутится в один и тот же момент. И упереться в него можно при полностью свободном процессоре – ниже разберём, почему так выходит.
Что посмотреть первым делом, ещё до всякой теории. В cPanel это раздел Logs → Resource Usage; там есть счётчик faults – сколько раз аккаунт упирался в лимит и по какому именно параметру. Если растёт колонка, связанная с EP, а CPU и память чистые, диагноз уже почти собран: дело в одновременности, а не в мощности. Всё остальное в статье – объяснение, что это значит и что с этим делать.
Счётчик faults важно читать правильно. Он показывает не текущую нагрузку, а число срабатываний лимита за период – сколько раз запрос упёрся в закрытую дверь. Ноль по EP означает, что входов хватало; растущее число – что в какие-то моменты их не хватило. Смотреть стоит не на разовые единицы, кратковременный всплеск переживёт любой сайт, а на устойчивый рост, особенно если он ложится на часы пик. Если есть доступ по SSH, ту же картину в реальном времени показывают команды lvetop и lveinfo: в колонке EP видно, сколько входов занято прямо сейчас, а рядом, в колонке CPU, – что процессор при этом свободен. Полная колонка EP при почти пустой CPU и есть подпись под диагнозом.
То, что 508 приходит и уходит сам, – тоже примета. Ресурсный упор привязан к нагрузке: спал трафик – ошибка ушла, вернулся пик – вернулась. А вот если 508 висит ровно и постоянно, даже когда заметной нагрузки нет, списывать EP со счетов рано – сначала загляните в EP faults, посмотрите текущий лимит и сколько процессов реально висит. И только если окажется, что 508 отдаёт не CloudLinux, а само приложение или прокси перед ним, причины могут быть уже совсем другими, и копать надо в той стороне.
EP – это про одновременность, а не про силу
Проще всего представить EP как число касс в магазине, а не как мощность двигателя. У аккаунта есть фиксированное количество входов, через которые сервер пропускает динамические запросы. На типичном PHP-сайте это прежде всего запросы, требующие выполнения PHP. На типовом виртуальном хостинге таких входов около двадцати, на тарифах помощнее – сорок. Пока запрос обрабатывается, одно окошко занято; запрос завершился – освободилось для следующего.
Путаницу добавляет то, что самого числа EP вы в тарифе, скорее всего, не найдёте. Провайдеры охотно пишут про гигабайты диска и «безлимитный трафик», а лимит одновременных процессов остаётся за кадром – хотя на общем хостинге именно такой лимит может первым ограничить сайт при резком росте одновременных запросов. Спросить точное значение у поддержки можно всегда, и в ответе обычно окажется то самое двадцать или сорок.
Что многих удивляет: EP – это не число посетителей. Даже два десятка входов спокойно обслуживают большой поток людей, если каждый запрос проходит за десятые доли секунды и почти сразу освобождает место. Двадцать одновременно занятых входов означают двадцать запросов, которые в этот момент ещё не завершились. Чтобы столько накопилось на быстром сайте, нужен либо шквал трафика, либо – и это куда чаще – запросы, которые подолгу не отпускают своё место.
Почему процессор свободен, а лимит исчерпан
Парадокс держится на простой вещи: вход занимает не тот, кто нагружает процессор, а тот, кто просто держит место. Представьте запрос, который отправил тяжёлый SQL к базе и ждёт ответа четыре секунды. Процесс PHP большую часть этого времени ждёт ответа, процессор по нему почти не работает. Но вход занят все четыре секунды. Наберётся два десятка таких ждущих запросов – и EP исчерпан, а процессор показывает почти ноль: считать-то нечего, все ждут.
У CloudLinux есть тонкость, которая усиливает эффект. Запрос к MySQL, отправка почты через Sendmail или другой внешний процесс не создают отдельный EP – текущий вход остаётся одним входом, дочерние процессы своих окошек не занимают. Звучит как хорошая новость, но на практике оборачивается обратным. Если же PHP сам ждёт ответа от внешнего HTTP-сервиса – например, платёжного шлюза, – вход всё равно остаётся занят до конца текущего запроса, сколько бы тот шлюз ни думал. Медленная зависимость – это надолго занятый вход.
На практике EP чаще заканчивается именно из-за медленных запросов: чем дольше каждый держит вход, тем меньше запросов в секунду пропустит тот же лимит. Но исчерпать EP можно и просто большим количеством одновременно пришедших запросов – даже если каждый сам по себе отрабатывает быстро. «Тяжело», «долго» и «слишком много разом» чинятся по-разному, поэтому сначала стоит понять, что именно держит входы занятыми.
Статья длинная. Предлагаем сделать паузу и ознакомиться с лучшими украинскими хостинг-провайдерами из нашего рейтинга. По каждому есть подробный разбор: как тестировали, что с аптаймом, скоростью и поддержкой, где сильные и слабые стороны. Загляните в обзоры тех, кто вам интересен, почитайте отзывы клиентов.
Что дольше всего держит вход занятым
На клиентских сайтах набор виновников из раза в раз повторяется. Первый – медленные запросы к базе: незакэшированная выборка, забытый плагин, который на каждой странице дёргает базу десятками обращений. Второй – генерация страницы без кэша: движок каждый раз собирает страницу заново, вместо того чтобы отдать готовую. Третий – внешние вызовы: проверка платежа, отправка почты через сторонний SMTP, подтягивание курса валют или ленты с чужого сайта; если тот сервис отвечает медленно, ваш вход висит открытым ровно столько, сколько он думает.
Менее очевидные держат место не хуже. Крупные загрузки и выгрузки, которые идут через PHP, а не отдаются напрямую веб-сервером, занимают вход на всё время передачи файла. Импорт товаров, генерация выгрузки для маркетплейса, тяжёлая операция в админке – каждая держит слот на секунды, а то и минуты. С WP-Cron отдельная тонкость: в стандартной конфигурации он проверяется и запускается во время посещений сайта, а не отдельным системным cron-процессом, так что тяжёлая крон-задача откусывает вход у живого трафика в самый неудачный момент.
Рядом почти всегда боты. Реальные посетители приходят вразнобой, а поисковый краулер, парсер или сканер уязвимостей способен открыть два десятка страниц в одну секунду – и создаёт ту самую одновременность, которой не даёт человеческий трафик. Query Monitor помогает разглядеть, что тормозит внутри конкретного запроса WordPress – медленный SQL, зависший внешний вызов, прожорливый плагин. А кто создаёт сам поток одновременных запросов, видно уже не в нём, а в логах доступа и серверной статистике: там нередко и выясняется, что пик даёт не наплыв покупателей, а зачастивший бот или давно заброшенный плагин.
Как это выглядит вживую – довольно типичная картина у интернет-магазинов. Каждый вечер, в час самого высокого трафика, сайт начинает через раз показывать 508, а к ночи всё проходит само. Первым делом грешат на нехватку памяти или слабый тариф, докупают ресурсы – не помогает. А оказывается, что незакэшированная страница категории собиралась базой по несколько секунд, и в вечерний пик таких сборок набиралось столько, что входы заканчивались. Стоило закэшировать вывод категорий – вечерние 508 исчезли, хотя тариф остался прежним. Отдельно коварна ситуация, когда весь поток держит одна тормозящая зависимость: начал медленно отвечать платёжный шлюз – и небольшой магазин упирается в EP из-за чужого сервиса, к которому сам отношения не имеет.
EP, CPU, память и NPROC – четыре разных упора, которые вечно путают
Ошибка 508 сбивает с толку тем, что сама по себе не говорит, какой именно лимит исчерпан, – это своего рода чёрный ящик. А лимитов на аккаунте несколько, и ведут они себя по-разному. Симптом подсказывает направление, но окончательно вопрос закрывает не он, а faults.
| Упор | Что может происходить | Куда смотреть |
|---|---|---|
| EP | 508 при достижении лимита одновременных входов | EP faults |
| CPU / IO | запросы начинают обрабатываться медленнее | CPU / IO faults |
| PMEM | процессы могут завершаться с ошибками | PMEM faults |
| NPROC | новые процессы не могут быть созданы | NPROC faults |
NPROC стоит развести с EP отдельно, потому что их путают чаще всего. NPROC – это общее число процессов аккаунта: сюда идут не только веб-запросы, но и сессии SSH, крон-задачи, почтовые процессы. EP считает только входы, NPROC – вообще все процессы. Причём тут многое зависит от обработчика PHP: PHP-FPM или LSPHP могут держать под собой дополнительные процессы, которые увеличивают NPROC, но не EP. Поэтому бывает, что EP показывает один вход, а процессов при этом висит десяток. Разработчики CloudLinux не зря требуют, чтобы NPROC был минимум на пятнадцать больше EP, – иначе аккаунт упрётся в потолок общего числа процессов раньше, чем в потолок входов.
Грубый ориентир по симптому такой: сайт заметно тормозит, но ошибки нет – чаще смотрят в сторону процессора или диска; валится 500 или белый экран – в сторону памяти; рваный 508, привязанный к часам пик, – это про EP. Но симптом только направляет: те же 500 бывают и по другим причинам, поэтому спор решают faults, а не догадка по внешнему виду. Откуда вообще берутся эти лимиты и почему провайдер вправе их ставить, подробно разобрано в материале про CloudLinux.
Почему поднять EP – обычно не то, с чего стоит начинать
Первое желание при виде 508 – попросить у хостера побольше входов или перейти на тариф, где их сорок вместо двадцати. Иногда это и правда решение. Но чаще – трата денег, которая только отодвигает проблему. Если запросы медленные, бóльшее число входов лишь удлиняет очередь: под следующий всплеск трафика вы упрётесь в новый потолок, просто чуть позже. Корень не в числе входов, а в том, что каждый держится открытым слишком долго.
Работает обратный порядок. Сначала – кэширование, чтобы страница отдавалась готовой, а не собиралась заново на каждый заход. И тут стоит различать два кэша, потому что от EP спасает в первую очередь один из них. При корректно работающем полностраничном кэше запрос к готовой странице может обслуживаться вообще без запуска PHP и обращения к базе – вход при этом почти не занимается, и для анонимного трафика это самый сильный рычаг. Кэш объектов (Redis или Memcached) работает тоньше: он не убирает PHP, но позволяет приложению не выполнять часть повторных запросов к базе, если соответствующие данные закэшированы, – а именно ожидание базы и держало вход открытым. Для магазина с корзиной и личным кабинетом, где страницы целиком не закэшируешь, объектный кэш нередко и снимает вечерние 508. Потом – разбор медленных запросов и тяжёлых плагинов. Скорость ответа сервера и EP связаны напрямую: чем быстрее отрабатывает запрос, тем быстрее освобождается вход, тем больше людей проходит через те же двадцать входов без очереди. Про то, из чего складывается эта скорость и как её мерить, есть отдельный разбор про TTFB. И только когда сайт уже быстрый, кэш настроен, а трафик действительно и устойчиво вырос, поднимать EP осмысленно.
У провайдера та же картина, только с другого конца. Хостер ставит EP низким намеренно: это защита от «шумного соседа» – одного аккаунта, который под нагрузкой съел бы все процессы Apache и уронил бы вместе с собой весь сервер. Поднять одному аккаунту EP до сотни технически недолго, но избегают этого не из жадности: все аккаунты на узле делят общий пул процессов Apache, и если раздать каждому по сотне входов, один тяжёлый сосед в пик займёт их столько, что остальным перестанет хватать. Низкий EP – это, по сути, страховка соседей от вас и вас от соседей разом.
На мониторинге аккаунт с чистым процессором, но растущими EP faults читается однозначно: сайт не тяжёлый, он медленный под нагрузкой. Поэтому на просьбу «дайте больше EP» вдумчивая поддержка нередко отвечает не увеличением лимита, а советом сначала поставить кэш – и, вопреки первому впечатлению, это по делу.
LiteSpeed: почему там EP считается иначе
Здесь нужна оговорка, потому что простого правила «Apache отдаёт 508, а LiteSpeed – нет» не существует. На Apache модуль mod_hostinglimits при достижении лимита одновременных входов возвращает 508 сразу: свободного входа нет – держи ошибку. На LiteSpeed EP реализован иначе, и одна и та же нагрузка не обязательно даёт то же самое значение EP; вдобавок на результат влияет конфигурация PHP и самого LiteSpeed, в частности ограничение PHP suEXEC Max Conn. Поэтому отсутствие 508 на LiteSpeed само по себе ещё не доказывает, что в EP вы не упирались, – симптомом там может быть просто заметно медленная отдача под нагрузкой. Обратное тоже верно: 503 на LiteSpeed не стоит автоматически записывать в EP – он бывает связан с NPROC или другими настройками PHP и веб-сервера. Что означают сами коды и чем 508 отличается от 503, разобрано в статье про ошибку 508.
Когда пора менять тариф или уходить на VPS
Признак один: faults по EP остаются грязными даже после того, как вы поставили кэш и разобрались с медленными запросами, а трафик при этом реально и стабильно подрос. Пока упор снимается ускорением сайта – смена тарифа лишь маскирует проблему за ваши деньги. Переход на VPS оправдан не тогда, когда хочется поскорее убрать 508, а когда ресурсы нужны свои и лимиты вы хотите задавать сами. Это уже другой разговор и другой бюджет – но по крайней мере вы будете менять тариф из-за реального роста, а не из-за забытого плагина, который на каждой странице ходил в базу двадцать раз. И ещё: прежде чем брать VPS, трезво оцените, готовы ли вы сами следить за обновлениями и безопасностью сервера, – вместе со своими лимитами вы берёте на себя и администрирование, которое на общем хостинге за вас делал провайдер.
Источники
- CloudLinux OS Documentation – Limits (EP, NPROC, поведение 508)
- CloudLinux – EP and NPROC limits, a look from inside
- CloudLinux – LVE limits: default and recommended values
- LiteSpeed Wiki – CloudLinux LVE vs LSWS PHP suEXEC Max Conn
FAQ по статье
Что такое EP (Entry Processes) на хостинге?
EP – это лимит на число запросов, которые аккаунт обрабатывает одновременно. Проще всего представить его как число касс в магазине: пока запрос обрабатывается PHP, одно «окошко» занято, завершился – освободилось. На типовом виртуальном хостинге таких окошек около двадцати, на тарифах помощнее – сорок. Это лимит одновременности, а не мощности.
Почему сайт отдаёт 508, если процессор не загружен?
Потому что окошко EP занимает не тот, кто нагружает процессор, а тот, кто просто держит место. Запрос, который ждёт ответа от медленной базы или внешнего сервиса, всё это время процессор почти не использует, но окошко держит. Наберётся два десятка таких ждущих запросов – и EP исчерпан при почти нулевом CPU. Отсюда и парадокс «508 при свободном процессоре».
EP – это количество посетителей сайта?
Нет, это распространённое заблуждение. EP считает не посетителей, а запросы, которые в этот момент ещё не отдали ответ. Даже два десятка входов спокойно обслуживают большой поток людей, если каждый запрос проходит за доли секунды и почти сразу освобождает место. Проблема начинается там, где запросы подолгу не отпускают вход.
Сколько EP обычно даёт виртуальный хостинг?
На типовом тарифе – около двадцати, на более мощных – порядка сорока. Точное число в тарифе обычно не пишут: провайдеры охотнее указывают гигабайты диска и «безлимитный трафик», а лимит одновременных процессов остаётся за кадром. Узнать своё значение можно у поддержки – в ответе, скорее всего, окажется как раз 20 или 40.
Чем EP отличается от лимита CPU?
EP – это про то, сколько запросов идёт одновременно, а CPU – про то, сколько процессорного времени они жгут. Упор в EP на Apache даёт 508, а упор в CPU ошибки обычно не выдаёт: сайт просто тормозит. Симптом подсказывает направление, но точный ответ дают faults: медленная загрузка без ошибки чаще про процессор, рваный 508 под нагрузкой – чаще про EP.
Чем EP отличается от NPROC?
EP считает только входы – веб-запросы, попадающие в обработку. NPROC считает вообще все процессы аккаунта: сюда идут ещё сессии SSH, крон-задачи, почтовые процессы. Поэтому EP может показывать один вход, а процессов при этом висеть десяток. По требованиям CloudLinux NPROC должен быть минимум на пятнадцать больше EP.
Как понять, что я упёрся именно в EP?
Откройте в cPanel раздел Logs → Resource Usage и посмотрите на faults. Если растёт колонка, связанная с EP, а CPU и память чистые – дело в одновременности. По SSH ту же картину в реальном времени показывают lvetop и lveinfo: полная колонка EP при пустой CPU и есть подпись под диагнозом.
Что заставляет один запрос надолго занимать EP?
Всё, из-за чего запрос долго не отдаёт ответ: медленный SQL к базе, генерация страницы без кэша, ожидание внешнего сервиса вроде платёжного шлюза или стороннего SMTP. Крупные загрузки и выгрузки через PHP и тяжёлые операции в админке тоже держат окошко на секунды и минуты. Причём вызов MySQL или почты изнутри скрипта считается тем же одним входом – окошко висит всё время ожидания целиком.
Почему боты так легко упирают сайт в EP?
Реальные посетители приходят вразнобой, а бот способен открыть два десятка страниц в одну секунду – и создаёт ту самую одновременность, которой не даёт человеческий трафик. Краулеры, парсеры и сканеры уязвимостей заходят пачками и занимают все окошки разом. Нередко после разбора логов доступа выясняется, что пик одновременных запросов создавал именно зачастивший бот, а не наплыв покупателей.
Поможет ли увеличение EP убрать 508?
Иногда да, но чаще это лишь отодвигает проблему. Если запросы медленные, большее число окошек просто удлиняет очередь: под следующий всплеск вы упрётесь в новый потолок чуть позже. Сначала стоит поставить кэширование и разобраться с медленными запросами – тогда окошки освобождаются быстрее, и часто 508 уходит без всякого повышения лимита.
Почему на LiteSpeed 508 может не появляться, хотя EP достигнут?
Простого правила «Apache отдаёт 508, а LiteSpeed – нет» не существует. На Apache модуль mod_hostinglimits при достижении лимита одновременных входов возвращает 508 сразу, а на LiteSpeed EP реализован иначе, и на результат влияет конфигурация PHP и самого LiteSpeed, в частности PHP suEXEC Max Conn. Поэтому отсутствие 508 на LiteSpeed само по себе не доказывает, что EP не достигался – симптомом бывает просто медленная отдача под нагрузкой. И 503 там не стоит автоматически считать признаком EP: он может быть связан с NPROC или другими настройками.
Когда упор в EP – повод переходить на VPS?
Тогда, когда faults по EP остаются грязными даже после кэширования и разбора медленных запросов, а трафик реально и стабильно вырос. Пока упор снимается ускорением сайта – смена тарифа просто маскирует проблему за ваши деньги. Переход на VPS осмыслен, когда ресурсы нужны свои и лимиты вы хотите задавать сами, но вместе с ними вы берёте на себя и администрирование сервера.