Сайт то падає, то оживає сам собою, а на білій сторінці – коротке «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 швидше.