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