Ви купили тариф, де великими літерами написано «512 МБ памʼяті», і тримаєте в голові одну цифру: ось моя стеля. Стеля в акаунта не одна. Їх з десяток, кожна перевіряється сама по собі, і гальмує чи падає сайт зазвичай через той ліміт, за яким ви якраз не стежили.
Якщо ви прийшли з конкретною бідою – сайт раз у раз віддає помилку, гальмує на рівному місці, «раптом закінчилося місце» за напівпорожнього диска, гортайте одразу до таблиці нижче: там симптом і те, куди дивитися. Усім іншим варто витратити пʼять хвилин на загальну карту. Далі ви упретеся вже в інший паркан, і знати заздалегідь, де він стоїть, дешевше, ніж зʼясовувати за аварією.
Звідки ліміти беруться взагалі, розібрано в тексті про CloudLinux – систему, яка на більшості віртуальних хостингів ділить один сервер між сотнями акаунтів. Тут важливе інше: лімітів багато не тому, що хостер жадібний, а тому що ресурс не один, і кожен доводиться стерегти окремо.
Чому парканів (лімітів) так багато
З боку провайдера картина проста. На одній машині живуть сотні чужих сайтів, і будь-який з них може одного дня збожеволіти, наприклад, зациклений скрипт, кривий плагін, нічний бекап, що читає диск без упину. Якщо нічим це не обгородити, один такий сусід кладе всіх. Тому кожному акаунту ставлять паркан.
Паркан потрібен не один. Скрипт може майже не їсти памʼять, але вкрай завантажити диск дрібними читаннями; може бути легким по диску, але зʼїдати процесор; може спокійно працювати наодинці й захлинутися, коли на сайт разом зайшли двісті людей. Один лічильник усі ці випадки не покриє, бо під кожен тип навантаження потрібен свій. Так їх і набирається одразу кілька: процесорний час, памʼять, число одночасних процесів, місце на диску, кількість файлів, швидкість і частота звернень до диска. Пів дюжини незалежних лімітів, і це ще скромний набір.
Що варто зрозуміти від самого початку: провайдеру зазвичай немає сенсу занижувати ліміти штучно, адже обмеження потрібні насамперед, щоб тримати навантаження під контролем і захищати решту акаунтів. Тікет у підтримку до того ж коштує йому дорожче, ніж процесорні секунди, які ви могли б витратити. Паркан він ставить не на покарання вам, а на захист вашого сусіда, ну і вас від сусіда. На більшості нормальних хостингів ліміти виставлені із запасом, і впираються в них не «важкі» сайти, а сайти з проблемою, про яку власник не знає.
У самих цифр ліміту логіка теж провайдерська. Сервер на shared-хостингу за замовчуванням розрахований на те, що акаунти не вибиратимуть свої ліміти на максимум одночасно. Так найчастіше і є: піки в сайтів не збігаються, і запасу вистачає на всіх. Ліміт на акаунт – це страховка на випадок, коли розрахунок не сходиться: він не дає одному сайту забрати частку, відкладену під сусідів. Тому однаковий на папері тариф на порожньому сервері й на щільно набитому відчувається по-різному, хоча цифри в панелі ті самі.
Хто тут живе
Найпростіше розкласти ліміти за тим, що кожен з них стереже.
Процесорний час
Це не «наскільки швидкий у вас сервер», а яку частку ядра вам дозволено займати. Рахується у відсотках, де 100% – це одне ціле ядро. Коли ви впираєтеся, сервер не видає помилку, він вас пригальмовує: запити стають у чергу, сторінка збирається не за триста мілісекунд, а за дві секунди. Тому CPU-ліміт і важко впіймати: сайт не лежить, просто стає вʼязким. Докладно цей випадок, «памʼяті вагон, а сайт ледь ворушиться», розібрано в окремому тексті про ліміт процесора.
Памʼять
Тут живе найзастаріліша плутанина на всьому хостингу. У налаштуваннях PHP є memory_limit – скільки оперативки дозволено одному скрипту. А є PMEM – скільки памʼяті взагалі відведено всьому акаунту. Людина піднімає memory_limit до 512 МБ, вважає, що тепер у неї пів гігабайта, і все одно ловить білий екран, бо реальний паркан, PMEM, стоїть нижче, а memory_limit у PHP усе одно не відображає всю витрату памʼяті акаунта. Різницю й те, за якою цифрою рахувати насправді, я розбирав у тексті про memory_limit і PMEM.
Одночасність
Тут два ліміти, які постійно плутають. EP (entry processes) – скільки запитів одночасно ввійшло всередину ізоляції акаунта (LVE) і зайняло цей ліміт. Для сайту це передусім паралельні звернення до динамічних скриптів, але туди ж можуть потрапляти cron і SSH. Не скільки людей на сайті, а скільки просто в цю секунду щось рахується на сервері. Звичайний тариф дає близько двадцяти таких входів, тариф дорожчий – сорок. Вичерпали – і на Apache сервер одразу віддає 508-му помилку. Другий, NPROC, – це загальне число процесів акаунта, куди входять не лише вебзапити, а й cron із SSH. NPROC зазвичай ставлять вищим за EP, бо він обмежує вже загальне число процесів усередині ізоляції, і впираються в нього рідше, але симптом інший, тому ліміту процесів відведено свій розбір.
До речі, тонкість, через яку EP лякає сильніше, ніж варто було б: EP не рахує кожен дочірній процес окремо. Скрипт викликав базу, надсилання листа, зовнішню команду, але для EP це так само один вхід. Тож двадцять EP – це не про число відвідувачів. Це двадцять запитів, які виконуються в один момент, і для середнього сайту такий запас зазвичай не малий.
Диск
Теж два різні паркани. Перший – місце в мегабайтах, він зрозумілий. Другий – число файлів, inode, і ось він ловить людей зненацька: сайт пише «No space left on device», а по диску зайнято відсотків шістдесят. Просто файлів уже більше, ніж дозволено, а важать вони копійки: тисячі дрібних файлів кешу, стара пошта, сесії. Куди саме витікає квота, коли цифри не сходяться, – тема окремого тексту про приховану витрату місця.
Введення-виведення
Найтихіший і найнедооціненіший ліміт. Їх знову два: смуга – скільки мегабайтів за секунду вам дозволено читати й писати (типове значення близько одного, на швидких тарифах до чотирьох), і IOPS – скільки окремих операцій із диском за секунду. Сайт із купою вільної памʼяті й незавантаженим процесором може гальмувати саме тут, і здогадатися складно, бо в тарифі цих цифр зазвичай немає взагалі. Що відбувається, коли впираєшся у смугу і коли в число операцій, рознесено по двох текстах – про смугу дискового I/O і про ліміт IOPS.
Різниця між смугою й числом операцій важливіша, ніж здається. Великий файл – відео, архів бекапу – упирається у смугу: даних багато, а операцій мало. Галерея з сотень дрібних превʼю навпаки: кожного кілобайта трохи, але звернень до диска тисячі, і першим закінчується IOPS. Тому сайт з однією важкою картинкою і сайт із горою дрібних файлів гальмують за різними лімітами, хоча на словах і там, і там «диск не тягне».
Одна деталь, яка заощаджує години діагностики: звернення до дискового кешу в ліміт I/O не зараховуються. Файл, який сервер уже тримає в памʼяті, можна читати хоч тисячу разів безкоштовно. Тому два однакові на вигляд сайти поводяться по-різному: в одного гарячі дані лежать у кеші, в іншого кожен запит лізе на реальний диск.
Стаття довга. Пропонуємо зробити паузу та ознайомитися з найкращими українськими хостинг-провайдерами з нашого рейтингу. На кожного з них є детальний аналіз: як проводилося тестування, як справи з аптаймом, швидкістю та підтримкою, які сильні та слабкі сторони. Загляньте в огляди тих, хто вас цікавить, прочитайте відгуки клієнтів.
Чому лагодити доводиться по колу
Ліміти незалежні, і це виходить боком під час ремонту. Ви знаходите витік памʼяті, сайт перестає видавати білий екран, а за тиждень починає гальмувати, бо той самий важкий плагін, що їв памʼять, не легший і по процесору. Розбираєтеся з процесором, і у стелю впираються нічні бекапи, тепер уже по введенню-виведенню. І так по колу… Кожен паркан стоїть сам по собі, тому, розвантаживши один ресурс, ви просто пересуваєте навантаження на наступний. «Додайте памʼяті» майже ніколи не закриває питання цілком, тобто лікує один симптом із кількох.
Поставивши монітор запитів, власники магазину нерідко виявляють, що найважчий у них не каталог і не кошик, а давно занедбаний конструктор сторінок, який вантажить і памʼять, і процесор, і диск разом. Прибрали його – і відпустило по всіх трьох лімітах одразу. Такі знахідки збоку видно куди частіше, ніж здається: справжній пожирач ресурсів зазвичай не той, на кого думають насамперед.
Хто вас укусив
Якщо сайт уже поводиться дивно, а копатися в теорії ніколи, тримайте коротку зведення: симптом ліворуч, імовірний винуватець праворуч. Вона не замінює діагностику, але звужує коло підозрюваних.
| Симптом | Найімовірніше це | Куди дивитися |
|---|---|---|
| 508 або «resource limit is reached» | досягнуто LVE-ліміт, найчастіше EP (Apache) | Resource Usage → faults за лімітами |
| Білий екран після оновлення плагіна чи теми | памʼять: PMEM або memory_limit | лог помилок, графік PMEM |
| Гальмує, при цьому памʼять і процесор вільні | смуга I/O або IOPS | графіки I/O і faults по них |
| Гальмує під навантаженням, памʼять у нормі | CPU-ліміт, іде тротлінг | графік CPU, faults по CPU |
| «No space left on device», а диск не повний | закінчилися inode | число файлів: кеш, пошта, сесії |
| 503 час від часу на LiteSpeed | не обовʼязково EP | конфігурація PHP, лог – ширше |
| cron не доходить до кінця | NPROC або CPU у момент запуску | список процесів, час старту завдань |
Окремо про передостанній рядок. На Apache вичерпання EP зазвичай дає саме 508, і це добрий перший орієнтир. На LiteSpeed EP влаштований інакше, і періодична 503 там прилітає з найрізноманітніших причин, вішати її на ліміт процесів не варто, поки не подивилися логи. Що взагалі означають ці коди і чим 508 відрізняється від 503 і 504, зібрано в тексті про коди відповіді HTTP.
Мʼякий ліміт і жорсткий
Ліміти гасять навантаження по-різному, і від цього залежить, переживете ви сплеск чи ні. Мʼякий ліміт вас пригальмовує: черга, затримка, але сайт працює. Жорсткий – обрубує одразу. CPU зазвичай мʼякий: уперлися у стелю – вас притримують, відпустило – поїхали далі. EP жорсткий: якщо всі двадцять входів зайняті, наступний запит, якому потрібен новий вхід, отримує 508 без розмов. Розбір, які ліміти поводяться як і чому це важливо під час вибору тарифу, – у тексті про мʼякі та жорсткі ліміти.
І ось що панель показує погано. Графік «використання 85%» лякати вас не має, поки ви під стелею, усе гаразд, навіть впритул. Дивитися треба не на лінію використання, а на лічильник faults, тобто скільки разів за добу ви реально вперлися в паркан. Нуль faults за завантаження в 90% означає лише, що за цим лімітом ви поки не впиралися у стелю. Десяток faults за середнього завантаження 40% – це сайт, який смикається у стелю піками, і ось із цим уже треба розбиратися.
До речі, деякі хостери лічильник faults у панелі взагалі не виводять – лінія використання виглядає спокійніше, і питань від клієнта менше. Якщо у вас його не видно, а сайт періодично дивакує, є сенс запитати підтримку напряму: скільки було faults і за яким лімітом.
Чого немає в тарифі
Найнеприємніше тут, те, що у вітрині тарифу ви бачите не ті ліміти, які вас реально зупинять. На сторінці з цінами великими літерами пишуть місце на диску й «безлімітний трафік», іноді памʼять. А EP, IOPS, смуга I/O і NPROC – ті самі ліміти, в які впирається живий сайт, – часто не вказані ніде. Їх доводиться випитувати в підтримки або дізнаватися за фактом першої аварії.
Логіку хостера тут зрозуміти можна. Ці цифри важко порівнювати між тарифами, вони лякають новачка й майже нічого йому не кажуть, а місце на диску обіцяти дешево. Так зʼявляється й «безлімітний» хостинг, який технічно не бреше: диск і трафік справді можна не рахувати, бо паркан стоїть не там, він стоїть на inode, EP і введенні-виведенні, і ось вони дуже навіть скінченні. Чому «безлім» – це перенесення ліміту, а не його відсутність, розкладено окремо в тексті про «безлімітний» хостинг.
Ще одне читається в тарифі не одразу: ресурс можуть назвати гарантованим, а можуть – burst, «до стільки-то». Але що стоїть за цими словами, залежить від політики конкретного провайдера: за одним формулюванням у тарифі не можна вважати, що вам фізично зарезервували відповідну частку заліза: LVE-ліміт узагалі задає стелю споживання, а не виділену вам частину сервера. На порожньому сервері різниця непомітна, на щільному може бути відчутною. Чим гарантовані ресурси відрізняються від burst і коли переплата за гарантію виправдана, розібрано в тексті про гарантовані та burst-ресурси.
Витягнути реальні числа до купівлі можна трьома шляхами. Перший – заглянути в панель на поточному хостингу: у cPanel розділ Resource Usage показує і ліміти, і історію faults за кожним з них. Другий – прямо запитати підтримку майбутнього хостера, які EP, IOPS і смуга I/O на тарифі, що цікавить; чесний відповість цифрами, а ухильна відповідь – це теж відповідь. Третій – не вірити вітрині в принципі й дивитися, як хостинг поводиться на тестах: за яким принципом ми ганяємо провайдерів і чому вітринним цифрам вірити не можна, описано в методиці рейтингу, а який тариф дає більше за свої гроші – рахує індекс TVI.
Пару років тому звернення в дусі «сайт падає, а хостинг каже, що все гаразд» ішли валом, і майже завжди упор був саме в невидимий ліміт, той самий, якого в тарифі не було. З боку клієнта це має вигляд прискіпування провайдера, з боку провайдера – чесно вичерпаного ресурсу, про який просто забули написати на сторінці з цінами.
Один ліміт – десять імен
Останнє, що варто тримати в голові під час порівняння тарифів: той самий паркан у різних хостерів називається по-різному. EP десь «entry processes», десь «одночасні підключення», десь «паралельні процеси». PMEM перетворюється на «фізичну памʼять» або просто «RAM». Порівнювати тарифи треба за змістом ліміту, а не за словом у таблиці, інакше легко вирішити, що у двох хостерів різні обмеження, хоча за різними назвами стоїть рівно те саме.
Джерела
- CloudLinux – Limits (SPEED, PMEM, IO, IOPS, EP, NPROC, inode)
- CloudLinux – EP and NPROC limits: a look from inside
- CloudLinux – LVE limits: default and recommended values
F.A.Q. по лімітам акаунту
Скільки насправді лімітів у хостинг-акаунта?
Зазвичай близько десятка, і перевіряється кожен сам по собі: процесорний час (CPU), памʼять (PMEM), число одночасних входів (EP), загальне число процесів (NPROC), число файлів (inode), місце на диску, смуга I/O та IOPS. Зупиняє сайт найчастіше не той ліміт, за яким власник стежив. Тому однієї цифри з тарифу тримати в голові замало – упертися можна в будь-який із парканів.
Чому сайт гальмує, хоча памʼяті й місця вистачає?
Вільна памʼять не означає, що вільні інші ресурси. Найчастіше в такому разі упор іде в CPU-ліміт (сервер пригальмовує вас, не видаючи помилку) або у введення-виведення – смугу I/O чи IOPS. Памʼять і процесор при цьому можуть бути майже порожніми, а сайт усе одно вʼязкий. Дивитися треба на графіки I/O і на лічильник faults за цими лімітами.
Що означає помилка 508 і з яким лімітом вона повʼязана?
На Apache 508 найчастіше означає досягнутий LVE-ліміт, і найчастіший його винуватець – вичерпані EP, одночасні входи в ізоляцію акаунта. Усі дозволені входи зайняті, і наступний запит, якому потрібен новий вхід, відбивається одразу. На LiteSpeed EP влаштований інакше, і періодична 503 там не обовʼязково повʼязана з цим лімітом – варто спершу подивитися логи. Тому 508 на Apache – добра причина насамперед перевірити EP.
Чим PMEM відрізняється від memory_limit?
memory_limit – це налаштування PHP: скільки оперативки дозволено одному скрипту. PMEM – скільки памʼяті відведено всьому акаунту цілком, і цей паркан зазвичай стоїть нижче. Підняти memory_limit до 512 МБ можна, але реальною стелею залишиться PMEM, а сам memory_limit не відображає всю витрату памʼяті акаунта. Рахувати треба за PMEM і за більшою цифрою.
Чому сайт пише «No space left on device», якщо диск не повний?
Найімовірніше, закінчилися не мегабайти, а inode – число файлів, яке дозволено тримати на акаунті. Файлів уже більше за ліміт, хоча важать вони копійки: тисячі дрібних файлів кешу, стара пошта, сесії. По диску при цьому зайнято може бути відсотків шістдесят. Дивитися потрібно лічильник файлів, а не вільне місце.
У чому різниця між EP і NPROC?
EP рахує одночасні входи в ізоляцію акаунта – для сайту це передусім паралельні запити до динамічних скриптів. NPROC рахує взагалі всі процеси акаунта, зокрема cron і SSH. NPROC зазвичай ставлять вищим за EP, і впираються в нього рідше. Симптоми в них різні, тому й плутати їх не варто.
Що таке faults і чому на нього важливо дивитися?
Faults – це лічильник того, скільки разів за добу ви реально вперлися в ліміт. Лінія використання в 85% лякати не має: поки ви під стелею, усе гаразд. А ось faults більше за нуль – це вже сигнал, навіть якщо середнє завантаження виглядає скромним. Деякі хостери цей лічильник у панелі не показують, і тоді його варто запитати в підтримки.
Чим IOPS відрізняється від смуги I/O?
Смуга – це скільки мегабайтів за секунду вам дозволено читати й писати; у неї впираються великі файли на кшталт відео та архівів бекапу. IOPS – це число окремих операцій із диском за секунду; у нього впирається гора дрібних файлів, наприклад галерея із сотень превʼю. Один сайт може гальмувати за смугою, інший за IOPS, хоча на словах в обох «диск не тягне». Звернення до дискового кешу при цьому в ліміт I/O не зараховуються.
Чому в тарифі не вказують EP, IOPS і смугу I/O?
Ці цифри важко порівнювати між тарифами, новачку вони мало що кажуть, а місце на диску обіцяти дешево й наочно. Тому у вітрині пишуть диск і «безлімітний трафік», а ліміти, в які реально впирається сайт, залишаються поза кадром. Дізнатися їх можна в підтримки або за фактом першої аварії. Ухильна відповідь на таке питання – це теж відповідь.
«Безлімітний» хостинг – це правда чи маркетинг?
Технічно «безлім» не бреше: диск і трафік справді можна не рахувати. Але паркан при цьому стоїть не там – він стоїть на inode, EP і введенні-виведенні, і ось ці ресурси дуже навіть скінченні. Тобто ліміт нікуди не подівся, його просто перенесли на те, що в рекламі не показують. Тому «безлімітний» тариф упирається в стелю аж ніяк не рідше за звичайний.
Як дізнатися реальні ліміти свого тарифу?
На хостингу з cPanel є розділ Resource Usage – він показує і самі ліміти, і історію faults за кожним з них за останню добу. Можна запитати підтримку напряму, які EP, IOPS і смуга I/O на вашому тарифі. І вітринні цифри з реальною поведінкою хостингу – не одне й те саме, тому корисно дивитися на результати незалежних тестів.
Я додав памʼяті, а сайт усе одно гальмує. Чому?
Ліміти незалежні один від одного, тому, розвантаживши памʼять, ви просто пересуваєте навантаження на наступний ресурс. Той самий важкий плагін, який їв памʼять, зазвичай не легший і по процесору, а слідом у стелю впираються бекапи по введенню-виведенню. «Додайте памʼяті» закриває один симптом із кількох, а не проблему цілком. Розбиратися доводиться по колу, поки не знайдеться справжній пожирач ресурсів.