Сайт час від часу виводить білу сторінку з написом «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-процесом, тож ресурсоємне завдання cron перекриває доступ для реального трафіку в найневідповідніший момент.
Поруч майже завжди боти. Реальні відвідувачі приходять по-різному, а пошуковий краулер, парсер або сканер вразливостей здатний відкрити два десятки сторінок за одну секунду – і створює ту саму одночасність, якої не забезпечує людський трафік. Query Monitor допомагає розгледіти, що гальмує всередині конкретного запиту WordPress – повільний SQL, завислий зовнішній виклик, «ненажерливий» плагін. А хто саме створює потік одночасних запитів, видно вже не в ньому, а в логах доступу та серверній статистиці: саме там нерідко з’ясовується, що пік спричиняє не наплив покупців, а бот, що занадто часто звертається, або давно занедбаний плагін.
Як це виглядає на практиці – досить типова картина для інтернет-магазинів. Щовечора, у годину найвищого трафіку, сайт починає час від часу показувати помилку 508, а до ночі все минає само собою. Насамперед звинувачують у цьому брак пам’яті або слабкий тариф, докуповують ресурси – не допомагає. А виявляється, що некешована сторінка категорії збиралася базою по кілька секунд, і у вечірній пік таких збірок набиралося стільки, що ресурси вичерпувалися. Варто було закешувати виведення категорій – вечірні 508 зникли, хоча тариф залишився колишнім. Окремо підступна ситуація, коли весь потік гальмує одна залежність: почав повільно відповідати платіжний шлюз – і невеликий магазин натрапляє на EP через чужий сервіс, до якого сам не має жодного стосунку.
EP, CPU, пам’ять і NPROC – чотири різні обмеження, які постійно плутають
Помилка 508 збиває з пантелику тим, що сама по собі не вказує, який саме ліміт вичерпано, – це свого роду «чорний ящик». А лімітів на акаунті кілька, і вони поводяться по-різному. Симптом підказує напрямок, але остаточно питання вирішує не він, а faults.
| Обмеження | Що може відбуватися | Куди дивитися |
|---|---|---|
| EP | 508 при досягненні ліміту одночасних входів | EP-помилки |
| CPU / IO | запити починають оброблятися повільніше | Помилки CPU / IO |
| PMEM | процеси можуть завершуватися з помилками | Помилки PMEM |
| NPROC | нові процеси не можуть бути створені | NPROC faults |
NPROC варто розмежувати з EP окремо, оскільки їх найчастіше плутають. NPROC – це загальна кількість процесів облікового запису: сюди входять не тільки веб-запити, а й сесії SSH, завдання cron, поштові процеси. 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
Ознака одна: помилки EP залишаються навіть після того, як ви налаштували кеш і розібралися з повільними запитами, а трафік при цьому реально й стабільно зріс. Поки акцент робиться на прискоренні сайту – зміна тарифу лише маскує проблему за ваші гроші. Перехід на VPS виправданий не тоді, коли хочеться якнайшвидше усунути 508, а коли потрібні власні ресурси і ви хочете самостійно встановлювати ліміти. Це вже інша розмова й інший бюджет – але принаймні ви змінюватимете тариф через реальне зростання, а не через забутий плагін, який на кожній сторінці звертався до бази двадцять разів. І ще: перш ніж обирати VPS, тверезо оцініть, чи готові ви самі стежити за оновленнями та безпекою сервера, – разом із своїми лімітами ви берете на себе й адміністрування, яке на загальному хостингу за вас виконував провайдер.
Джерела
- Документація CloudLinux OS – Обмеження (EP, NPROC, поведінка 508)
- CloudLinux – обмеження EP та NPROC, погляд зсередини
- CloudLinux – Обмеження LVE: значення за замовчуванням та рекомендовані
- LiteSpeed Wiki – CloudLinux LVE проти LSWS PHP suEXEC Max Conn
FAQ по статті
Що таке EP (Entry Processes) на хостингу?
EP – це обмеження на кількість запитів, які обліковий запис обробляє одночасно. Найпростіше уявити це як кількість кас у магазині: поки запит обробляється PHP, одне «віконце» зайняте, а коли обробка завершилася – воно звільнилося. На типовому віртуальному хостингу таких віконець близько двадцяти, на потужніших тарифах – сорок. Це ліміт одночасності, а не потужності.
Чому сайт видає помилку 508, якщо процесор не завантажений?
Тому що «віконце» EP займає не той, хто навантажує процесор, а той, хто просто займає місце. Запит, який чекає на відповідь від повільної бази даних або зовнішнього сервісу, весь цей час майже не використовує процесор, але займає «віконце». Набереться два десятки таких запитів, що очікують, – і EP вичерпається при майже нульовому завантаженні процесора. Звідси й парадокс «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?
Тоді, коли помилки EP залишаються навіть після кешування та аналізу повільних запитів, а трафік реально й стабільно зріс. Поки проблему можна вирішити прискоренням роботи сайту – зміна тарифу просто маскує проблему за ваші гроші. Перехід на VPS має сенс, коли потрібні власні ресурси і ви хочете самостійно встановлювати ліміти, але разом із цим ви берете на себе й адміністрування сервера.