Сайт став помітно повільнішим, підтримка киває на «навантаження по диску», а в статистиці акаунта зʼявилася строка IO з цифрами, що вперлися у стелю. Місця на диску при цьому вдосталь, память не забита. Так виглядає упор у пропускну здатність диска: ліміт, який майже ніколи не виносять у тариф великим шрифтом, хоча натрапляють на нього постійно.
Якщо зовсім коротко, ось суть. IO-ліміт обмежує не обсяг диска, а швидкість: скільки кілобайтів на секунду ваш акаунт може прочитати й записати. На типовому віртуальному хостингу це близько 1024 KB/s, тобто приблизно 1 МБ/с. Коли ви в нього впираєтеся, сервер не роняє сайт, а пригальмовує процеси: вони «засинають» і чекають, доки звільниться смуга. Тому симптом зазвичай не «впало», а «гальмує». Перше, що варто зробити, знайти, що саме вантажить диск просто зараз. Найчастіше це бекап, розпакування великого архіву, генерація превʼю для медіатеки або розрослі логи. Якщо причиною був разовий процес, на кшталт бекапа чи розпакування архіву, після його завершення навантаження зазвичай повертається до звичайного рівня. Якщо ж у смугу постійно впирається сам застосунок, зупинка однієї операції нічого не вирішить, і тоді доведеться розбиратися глибше.
Далі розберемо, чому провайдер узагалі ставить цей ліміт, чим пропускна здатність відрізняється від кількості операцій, і як зрозуміти, що гальма саме про диск, а не про процесор чи память.
Чому швидкість диска взагалі обмежують
Фізично диск на сервері швидкий. Навіть недорогий SSD спокійно видає сотні мегабайтів на секунду, а на форумах CloudLinux трапляються тести, де звичайний запис на серверний накопичувач іде під гігабайт на секунду. Питання в тому, що цей диск один, а акаунтів на сервері віртуального хостингу сотні. Якщо дозволити кожному читати й писати на повній швидкості, вистачить одного сусіда, який затіяв імпорт каталогу на десятки тисяч товарів, щоб у решти сайти стали.
Саме для цього й існує ізоляція: багато провайдерів shared-хостингу використовують CloudLinux, а він ріже кожен акаунт по CPU, памʼяті, кількості процесів і ось цій самій смузі диска. Ліміт IO вимірюється в кілобайтах на секунду й враховує дисковий ввід-вивід, тобто і читання, і запис; звернення до disk cache в цей ліміт не включаються. Рекомендовані самим CloudLinux значення такі: типовий акаунт – 1024 KB/s (близько 1 МБ/с), акаунт дорожчий – 4096 KB/s (близько 4 МБ/с). Цікаво, що ці цифри, за документацією вендора, не залежать від потужності сервера: вони залежать лише від того, наскільки «швидким» провайдер хоче зробити акаунт. Тобто на двох фізично однакових серверах у різних хостерів смуга вам може дістатися різна просто з міркувань щільності розміщення.
З боку провайдера це виглядає буденно. У панелі видно, у кого накопичуються «faults» по диску, і зазвичай це два-три акаунти зі ста, які тягнуть ковдру на себе. Ліміт потрібен не щоб вас покарати, а щоб сусідський бекап не перетворив ваш сайт на слайд-шоу.
Пропускна здатність і IOPS – це два різні ліміти
Тут плутаються найчастіше. «Диск не тягне» насправді розпадається на дві незалежні речі, і лікуються вони по-різному.
Пропускна здатність (це і є IO bandwidth) відповідає на питання «скільки даних на секунду». Ганяєте великий файл – упираєтеся в неї. А IOPS відповідає на інше питання: «скільки окремих звернень до диска на секунду». Тисяча запитів до бази, кожен з яких смикає по крихітному шматку даних, смугу майже не витрачає, зате легко вибирає ліміт операцій. Одне й те саме слово «диск» ховає дві різні стінки, і збільшення однієї з них ніяк не допоможе, якщо ви вперлися в іншу.
| Ситуація | Що обмежує |
|---|---|
| Великий файл читається або записується послідовно | IO bandwidth |
| Багато дрібних операцій з файлами | IOPS |
| Резервне копіювання великого обсягу даних | IO bandwidth, а за безлічі дрібних файлів – ще й IOPS |
| Тисячі дрібних операцій файлової системи | IOPS |
| Читання даних із disk cache | Не враховується в IO limit |
Останній рядок заслуговує на окреме застереження, бо його легко прочитати неправильно. «Не враховується в IO limit» не означає «не створює навантаження взагалі». Це означає рівно одне: конкретне звернення, яке обслужене з дискового кешу, не списується з вашої квоти пропускної здатності. Навантаження на систему в нього все одно є, просто іншого роду, і живе воно в оперативній памʼяті, а не в лічильнику диска.
Що потрапляє в лічильник, а що проходить повз
Про кеш варто сказати трохи докладніше, бо це той нюанс, що змінює всю картину. Коли файл уперше читається з диска, система відкладає його копію в оперативну память. Друге, третє, тисячне звернення до того самого файлу береться вже звідти, а не з накопичувача. За документацією CloudLinux такі читання з кешу в ліміт IO не потрапляють: файл, який сервер віддав із памʼяті хоч тисячу разів, не витратить жодного байта вашої дискової смуги.
Практичний сенс простий. Повторне читання файлу, який уже лежить у page cache, лічильник IO не збільшує, тому в сайту, який раз по раз віддає одні й ті самі картинки й ту саму головну, багато звернень може майже не витрачати саме цей ліміт. А ось коли кожен запит лізе за свіжими, ще не прогрітими даними, смуга починає танути. Звідси, до речі, росте несподіваний ефект: сайт може роками працювати без жодного упору в IO, а потім «раптово» загальмувати після чищення кешу, переїзду чи нічного моменту, коли кеш іще холодний, а трафік уже пішов. Диск не став повільнішим, просто зникла прошарок, який раніше приймав удар на себе.
Стаття довга. Пропонуємо зробити паузу та ознайомитися з найкращими українськими хостинг-провайдерами з нашого рейтингу. На кожного з них є детальний аналіз: як проводилося тестування, як справи з аптаймом, швидкістю та підтримкою, які сильні та слабкі сторони. Загляньте в огляди тих, хто вас цікавить, прочитайте відгуки клієнтів.
Лічильник бачить переважно PHP, cron і SSH
Ще одна річ, яка перевертає інтуїцію. Ліміт IO рахується не для всього підряд, що відбувається на диску, а лише для процесів, що потрапили в ізоляцію CloudLinux. А туди потрапляє запит, який обробляє PHP чи CGI-скрипт, плюс те, що ви запускаєте по SSH і за розкладом через cron. За стандартної конфігурації статичний контент – картинки, стилі, скрипти, які вебсервер віддає сам, не смикаючи PHP, – в ізоляцію зазвичай не потрапляє, тому його роздача в цей ліміт не враховується. За документацією CloudLinux обмеження за замовчуванням стосується PHP і CGI, оброблених Apache, і процесів із SSH. Але це саме поведінка за замовчуванням: конфігурацію можна змінити так, щоб певні види статики теж оброблялися всередині ізоляції.
Із цього випливає несподіваний поворот в історії про медіатеку. Важкі оригінали, вставлені звичайним тегом картинки й покладені статичними файлами, зазвичай на вашу дискову смугу не тиснуть: їх віддає вебсервер напряму. А ось якщо ті самі файли проходять через PHP – скрипт захищеного завантаження, віддача за токеном, генерація превʼю на льоту, плагін, який «стрімить» файл замість прямого посилання, – тоді дискові читання цього процесу вже потрапляють під IO limit. З одним застереженням: те, що обслужене з disk cache, і далі не рахується, тож повторна віддача того самого файлу з памʼяті ліміт не витрачає. Тому один і той самий гігабайт картинок може або майже не потрапляти в лічильник, або вибивати ліміт на холодних читаннях: усе залежить і від того, хто їх віддає, і від того, чи лежать вони вже в кеші. З боку провайдера це видно як різниця між сайтом, у якого диск вантажить трафік, і сайтом, у якого його вантажить архітектура.
Що реально зʼїдає смугу
Якщо звести практику до кількох упізнаваних сценаріїв, у пропускну здатність зазвичай упираються одні й ті самі речі.
Резервне копіювання. Повний бекап акаунта потребує прочитати великий обсяг даних і записати результат, тому на обʼємному сайті він спокійно вибирає смугу на весь час роботи. А якщо файлів багато й вони дрібні, до навантаження на смугу додається ще й купа окремих операцій, тобто та сама історія про IOPS. Особливо якщо бекап запускається засобами самого хостингу в денний пік, коли смуга й без того потрібна відвідувачам.
Розпакування й упакування архівів прямо на хостингу. Завантажили zip з темою, картинками чи дампом і розпакували через файловий менеджер – на кілька хвилин диск зайнятий лише цим. Те саме з імпортом великого каталогу в магазин: сотні мегабайтів зображень, які рушій ще й перезбирає в превʼю різних розмірів.
Розрослі логи й сміття, що пишеться постійно. Плагін, який у режимі відлагодження строчить у файл на кожен запит, до пари гігабайтів лога особливо не привертає уваги, але часта запис у лог створює постійне навантаження на файлову підсистему цілодобово. Фізично на накопичувач це може лягти й пізніше, через кешування операційної системи, але потік вводу-виводу нікуди не дівається.
Медіатека, що ходить через PHP. З урахуванням попереднього розділу уточнимо: смугу вибивають не картинки самі по собі, а ті, що віддаються скриптом – за токеном, з перевіркою прав, з ресайзом на льоту. Важкі оригінали, які сервер роздає напряму, найчастіше повз лічильник. А ось за постійної захищеної віддачі великих файлів такий акаунт створює стійке дискове навантаження, і це, як правило, не «атака» й не збій, а просто устрій сайту.
Як відрізнити дисковий затик від процесора й памʼяті
Симптом «сайт гальмує» однаковий для півдесятка різних лімітів, і тут легко лікувати не те. Розкласти допомагає статистика ресурсів у панелі: у CloudLinux вона показує роздільно, за яким саме лімітом накопичилися «faults». Якщо росте строка IO – річ у смузі. Якщо CPU – сайт упирається в процесорний ліміт, і жодна робота з диском тут не допоможе. Якщо PMEM – не вистачає оперативної памʼяті. Якщо лічильник за одночасними вхідними запитами (EP) – сайт захлинається від паралельних підключень, а не від швидкості диска.
Важливо, що різні ліміти й проявляються по-різному, і плутати їхні коди не варто. Сам по собі IO limit (як і CPU) зазвичай дає саме сповільнення: процеси пригальмовуються, а не завершуються з помилкою. А ось при вичерпанні EP, ліміту одночасних запитів, CloudLinux може повернути 508 Resource Limit Reached; брак памʼяті чи кількості процесів частіше виливається в 500 або 503. Тобто за кодом відповіді можна прикинути, де шукати, але остаточну відповідь дає все одно розбивка faults у статистиці, а не сам код. Повний розбір кодів, які може віддати сервер у таких ситуаціях, є в матеріалі про HTTP-статуси. Загальну ж логіку всіх цих лічильників – чому їх декілька і як вони повʼязані – ми зібрали в огляді лімітів і ресурсів акаунта.
Де це взагалі побачити
На більшості панелей із CloudLinux потрібна сторінка називається «Resource Usage» або «Використання ресурсів» і живе в cPanel поруч із метриками акаунта. Дивитися треба не на поточну цифру, а на стовпець із «faults» – це лічильник того, скільки разів за період ви впиралися в кожен ліміт окремо. Нуль по IO при ненульових faults по CPU означає, що диск ні до чого, як би не хотілося все звалити на нього. У провайдера теж є статистика LVE, і він може побачити, за яким лімітом акаунт регулярно ловить faults, хоча його панель виглядає інакше, ніж ваша. Тому в тикет має сенс одразу докласти, за яким саме лімітом у вас накопичуються faults: це заощаджує одне-два кола листування.
Що до снаги вебмайстру
Хороша новина в тому, що майже все, що впирається в смугу, лікується не грошима, а порядком. Найдієвіше – кешування, і не тільки сторінкове. Коли рушій віддає готові сторінки з кешу, а повторні читання файлів обслуговуються з памʼяті, диск перестає бути вузьким місцем для значної частини повторюваних запитів. Динаміка, промахи кешу, адмінка, cron і бекапи при цьому нікуди не діваються, але основний потік однотипних звернень із диска йде. Саме тому упор в IO так часто відходить після простого ввімкнення нормального кешу: смуга-то нікуди не поділася, просто до неї перестали доходити.
Бекапи варто відводити на ніч і, за можливості, назовні. Резервна копія, яка збирається на самому хостингу в денний пік, конкурує за смугу з живими відвідувачами; та сама копія вночі проходить непомітно. І, до речі, бекап на тому самому акаунті – це ще й не зовсім резервна копія, але це окрема розмова.
Далі йдуть речі простіші. Не тримайте архіви й старі дампи в робочому каталозі сайту: вони не тільки їдять місце й іноди, але й потрапляють під будь-які операції обходу файлів. Вимикайте відлагоджувальне логування, коли воно не потрібне, інакше диск пише марно цілодобово. Важку медіатеку, яка не влазить у кеш, має сенс віддавати через зовнішнє сховище чи CDN: це знижує кількість звернень до вашого диска, а за повного перенесення файлів у зовнішнє сховище оригінали й зовсім перестають із нього читатися. Щоправда, з одним лише CDN промах кешу все одно призводить до запиту на ваш origin, а той уже читає файл із диска, тож срібної кулі тут немає. Зауважу з практики: після того як люди ставлять собі монітор запитів і починають дивитися, що коїться з диском, найчастіше виявляється, що смугу вибирає не магазин і не трафік, а один забутий плагін, який щось пише у файл на кожен чих.
Коли збільшувати IO-ліміт, а коли проблема взагалі не в ньому
Спокуса проста: уперся в ліміт – попроси підняти. Іноді це правильний хід, але далеко не завжди, і перш ніж платити за більший тариф, варто переконатися, що ви взагалі впираєтеся в ту стінку. Розкласти допомагає все та сама статистика ресурсів.
- Якщо регулярно досягається саме
IOlimit, а не сусідні лічильники – збільшення смуги справді може допомогти, це той випадок, коли апгрейд по ділу. - Якщо впираєтеся в
IOPS– зростання однієї лише пропускної здатності майже нічого не дасть: це інший ліміт, про кількість операцій, і лікується він інакше. - Якщо росте
CPU– додавати IO безглуздо, диск тут ні до чого, сайт рахує, а не читає. - Якщо проблема в
EP, кількості одночасних запитів, – це взагалі про паралельні підключення, окрема історія зі своїми причинами. - Якщо ж workload постійно дискоємний за своєю природою – великий каталог, важка медіатека, активний запис, – то упор у смугу перестає бути випадковістю, і тоді логічніше не докуповувати IO на shared, а перейти туди, де ресурси диска виділені під вас: на VPS чи виділений сервер. Різницю між загальною й гарантованою смугою ми розбираємо окремо – гарантований ресурс проти burstable і мʼякі ліміти проти жорстких. Про сам вибір типу розміщення зручно відштовхнутися від вітрини видів хостингу.
Сенс цієї розвилки в тому, щоб не перетворювати будь-який червоний лічильник на привід для апгрейда. Більший тариф вирішує проблему лише там, де обмежувальний ресурс справді вичерпаний і його збільшення відповідає характеру навантаження. У решті випадків допомагає не оплата, а знайдена справжня причина, і вона нерідко виявляється дешевшою й ближчою, ніж здається на перший погляд.
Джерела
- CloudLinux OS – LVE Limits (офіційна документація);
- CloudLinux – LVE limits: значення за замовчуванням і рекомендовані.
FAQ по ліміту IO
Що таке ліміт IO на хостингу?
IO – це обмеження швидкості диска, а не його обсягу: скільки мегабайтів на секунду ваш акаунт може читати й записувати. На віртуальному хостингу його ставить CloudLinux, щоб один сайт не зайняв весь диск сервера. Вимірюється він у кілобайтах на секунду й рахує і читання, і запис.
Чим IO bandwidth відрізняється від IOPS?
IO bandwidth – це обсяг даних на секунду, а IOPS – кількість окремих звернень до диска на секунду. Великий файл, який читається цілком, упирається в bandwidth. Тисяча дрібних запитів до бази майже не витрачає смугу, зате вибирає ліміт операцій IOPS. Це дві різні стінки, і збільшення однієї не допомагає, якщо ви вперлися в іншу.
Чому сайт гальмує, якщо місця на диску багато?
Місце й швидкість – різні речі. Диск може бути заповнений на десять відсотків, але якщо ви вперлися в ліміт швидкості читання й запису, процеси починають чекати звільнення смуги. Звідси й «гальмує», хоча за вільним місцем усе гаразд.
Скільки мегабайтів на секунду зазвичай дає shared-хостинг?
За рекомендаціями CloudLinux типовому акаунту дають близько 1 МБ/с (1024 KB/s), тарифу дорожчому – порядку 4 МБ/с. Ці цифри не залежать від потужності сервера, а відображають, наскільки «швидким» провайдер вирішив зробити акаунт. Тому на схожих серверах у різних хостерів смуга може помітно відрізнятися.
Сайт падає через IO limit чи просто сповільнюється?
При упорі в IO сервер не вбиває процеси, а пригальмовує їх: вони «засинають» і чекають звільнення смуги. Тому типовий симптом – повільне завантаження, а не падіння з помилкою. Повноцінну 508 зазвичай дає інший ліміт, за кількістю одночасних запитів (EP), а брак памʼяті частіше виливається в 500 або 503.
Що найсильніше витрачає пропускну здатність диска?
Найчастіше це резервне копіювання великого сайту, розпакування архівів прямо на хостингу, імпорт великого каталогу й розрослі логи. Окремо стоїть медіатека, яка віддається через PHP. Усі ці операції читають або пишуть багато й довго, тому й вибивають смугу.
Чи враховується читання з disk cache в ліміті IO?
Ні. Звернення, обслужене з дискового кешу, не списується з квоти IO: файл, відданий із памʼяті хоч тисячу разів, не витратить жодного байта смуги. Але це не означає, що кеш взагалі не вантажить систему – навантаження просто переїжджає в оперативну память.
Чи рахується роздача статики в ліміт IO?
Як правило, ні. Ліміт IO стосується процесів усередині ізоляції CloudLinux: це PHP, CGI, а також те, що запущене по SSH і через cron. Картинки й файли, які вебсервер віддає напряму, за стандартної конфігурації зазвичай проходять повз лічильник. А ось ті самі файли, віддані через PHP-скрипт, уже можуть витрачати смугу – окрім випадків, коли відповідь обслужена з disk cache.
Як зрозуміти, що проблема саме в IO, а не в CPU чи памʼяті?
Дивіться статистику ресурсів у панелі: вона показує faults окремо за кожним лімітом. Якщо росте строка IO – річ у диску; якщо CPU чи PMEM – причина інша, і робота з диском тут не допоможе. Той самий симптом «гальмує» буває в півдесятка різних лімітів.
Чи допоможе збільшення IO-ліміту?
Тільки якщо ви впираєтеся саме в IO. Якщо faults накопичуються за IOPS, CPU чи EP, зростання однієї лише пропускної здатності майже нічого не дасть. Тому спершу варто переконатися за статистикою, в яку стінку ви бʼєтеся, а вже потім просити апгрейд.
Як знизити навантаження на диск без зміни тарифу?
Найбільше допомагає кешування: готові сторінки й повторні читання перестають доходити до диска. Бекапи варто переносити на ніч, відлагоджувальні логи – вимикати, важку медіатеку – віддавати через CDN. Часто справжньою причиною виявляється один плагін, який щось пише у файл на кожен запит.
Коли через диск час переходити з shared на VPS?
Коли сайт дискоємний за своєю природою – великий каталог, активний запис, важка обробка файлів – і упор у смугу стає постійним, а не разовим. У цьому випадку докуповувати IO на загальному хостингу менш логічно, ніж взяти виділені ресурси. Разові сплески так вирішувати не варто.