И снова о проблемах с лимитами. Разберем следующий случай: сайт стал заметно медленнее, поддержка кивает на «нагрузку по диску», а в статистике аккаунта появилась строка 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 на общем хостинге менее логично, чем взять выделенные ресурсы. Разовые всплески так решать не стоит.