Розглянемо ще один момент, пов’язаний із лімітами. Іноді трапляється так, що місце на диску є, памʼяті вистачає, процесор не в стелі – а сайт усе одно вʼязкий: сторінки відкриваються із затримкою, адмінка думає по кілька секунд. У цієї картини є неочевидний винуватець: ліміт IOPS, кількість звернень до диска за секунду. Впертися в нього можна, майже не витративши жодну зі звичних цифр.
Короткий план, якщо ви прийшли з палаючим сайтом. Відкрийте в cPanel розділ «Використання ресурсів» (Metrics → Resource Usage) і гляньте на рядки IOPS та I/O Usage за потрібний період. Якщо в стелю впирається саме IOPS, сайту бракує не потужності, а «пропускної здатності за операціями». Часта причина на WordPress – вимкнений або зламаний кеш плюс база, яка ганяє дрібні запити до диска пачками. Що робити далі й чому так вийшло – нижче.
Що таке IOPS і чому це не про обсяг диска
У диска є три різні характеристики, і плутають їх саме тому, що всі три «про диск». Обсяг відповідає на питання, скільки даних вміститься. Пропускна здатність (у панелі її зазвичай підписують як I/O) – скільки даних можна прочитати й записати за секунду, її міряють у KB/s або MB/s. А IOPS – скільки окремих операцій читання й запису диск встигає обслужити за ту саму секунду. Три відповіді на три різні питання, і сайт здатен впертися в будь-яку з них окремо.
Груба аналогія – склад. Обсяг це скільки коробок туди вміститься. Пропускна здатність – наскільки широкі ворота, скільки вантажу протягнеш за раз. А IOPS – скільки окремих ходок встигне зробити навантажувач. Можна катати порожній візок туди-сюди й впертися в кількість ходок, не перевізши майже нічого за вагою. З диском так само: тисяча крихітних запитів створює високий IOPS при майже нульовому трафіку.
Тонкість, яку варто тримати в голові: IOPS – це один із лімітів акаунта, а не головний і не єдиний. Поряд із ним живуть ліміти процесора, памʼяті, кількості процесів, і впертися сайт може в будь-який. IOPS часто лишається непоміченим: його не завжди вказують на сторінці тарифу, і його легко пропустити під час первинної діагностики. Ловлять його, як не дивно, останнім.
Як побачити проблему в cPanel і чому faults = 0 ще нічого не означає
Тут живе вся практична користь, тому трохи докладніше. Розділ «Використання ресурсів» (Metrics → Resource Usage) показує історію навантаження, а не лише стан у поточну секунду: чи впирався акаунт у якийсь із лімітів і коли саме. Період і деталізацію (день, година, хвилина) можна вибрати. Поряд стоять рядки CPU, Physical Memory, Entry Processes, I/O Usage, IOPS і Faults, і це різні вимірювання, які не можна валити в одну купу.
I/O Usage – це пропускна здатність дискового I/O, зазвичай у KB/s або MB/s. IOPS – кількість операцій. Сусіди по таблиці, але міряють різне й упираються нарізно: на клієнтських серверах постійно трапляється картина, коли I/O спокійний, а IOPS у стелі, або рівно навпаки. Що відбувається, коли впирається саме пропускна здатність, розбираємо в окремій статті про I/O та bandwidth диска.
Окремо про faults, бо тут плутаються найчастіше. Faults – це лічильник, скільки разів акаунт уперся у відповідний ліміт за період. Не індикатор здоровʼя диска й не сигнал «сайт хворий / здоровий». І ось неочевидний наслідок: сайт гальмує просто зараз, а faults по IOPS показує нуль, – це не суперечність. Панель показує історію, і ліміт міг бути досягнутий раніше й уже відпустити; гальмувати міг один важкий запит, що не добрав до порога; а вузьким місцем міг виявитися взагалі не диск, а процесор чи оперативна памʼять. До речі, тому дивитися варто не поточну секунду, а той період, у якому сайт справді гальмував: виберіть потрібний інтервал і роздивляйтеся графік там, а не в спокійний момент.
Нуль у графі faults означає «у вибраний період ліміт не пробивали», а не «з диском усе гаразд». Різниця важливіша, ніж здається.
Окрема складність у тому, що і ліміт процесора, і ліміт IOPS зовні виглядають однаково: «сайт повільний». Розрізняє їх характер гальмувань. Упор у CPU зазвичай рівний – важчає все підряд, бо процесорного часу бракує на самі обчислення. Упор в IOPS частіше рваний: сторінки без звернень до диска літають, а варто відкрити щось, що лізе в базу чи у файли, як воно зависає на рівному місці. Надійніше не гадати за симптомом, а звести час скарги з історією навантаження: у розділі «Використання ресурсів» можна дивитися не лише поточне значення, а й графік за потрібний інтервал. Окремі знімки навантаження при цьому відображають стан близько до моменту збою, але не дослівно, тож спиратися варто на картину за період, а не на одну точку – вона й покаже, який рядок реально впирався в стелю.
Ще одна деталь про поведінку, і тут варто навести дослівне формулювання, бо в ньому вся суть. У документації CloudLinux про досягнення ліміту IOPS сказано так:
«When the limit is reached the read/write operations stop until current second expires.» – CloudLinux Documentation
Українською: операції не відвалюються з помилкою, а притримуються до кінця поточної секунди й виконуються трохи згодом. Тому безпосередній ефект – затримка операцій читання й запису: найчастіше це відчувається як уповільнення, а не як окрема помилка на кшталт 508, яку відвідувач ловить при вичерпанні Entry Processes. Хоча, якщо затримка затягується або долучаються інші ліміти, конкретний запит усе ж може завершитися помилкою. Від того упор в IOPS і найважче помітити: сайт зазвичай не падає, а тупить.
Стаття довга. Пропонуємо зробити паузу та ознайомитися з найкращими українськими хостинг-провайдерами з нашого рейтингу. На кожного з них є детальний аналіз: як проводилося тестування, як справи з аптаймом, швидкістю та підтримкою, які сильні та слабкі сторони. Загляньте в огляди тих, хто вас цікавить, прочитайте відгуки клієнтів.
IOPS проти I/O: два боки одного дискового навантаження
Різниця між кількістю операцій і пропускною здатністю – той момент, на якому зазвичай «клацає». Найпростіше показати на сценаріях.
| Що відбувається | Даних | Операцій | У що впрітеся |
|---|---|---|---|
| Читаєте великий файл послідовним потоком | багато | мало | I/O (пропускна здатність) |
| Безліч дрібних читань по кілька КБ | мало | дуже багато | IOPS |
| WordPress збирає сторінку: десятки дрібних звернень до файлів і бази | небагато | багато | частіше IOPS |
| Бекап великого сайту | багато | багато | і I/O, і IOPS |
| База ганяє дрібні запити до диска пачками | мало | багато | частіше IOPS |
Тільки не подумайте, що IOPS і мегабайти живуть незалежно одне від одного. Вони повʼязані, і грубо це виглядає так: пропускна здатність ≈ кількість операцій × розмір однієї операції. Просто різні навантаження тиснуть на різні боки цієї рівності. Великі послідовні читання набивають мегабайти, лишаючись скромними за кількістю операцій; рій дрібних – навпаки, забиває IOPS, майже не чіпаючи трафік. Звідси важливе для діагностики: «та в мене ж I/O в нормі» ще не доводить, що з диском лад, – ви могли впертися в інший бік того самого навантаження.
Навіщо провайдер узагалі обмежує IOPS
Тепер з боку хостера, бо звідси зрозуміло, чому ліміт саме такий. Уявіть спільний SSD або NVMe-масив, яким одночасно користуються десятки, а то й сотні акаунтів. Один сайт може засипати цей диск величезною кількістю дрібних звернень, фізично читаючи й записуючи зовсім небагато. За обсягом – копійки, за кількістю операцій – шквал, і таке навантаження лягає на спільну дискову підсистему, зачіпаючи інших користувачів.
Обмеження за обсягом таке навантаження не спіймає: сайт же майже нічого не «важить». А ліміт на кількість операцій ловить саме характер навантаження: не скільки даних ганяє акаунт, а наскільки смикано він це робить. Для провайдера це не штучна удавка, а спосіб тримати спільний диск у рамках, щоб один галасливий сусід не садив продуктивність усієї полиці. Саму механіку ізоляції акаунтів на віртуальному хостингу ми розбирали в статті про CloudLinux – ліміти ростуть саме звідти.
Про NVMe варто сказати окремо, бо на нього часто марно сподіваються. NVMe справді здатен на помітно вищу дискову продуктивність, особливо за кількістю операцій. Але якщо тариф усе одно ріже акаунт умовною цифрою IOPS, наявність NVMe не означає, що конкретно вам дістанеться вся його продуктивність. Стеля піднята на рівні заліза, а ваша особиста стеля задана лімітом акаунта, і вона цілком може лишитися колишньою. Розчаровує це, мабуть, найдужче: купили «найшвидший NVMe», а впираєтеся в ту саму стінку, що й на звичайному диску.
Що на практиці набиває IOPS
Корисніше не список причин, а механізм – звідки взагалі беруться ці операції.
Почну з кешу – це одне з найчастіших джерел зайвих операцій на WordPress. Кеш вимкнений або ввімкнений, але не працює (так буває частіше, ніж хотілося б). За відсутності ефективного page cache кожен запит знову проходить через PHP і створює додаткову роботу для застосунку й бази. Частина даних при цьому віддається з памʼяті – кешу операційної системи, буферного пулу бази, – і не кожен запит доходить до фізичного диска; але при інтенсивному динамічному навантаженні кількість дискових операцій усе одно помітно зростає. Помножте на трафік, і високий IOPS набігає буквально на порожньому місці. Високий IOPS, до слова, може бути й однією з причин вирослого часу відповіді сервера – хоча причин у повільного TTFB вистачає й крім диска.
Далі – база, яка працює неефективно. Запит без індексу змушує її перелопачувати таблицю цілком; велике сортування чи групування, якому забракло памʼяті, вихлюпується в тимчасові файли на диск. Зовні це виглядає як «сайт тупить», а всередині – сотні дрібних дискових операцій на один важкий запит. Після встановлення Query Monitor багато хто зі здивуванням виявляє, що найдужче диск смикає не вітрина магазину, а якийсь давно забутий плагін, що на кожній сторінці лізе в базу за своїми налаштуваннями.
Файлові сесії – тихе, але стабільне джерело. Якщо PHP зберігає сесії файлами, запити, що працюють із сесією, читають відповідний файл, а при зміні даних сесії – ще й переписують його. Поодинці дрібниця, але на живому магазині із сотнями одночасних кошиків це може складатися в помітний потік дрібних операцій, який нічим себе не виказує у звичних метриках.
Логи туди ж. Багатослівне логування, спам помилок у error_log, плагіни, що пишуть власну аналітику у файли: кожен рядок це запис на диск. Зазвичай небагато, але зламаний плагін, що завалює лог десятком записів на кожен запит, здатен поодинці тримати IOPS високим.
І окремо – бекапи, бо це гарний контрапункт до всього сказаного. Бекап примудряється набивати одразу обидві метрики: він і жене великий обсяг даних (це I/O), і, якщо інструмент обходить тисячі окремих файлів – а на типовому WordPress у теці uploads їх саме тисячі, – плодить купу дрібних операцій (це IOPS). Тут же зринає старий знайомий, кількість inode: що більше у вас дрібних файлів, то більше дискових операцій може знадобитися для кожного повного бекапу.
Як знизити IOPS і чому в кожного способу є межа
Способів кілька, і в кожного своє слабке місце. Звести в таблицю чесніше, ніж розписувати один «правильний».
| Що робимо | Що зменшує | Де межа |
|---|---|---|
| Кеш сторінок (page cache) | повторні прогони PHP і запити до бази | не допомагає некешованим сторінкам: кошик, особистий кабінет, адмінка, POST-запити |
| Обʼєктний кеш (Redis, Memcached) | повторні запити до бази та повʼязану з ними роботу | сам не лагодить поганий SQL: якщо запит не покритий кешем або дані постійно змінюються, він усе одно виконується й створює вихідне навантаження |
| Оптимізація бази (індекси, правка запитів) | зайві читання й сортування на диску | спершу треба знайти конкретний проблемний запит, а це вже робота руками |
| Перенесення сесій із файлів у in-memory backend (наприклад, Redis) | може зменшити файлові операції | перенесення в саму базу навантаження не знімає – база теж працює з диском; потрібна підтримка з боку застосунку |
| Тариф вищий | піднімає сам ліміт | не усуває неефективне навантаження, ви просто впертеся в стіну трохи згодом |
| Перехід на VPS | більше контролю над ресурсами; стеля дискового навантаження може бути вищою | вимагає адміністрування; у самого VPS теж бувають свої ліміти IOPS з боку провайдера |
Один нюанс про сам сервер. На LiteSpeed звʼязка з LSCache може віддавати закешовану сторінку прямо на рівні вебсервера, не запускаючи заради неї PHP. Це здатне помітно знизити навантаження на застосунок і повʼязані з ним звернення до бази й файлової системи. Але результат залежить від конфігурації й типу запитів: на некешованих сторінках (тому самому кошику) не рятує жоден серверний кеш. Універсального правила «LiteSpeed – означає менше IOPS» тут немає.
Що ховається за «безлімітним SSD»
«Безлімітний SSD» на тарифній сторінці зазвичай стосується передусім обсягу дискового простору, а не продуктивності дискової підсистеми. І «безлімітний» тут рідко означає буквально «скільки завгодно»: майже завжди поряд живуть Fair Use, ліміт inode, обмеження на типи файлів. А про те, яке дискове навантаження витримає акаунт, цей пункт тарифу не каже нічого. Можна мати 50, 100, 500 гігабайтів вільного місця й усе одно впиратися в ліміт IOPS щовечора в годину пік.
Чому цифри IOPS майже ніколи немає на тарифній сторінці – питання радше нудне, ніж таємниче. Одна з можливих причин проста: сторінка з цінами зазвичай не несе всієї технічної специфікації, а «3000 операцій за секунду» більшості покупців нічого не скаже. Прискіпуватися тут особливо нема до чого. Просто тримайте в голові, що «безлімітний» описує полицю, а не швидкість, з якою ви з цієї полиці берете.
Коли ліміт IOPS означає, що ви переросли віртуальний хостинг
Буває, що кеш налаштований, запити вичищені, сесії винесені з файлів, а IOPS усе одно регулярно бʼється в стелю. Це вже не про «щось зламалося», а про те, що характер навантаження вашого сайту перестав уміщатися в модель віртуального хостингу.
Нічого ганебного в цьому немає. Віртуальний хостинг спроєктований під певний профіль навантаження, і живий магазин із сотнями одночасних користувачів, важкою динамікою та постійною роботою з базою в цей профіль просто не вкладається. Тоді має сенс дивитися в бік VPS, де зазвичай більше контролю над ресурсами, а стеля дискового навантаження може бути вищою, або виділеного сервера, де фізичні накопичувачі справді у вашому розпорядженні, – щоправда, за цей контроль доведеться платити адмініструванням. Різницю між типами розміщення по суті, а не по вітрині, ми розбирали окремо; а зрозуміти, який тип хостингу підходить під ваше навантаження, простіше, коли ви вже чесно виміряли, у що впираєтеся. Іноді досить підняти тариф. Іноді – уже ні.
Джерела
- CloudLinux Documentation – LVE limits: IO та IOPS (що таке ліміт на кількість дискових операцій на рівні контейнера акаунта і чим він відрізняється від ліміту пропускної здатності);
- CloudLinux Documentation – Resource Usage (клієнтський плагін у cPanel) (які метрики показує розділ «Використання ресурсів» і як читати faults);
- LiteSpeed Documentation – LSCache (як серверний кеш віддає готову сторінку до запуску PHP).
FAQ по ліміту IOPS
Що таке IOPS на хостингу простими словами?
IOPS – це кількість окремих операцій читання й запису, які диск встигає обслужити за секунду. Це не про те, скільки даних вміститься (обсяг), і не про те, скільки мегабайтів проходить за секунду (пропускна здатність), а про кількість самих звернень до диска. Тисяча крихітних запитів створює високий IOPS, навіть якщо за обсягом це майже нічого. На віртуальному хостингу IOPS – один із лімітів акаунта нарівні з CPU, памʼяттю та кількістю процесів.
Чим IOPS відрізняється від I/O та пропускної здатності диска?
I/O (пропускна здатність) міряє обсяг даних за секунду, зазвичай у KB/s або MB/s. IOPS міряє кількість операцій за секунду, незалежно від їхнього розміру. У панелі це сусідні рядки, але впиратися в них можна нарізно: велике послідовне читання набиває I/O при скромному IOPS, а рій дрібних запитів – навпаки. Повʼязані вони приблизно так: пропускна здатність ≈ кількість операцій × розмір однієї операції.
Чому сайт гальмує, якщо місця на диску багато, а памʼять і процесор у нормі?
Вільне місце, памʼять і процесор – це різні ресурси, і впертися можна в той, на який ви не дивитеся. Частий винуватець – саме IOPS: сайт робить забагато дрібних звернень до диска, хоча ні обсяг, ні трафік при цьому не зашкалюють. При досягненні ліміту операції притримуються до кінця секунди, і сайт стає вʼязким, не видаючи явної помилки. Перевірте рядок IOPS у розділі «Використання ресурсів».
Де подивитися IOPS у cPanel?
У cPanel відкрийте розділ «Використання ресурсів» (Metrics → Resource Usage). Він показує історію навантаження, а не лише стан у поточну секунду: період і деталізацію (день, година, хвилина) можна вибрати. Рядок IOPS стоїть поряд із CPU, Physical Memory, Entry Processes та I/O Usage. Для точної діагностики вибирайте інтервал, у якому сайт гальмував, а не лише поточне значення.
Якщо faults = 0, значить з IOPS усе гаразд?
Не обовʼязково. Faults – це лічильник, скільки разів акаунт пробив ліміт за період, а не індикатор здоровʼя диска. Панель показує історію за вибраний період, тому пік міг статися раніше й уже відпустити, а ви дивитеся в спокійний момент. Нуль у faults означає «у вибраний період ліміт не пробивали», а не «з диском усе гаразд».
Що найчастіше створює високий IOPS на WordPress?
Часта причина – вимкнений або зламаний кеш: без нього кожен запит знову проходить через PHP і звертається до бази й файлової системи. Частина даних віддається з памʼяті, але при інтенсивній динаміці дискових операцій усе одно багато. Далі – неефективні запити до бази без індексів і сортування, які вихлюпуються в тимчасові файли. Свій внесок дають файлові сесії, багатослівні логи та бекапи, що обходять тисячі дрібних файлів.
Чи допомагає кеш знизити IOPS?
Так, кеш сторінок – найдієвіший перший крок: він віддає готову сторінку, не піднімаючи PHP і не смикаючи базу на кожен захід. Але в нього є межа – він не працює на некешованих сторінках: кошик, особистий кабінет, адмінка, POST-запити. Обʼєктний кеш (Redis, Memcached) знімає частину звернень до бази, але не лагодить поганий SQL-запит. Тож кеш розвʼязує більшу частину проблеми, але не всю.
Чи знімає NVMe ліміт IOPS?
Ні. NVMe здатен обслуговувати помітно більше операцій і відповідати швидше, але це піднімає стелю на рівні заліза, а не вашу особисту. Якщо тариф ріже акаунт конкретною цифрою IOPS, наявність NVMe не означає, що вам дістанеться вся його продуктивність. Ваша стеля задана лімітом акаунта, і вона може лишитися колишньою навіть на найшвидшому диску.
Чи дає «безлімітний SSD» необмежений IOPS?
Ні, «безлімітний SSD» – це про місткість, а не про швидкість роботи з диском. Зазвичай це означає, що провайдер не ставить звичний жорсткий ліміт на обсяг у межах моделі тарифу, – а не що даних буквально скільки завгодно: поряд майже завжди живуть Fair Use та ліміт inode. Про дискове навантаження й ліміти I/O та IOPS «безлімітний» не каже нічого, і впиратися в IOPS можна при сотнях вільних гігабайтів. Цифру IOPS на тарифній сторінці зазвичай не пишуть просто тому, що вона мало що каже звичайному покупцеві.
Як відрізнити проблему з IOPS від ліміту процесора?
Зовні обидва виглядають як «сайт повільний», розрізняє їх характер гальмувань. Упор у CPU зазвичай рівний: важчає все підряд. Упор в IOPS частіше рваний: легкі сторінки літають, а все, що лізе в базу чи файли, зависає на рівному місці. Надійніше не гадати за симптомом, а звести час скарги з графіками навантаження за той самий період.
Чи видає ліміт IOPS помилку на сайті?
Зазвичай ні. При досягненні ліміту IOPS операції не відвалюються, а притримуються до кінця поточної секунди й виконуються трохи згодом. Перевищення IOPS проявляється передусім як уповільнення, а не як окрема помилка на кшталт 508 при вичерпанні Entry Processes. Через це його найважче спіймати: сайт зазвичай не падає, а тупить.
Коли ліміт IOPS означає, що час переходити на VPS?
Коли кеш налаштований, запити вичищені, сесії винесені з файлів, а IOPS усе одно регулярно бʼється в стелю. Це вже не поломка, а сигнал, що характер навантаження сайту перестав уміщатися в модель віртуального хостингу. Живий магазин із сотнями одночасних користувачів і важкою динамікою в цей профіль часто не вкладається. На VPS зазвичай більше контрольованих ресурсів і вища стеля дискового навантаження, а на виділеному сервері накопичувачі у вашому розпорядженні, – але за контроль доведеться платити адмініструванням.