Сайт то падает, то оживает сам собой, а на белой странице – короткое «508 Resource Limit Is Reached». Если коротко: почти наверняка это не поломка сервера и не взлом, а ваш аккаунт упёрся в один из лимитов, которые хостинг выдаёт каждому клиенту на общем сервере. Сайт вернётся сам через минуту-другую, когда нагрузка спадёт, и в этом главная ловушка: проблема выглядит случайной, а на деле повторяется под нагрузкой и никуда не денется, пока вы не уберёте причину.
Что сделать в первую очередь, ещё до всякой теории: зайдите в панель хостинга, в cPanel это раздел Logs → Resource Usage, и посмотрите на faults – счётчик срабатываний лимита. Он покажет, в какой именно лимит вы упираетесь: число одновременных процессов, процессор или память. От этого зависит вообще всё дальнейшее лечение, потому что три причины лечатся тремя разными способами, и накрутить не тот лимит – значит не сделать ничего.
Дальше – почему код 508 вообще означает то, что означает, и почему он так упорно скрывает, что именно у вас кончилось.
У кода 508 есть два совершенно разных значения
Это стоит разложить первым, потому что путаница начинается прямо здесь. Если открыть стандарт – RFC 5842 – там 508 называется Loop Detected, «обнаружен цикл». Код придумали для WebDAV: сервер обходит дерево папок, натыкается на ссылку, которая закольцовывает структуру саму на себя, и прекращает операцию, чтобы не уйти в бесконечный цикл. К нехватке ресурсов это не имеет никакого отношения – речь про защиту от зацикливания при обходе каталогов.
А теперь то, что видите вы на украинском виртуальном хостинге. Здесь те же три цифры означают совсем другое – «Resource Limit Is Reached», достигнут лимит ресурсов. Так вышло, что CloudLinux и веб-сервер LiteSpeed переиспользовали свободный номер под своё сообщение. Формально это даже не ошибка LiteSpeed: CloudLinux сообщает, что аккаунт упёрся в лимит, а веб-сервер просто выносит наружу код 508. Тот же номер, другая история целиком.
Один код – два не пересекающихся смысла. Человек читает стандарт, натыкается на форумы про WebDAV-циклы и начинает искать цикл в своём коде, которого там нет. На виртуальном хостинге 508 почти всегда про ресурсы, а не про циклы. Провайдеры про эту подмену обычно молчат: на странице ошибки стоит «Resource Limit Is Reached», и хорошо, если стоит хоть это, а не голые три цифры.
Код говорит «лимит достигнут», но не говорит какой
Самое неприятное в 508 – не сам факт лимита, а его немота. Страница сообщает, что лимит ресурса достигнут, и на этом замолкает. А ресурсов, которые CloudLinux считает по отдельности, несколько: число одновременных процессов, процессорное время, оперативная память, общее число процессов в аккаунте. У каждого свой потолок, своё поведение при упоре и свой способ лечения. Одна и та же надпись 508 спокойно прячет за собой четыре разные причины.
Подвох в том, что раз причина не названа, человек чинит наугад. Самый частый рефлекс – «мне мало ресурсов, возьму тариф пожирнее» или «попрошу поднять лимит». Иногда это срабатывает, чаще – деньги на ветер, потому что подняли не тот лимит. Прежде чем что-то менять, надо узнать, какой именно счётчик срабатывает, а видно это только в статистике LVE – той самой Resource Usage с колонкой faults. Про изоляцию аккаунтов и про то, откуда вообще берутся эти лимиты, у нас есть отдельный разбор – CloudLinux, если хочется понять механику целиком, а не только симптом.
Как прочитать Resource Usage и перестать гадать
Раздел Resource Usage в cPanel – это не украшение, а единственное место, где 508 перестаёт быть загадкой. По каждому ресурсу там показаны две вещи: текущее использование и faults – сколько раз за выбранный период вы упёрлись в потолок. Ноль faults по строке означает, что этот лимит вас ни разу не остановил; ненулевое число – вот он, виновник. Смотреть надо не на «сколько процентов занято сейчас», а именно на faults: сайт мог падать в час пик утром, а вы открыли панель днём, когда всё спокойно, и увидели зелёные графики. Faults же копятся за период и покажут вечерний или утренний всплеск, который вы вживую не застали.
Строк несколько, и каждая ведёт в свою сторону. Срабатывания по EP – это одновременные запросы, самый частый источник 508й ошибки. По CPU – процессорное время; тут, кстати, сайт обычно даже не отдаёт ошибку, а просто тормозит, так что 508я и CPU-faults вместе встречаются реже, чем можно подумать. По PMem – физическая память, и это уже другая история с 500й ошибкой и белым экраном. Пока вы не посмотрели, какая из строк ненулевая, любое лечение – стрельба вслепую, и именно на этом шаге люди чаще всего теряют время и деньги.
Статья длинная. Предлагаем сделать паузу и ознакомиться с лучшими украинскими хостинг-провайдерами из нашего рейтинга. По каждому есть подробный разбор: как тестировали, что с аптаймом, скоростью и поддержкой, где сильные и слабые стороны. Загляните в обзоры тех, кто вам интересен, почитайте отзывы клиентов.
Чаще всего это EP – число одновременных запросов
Если исключить редкие случаи, за ошибку 508 на виртуальном хостинге стоит лимит EP (entry processes — число процессов, которые одновременно «вошли» в ваш аккаунт и прямо сейчас что-то выполняют). Каждый запрос к PHP – это один такой процесс. Когда их в один момент набирается больше, чем разрешено тарифом, механизм CloudLinux перестаёт пускать новые и отдаёт им 508. Тяжёлый сайт при этом тормозит и сыпет 508, но соседей по серверу с собой не тянет – ради этого лимит и придуман: изолировать одного, чтобы не страдали остальные.
А вот наблюдение, которое переворачивает всю логику. EP – это не число посетителей. Это число запросов, которые выполняются в один и тот же момент, и разница тут огромная. Если страница генерируется за пятьдесят миллисекунд, процесс входит и почти сразу выходит – даже лимита в 20 EP хватает на тысячи посетителей в час. Если же страница готовится три секунды, процессы живут долго, накладываются друг на друга, очередь растёт – и те же самые посетители упираются в лимит. То есть 508 по EP – это чаще всего замаскированная проблема скорости, а не посещаемости. Почему при этом процессор остаётся почти на нуле и что конкретно так надолго занимает процессы — разобрано в отдельной статье про лимит EP.
На клиентских серверах это встречается постоянно: сайт со скромным трафиком ловит 508, владелец в панике открывает графики посещаемости – а там ничего экстремального. Просто каждая страница отдаётся медленно, и десяток одновременных запросов держат аккаунт занятым дольше, чем позволено. Есть ещё тонкость в том, как CloudLinux считает: если ваш PHP-скрипт по ходу дела запускает что-то ещё – отправку письма, обращение к базе – это не добавляет нового EP, всё внутри одного «входа» считается одним подключением. Так что дело именно в одновременных запросах снаружи, а не в том, сколько всего шевелится под капотом. Про случай, когда упор идёт именно в процессор, а не в число процессов, – подробно в статье про лимит CPU: там сайт не отдаёт ошибку вовсе, а просто вязнет.
Отдельно стоит сказать про тех, кого владелец в статистику посещений не записывает. Часть 508 приходит не от живых людей, а от ботов: агрессивные краулеры, парсеры цен, сканеры уязвимостей заходят пачками и держат по несколько одновременных запросов каждый. Для счётчика EP такой бот ничем не отличается от посетителя – процесс вошёл, процесс занял место. Поэтому сайт, у которого «по людям» трафика немного, вполне может ловить 508 из-за десятка ботов, долбящих тяжёлые страницы поиска или фильтры каталога. Прежде чем винить наплыв клиентов, стоит заглянуть в логи и посмотреть, кто на самом деле создаёт одновременную нагрузку. Отсечь агрессивных ботов на уровне сервера нередко оказывается быстрее и дешевле, чем разгонять сам сайт, и часто именно это снимает 508 без всяких доплат за тариф.
Поднять лимит EP – обычно не тот ход
Первое желание – попросить хостера добавить EP. Логика понятная: не хватает – дайте больше. Но если страницы медленные, больше EP просто отодвигает стену на пару шагов: очередь станет длиннее, а упор вернётся на следующем всплеске трафика.
Работает обратный заход – сделать так, чтобы до PHP доходило меньше запросов и каждый завершался быстрее. Кеширование страниц снимает основную массу нагрузки: закешированная страница отдаётся вообще без запуска PHP, то есть не тратит ни одного EP. Ускорение того, что закешировать нельзя, добивает остальное. Про скорость ответа сервера и из чего она складывается – в материале про TTFB. Настоящий рост EP-лимита оправдан только тогда, когда трафик реально вырос и кеш уже стоит, – но до этого доходит реже, чем кажется на первой панике.
Почему у соседа та же проблема выдаёт 503, а не 508
Один и тот же упор в лимит на разных серверах выглядит по-разному, и это сбивает с толку при поиске решения. На классическом Apache модуль, который следит за лимитами, отбивает лишний запрос сразу – вы моментально получаете 508. На LiteSpeed поведение мягче: лишние запросы сначала встают в очередь и ждут, пока освободится место, и только если не дождались за отведённое время – тогда отдаётся ошибка. Поэтому на LiteSpeed вместо честного 508 вы можете увидеть 503, а можете просто долгую загрузку без всякой ошибки.
Из-за этого добрая половина советов из интернета не срабатывает: человек ищет «как убрать 508», а у него на сервере тот же лимит маскируется под 503 или под тормоза. Если хочется разобраться, чем вообще отличаются Apache и LiteSpeed в обработке запросов, есть разбор веб-серверов. А общий расклад по кодам ответа, включая соседние 500, 503 и 504, разложен в статье про HTTP-статусы – 508 удобнее понимать рядом с ними, а не в вакууме.
Звучит странно, но одна и та же болячка на двух хостингах называется двумя разными кодами. Кстати, именно поэтому часть провайдеров вообще предпочитает отдавать 503: он привычнее и меньше пугает клиента непонятными цифрами.
Когда 508 – это всё-таки память или настоящий цикл?
EP – самый частый, но не единственный виновник. Иногда за похожими симптомами стоит нехватка памяти: один PHP-процесс превысил свой потолок. Но упор в память обычно проявляется иначе – как 500 или 503, белый экран, оборванная загрузка, а не как аккуратное «Resource Limit Is Reached». Если faults показывают срабатывания по PMem, а не по EP, – это память, и лечится она по-своему: разбором того, что съедает оперативку, и правкой лимита. Мы подробно развели лимит страницы и лимит аккаунта в статье про memory_limit и PMEM – там же про то, почему реальный расход памяти заметно больше, чем показывает счётчик PHP.
И совсем редкий случай – тот самый 508 из стандарта, настоящий цикл. Скрипт, который вызывает сам себя без выхода; цепочка редиректов, замкнутая в кольцо; правило в .htaccess, отправляющее страницу саму на себя. Отличить это от ресурсного 508 несложно по одному признаку: ресурсный приходит и уходит сам, привязан к нагрузке и часам пик; цикл же воспроизводится стабильно, на каждом заходе, есть трафик или нет. Если сайт отдаёт 508 ровно и всегда – смотрите в сторону цикла. Если рвано и под нагрузкой – это ресурсы.
Одна ошибка, два взгляда
Со стороны клиента картина обычно такая: сайт то работает, то нет, в панели всё зелёное, а поддержка отвечает шаблоном – «оптимизируйте нагрузку» или «рассмотрите тариф выше». Выглядит как отписка, и обиднее всего именно это.
Со стороны хостера та же ситуация выглядит иначе. Провайдер видит в статистике LVE ваш аккаунт со срабатываниями по EP – конкретные цифры, конкретные часы. «Оптимизируйте нагрузку» для него не вежливый способ отмахнуться, а буквально то, что показывает мониторинг: запросы копятся, лимит переполняется, упирается всё в скорость генерации. Провайдеры видят такую картину каждый день, и по их меркам совет честный – беда лишь в том, что он ничего не говорит клиенту о том, что конкретно делать руками.
Есть ещё деталь, которая пугает новичков. На странице 508 иногда стоит подпись вроде «Proudly powered by LiteSpeed Web Server», и человек решает, что сайт взломали и подменили. Ничего подобного: это стандартная страница веб-сервера, которую он показывает вместо вашего сайта, пока тот сидит в лимите. Взлом тут ни при чём, и подпись эту ставит не злоумышленник, а сам сервер.
Что с этим делать по порядку
Начните с faults в Resource Usage – они называют виновника, и без этого шага всё остальное превращается в гадание. Срабатывания по EP означают упор в одновременность: ставьте кеширование страниц и разбирайтесь, почему страницы генерируются медленно, – и лимит перестанет переполняться. Срабатывания по CPU – это процессор, тут поможет разбор из статьи про лимит CPU, и снова упор в скорость, а не в докупку. Срабатывания по PMem – память, о ней сказано выше. Разница между этими путями принципиальная: кеш и ускорение убирают 508 насовсем, а поднятый лимит лишь оттягивает следующий упор, поэтому начинать почти всегда стоит с причины, а не с потолка. И только если faults чистые, а трафик реально и устойчиво вырос, – тогда разговор про тариф выше или про переход на VPS становится осмысленным: там ресурсы ваши и лимиты вы ставите сами.
Если сводить всё к одному: 508 на виртуальном хостинге почти всегда не «мало памяти» и не «сервер сломался», а «слишком много одновременных запросов, потому что каждый идёт слишком долго». Памятью это не лечится. Лечится скоростью.
Источники
- RFC 5842 (IETF) – определение кодов 508 Loop Detected и 208 в стандарте WebDAV Binding Extensions.
- CloudLinux Documentation – Limits – как устроены лимиты LVE (CPU, память, IO, EP) и почему при упоре в EP возвращается именно 508.
- LiteSpeed Documentation – CloudLinux Issues – 508 Resource Limit Reached и его связь с лимитом одновременных подключений.
FAQ по ошибке 508
Что означает ошибка 508 Resource Limit Is Reached?
На виртуальном хостинге это сообщение о том, что ваш аккаунт упёрся в один из лимитов, которые провайдер выдаёт каждому клиенту на общем сервере. Чаще всего речь про число одновременных процессов, реже — про процессор или память. Сайт обычно возвращается сам через минуту-другую, когда нагрузка спадёт, но проблема повторяется под нагрузкой, пока не убрать причину.
508 — это то же самое, что 508 Loop Detected из стандарта?
Нет, это два разных смысла одного номера. По стандарту RFC 5842 код 508 называется Loop Detected и означает бесконечный цикл при обходе каталогов в WebDAV. CloudLinux и LiteSpeed переиспользовали свободный номер под своё «Resource Limit Is Reached», и на хостинге вы почти всегда видите именно ресурсный вариант, а не цикл.
Мой сайт взломали, раз показывает 508 и подпись LiteSpeed?
Нет. Подпись вроде «Proudly powered by LiteSpeed Web Server» на странице 508 ставит сам веб-сервер, а не злоумышленник. Это стандартная страница, которую сервер показывает вместо вашего сайта, пока аккаунт сидит в лимите. Взлом тут ни при чём.
Почему 508 появляется и исчезает сама по себе?
Потому что это не крах, а временное ограничение по нагрузке. Когда одновременных запросов становится больше лимита, лишние получают 508; как только нагрузка спадает, всё возвращается. Именно из-за этой «мигающей» природы проблему легко принять за случайность, хотя она стабильно повторяется в часы пик.
Что такое лимит EP и при чём он к 508?
EP — это entry processes, число процессов, которые одновременно вошли в ваш аккаунт и прямо сейчас что-то выполняют. Каждый запрос к PHP занимает один такой процесс. Когда их набирается больше, чем разрешено тарифом, CloudLinux перестаёт пускать новые и отдаёт им 508.
EP — это ограничение на число посетителей?
Нет, это число запросов, выполняемых в один и тот же момент, а не всего посетителей. Если страница генерируется за миллисекунды, процесс входит и почти сразу выходит, и небольшого лимита хватает на тысячи человек. Если страница готовится по несколько секунд, процессы накапливаются, и те же посетители упираются в лимит — поэтому 508 по EP чаще про скорость, чем про трафик.
Поможет ли докупить памяти, если сайт отдаёт 508?
Обычно нет. Если faults срабатывают по EP, дело в числе одновременных запросов, а не в памяти, и лишние гигабайты ничего не изменят. Память имеет смысл трогать только тогда, когда счётчик показывает срабатывания именно по PMem, — а это уже другая история, ближе к 500 и белому экрану.
Почему у меня 508, а на другом хостинге та же нагрузка даёт 503?
Всё зависит от веб-сервера. На классическом Apache модуль лимитов отбивает лишний запрос сразу — вы видите 508. На LiteSpeed запросы сначала встают в очередь, и вместо 508 может прийти 503 или просто долгая загрузка, поэтому советы из интернета часто не совпадают с тем, что вы видите у себя.
Как понять, в какой именно лимит я упираюсь?
Откройте в cPanel раздел Logs → Resource Usage и посмотрите на faults — счётчик срабатываний по каждому ресурсу. Ненулевое число напротив строки и есть виновник: EP, CPU или PMem. Смотреть надо именно на faults за период, а не на текущую загрузку, потому что упор мог случиться в час пик, которого вы вживую не застали.
Стоит ли просить хостера поднять лимит EP?
Как первый ход — почти никогда. Если страницы медленные, больше EP лишь отодвигает упор на следующий всплеск, а очередь просто станет длиннее. Сначала стоит поставить кеширование и ускорить генерацию страниц, и только когда трафик реально вырос при уже настроенном кеше — тогда поднятие лимита оправдано.
Когда 508 — это настоящий цикл, а не нехватка ресурсов?
Отличить помогает характер появления. Ресурсный 508 приходит и уходит сам, привязан к нагрузке и часам пик. Настоящий цикл — зациклённый редирект, правило в .htaccess, ссылающееся само на себя, скрипт без выхода — воспроизводится стабильно на каждом заходе, независимо от трафика. Ровный и постоянный 508 — повод искать цикл, рваный и под нагрузкой — ресурсы.
Когда пора менять тариф или переходить на VPS из-за 508?
Тогда, когда faults чистые после кеширования и оптимизации, а трафик реально и устойчиво вырос. Пока упор снимается ускорением сайта, смена тарифа — лишние деньги. Переход на VPS осмыслен, когда ресурсы нужны свои и лимиты вы хотите ставить сами, а не когда просто хочется убрать 508 побыстрее.