IOPS: что это такое и как рассчитать количество

Компания купила сервер с производительными NVMe-накопителями или арендовала мощную виртуальную машину, а бухгалтерия всё равно жалуется на медленное проведение документов в 1С. Причина может быть в том, что дисковую подсистему выбирали по скорости в мегабайтах в секунду, не учитывая количество операций, задержку и реальный характер нагрузки.

Разберём, что показывает IOPS, почему этот параметр нельзя оценивать отдельно от других характеристик и как рассчитать требования к хранилищу для СУБД, 1С, VDI и файловых серверов.

Высокая линейная скорость диска не всегда означает, что база данных будет работать быстро. Транзакционные СУБД выполняют множество небольших случайных операций ввода-вывода. Размер таких запросов зависит от СУБД, типа файла, настроек и характера нагрузки. Например, страница данных SQL Server имеет размер 8 КиБ, хотя физический запрос может захватывать сразу несколько страниц.

Параметр IOPS - Input/Output Operations Per Second - показывает, сколько операций чтения или записи накопитель выполняет за секунду. В тестах одной операцией обычно считают один запрос к блоку заданного размера. В реальной системе запросы могут объединяться или, наоборот, разбиваться на несколько операций на уровне ОС, контроллера или системы хранения.

Допустим, накопитель выполняет 16 000 операций в секунду. При размере операции 256 КиБ теоретическая пропускная способность составит 4 000 МиБ/с. Если уменьшить размер операции до 4 КиБ, те же 16 000 IOPS дадут 62,5 МиБ/с.

Сам накопитель при этом не стал медленнее - изменился профиль нагрузки. Кроме того, у диска или облачного тома может быть отдельный лимит пропускной способности. По этой причине максимальное значение IOPS не всегда достижимо одновременно с максимальной скоростью в МБ/с.

Синтетический тест вроде CrystalDiskMark способен показать отличное последовательное чтение, тогда как задержка случайных операций в реальной нагрузке СУБД окажется заметно выше. Поэтому тестировать хранилище нужно на профиле, который максимально близок к рабочему.

Есть и другое ограничение - глубина очереди. Если приложение отправляет только один запрос за раз, а задержка операции составляет 200 микросекунд, теоретический потолок будет около 5 000 IOPS. Даже накопитель, способный показать 300 000 IOPS в многопоточном тесте, не раскроется: приложение просто не создаёт достаточного количества параллельных запросов.

При выборе хранилища для СУБД или ERP нужно смотреть сразу на несколько параметров:

• количество операций;
• размер блока;
• глубину очереди;
• долю чтения и записи;
• задержку;
• пропускную способность.

Производители указывают IOPS для конкретных условий: размера блока, глубины очереди, числа потоков и соотношения операций чтения и записи. Изменение любого из этих параметров может заметно повлиять на результат.

Размер блока

IOPS и пропускная способность связаны простой формулой:

Throughput = IOPS × размер операции.

Один и тот же накопитель будет выглядеть по-разному в тесте базы данных с небольшими блоками и в тесте видеомонтажа с крупными последовательными операциями. Поэтому сравнивать два диска только по количеству IOPS или только по МБ/с некорректно.

Глубина очереди

Глубина очереди, или Queue Depth, показывает, сколько запросов одновременно обрабатывается или ожидает выполнения.

Чем больше параллельных операций получает накопитель, тем эффективнее он может использовать внутренние очереди и каналы памяти. Особенно это заметно у NVMe. Но высокая глубина очереди нужна не каждой системе. Если приложение работает почти синхронно и редко отправляет больше одного-двух запросов одновременно, оно не достигнет значений, заявленных для QD32 или QD128.

Нельзя выбрать «правильную» глубину очереди отдельно от приложения. Её оценивают вместе с задержкой: большая очередь при стабильной Latency может быть нормальным режимом, а рост очереди одновременно с ростом задержки уже указывает на перегрузку.

Read IOPS

Read IOPS показывает количество операций чтения, которое накопитель способен обработать за секунду при заданных условиях.

Фактическая доля чтения зависит от приложения, настроек СУБД, объёма оперативной памяти и эффективности кэширования. При выполнении SELECT-запросов СУБД обращается к страницам данных и индексам, если нужных данных нет в памяти.

Чем больше горячих данных помещается в буферный кэш, тем меньше физических чтений приходится выполнять. Поэтому одинаковые базы на одинаковых дисках могут показывать разную нагрузку при разном объёме RAM.

Write IOPS

Запись нередко создаёт более тяжёлую нагрузку, чем чтение. Причина не только в работе самого накопителя. СУБД может синхронно фиксировать изменения в журнале, RAID-массив - выполнять дополнительные операции с чётностью, а контроллер - сбрасывать данные из кэша на физические носители.

При этом одна запись приложения не всегда равна одной физической операции. Запросы могут кэшироваться, объединяться или выполняться асинхронно.

Резервное копирование, перестроение индексов и другие фоновые задачи тоже влияют на запись. Если они конкурируют с основной нагрузкой за IOPS, пропускную способность, CPU или сеть, задержка пользовательских запросов вырастет.

Допустимую Latency задают требования приложения, класс хранилища и SLA. Для журналов транзакций часто требуется более низкая задержка, чем для файлов данных, но единого порога, подходящего для всех систем, нет.

Random и Sequential IOPS

При последовательном доступе данные читаются или записываются подряд крупными блоками. Такой профиль характерен для резервного копирования, потокового видео, экспорта и обработки больших файлов.

При случайном доступе приложение обращается к разным адресам накопителя. Так работают базы данных, ERP-системы и виртуальные машины с несколькими активными пользователями.

У HDD случайные операции сильно зависят от механики: головке нужно перемещаться между дорожками, а пластинам - поворачиваться до нужного сектора. Поэтому случайная производительность может быть в разы или на порядки ниже последовательной.

SSD не тратит время на механическое позиционирование, но и у него случайное чтение, случайная запись и последовательная скорость заметно различаются. Эти показатели нужно сравнивать отдельно.

Provisioned IOPS

Provisioned IOPS - заранее установленный уровень производительности облачного тома или системы хранения.

Условия его предоставления зависят от конкретного сервиса. Провайдер может ограничивать производительность на уровне диска, виртуальной машины, сети или физического пула хранения. В некоторых продуктах заявленный уровень поддерживается большую часть времени, например 99,9%, но это характеристика конкретного тарифа, а не общее правило для всех облаков.

Для бизнес-критичных систем предсказуемые 20 000 IOPS нередко полезнее кратковременного пика в 100 000 IOPS, после которого том возвращается к базовому лимиту.

В массивах с контролем чётности одна логическая запись может вызвать несколько физических операций.

Для небольшой частичной записи RAID 5 по алгоритму read-modify-write выполняет:

1. чтение старого блока данных;
2. чтение старого блока чётности;
3. запись нового блока данных;
4. запись новой чётности.

В упрощённой модели коэффициент Write Penalty для RAID 5 равен 4.

Для RAID 6 обычно используют коэффициент 6, поскольку массив хранит два блока чётности.

У RAID 10 запись дублируется на зеркало, поэтому классический коэффициент равен 2.

Эти значения подходят для предварительного расчёта небольшой случайной записи. На практике результат может отличаться из-за кэша контроллера, записи полной полосы, объединения запросов и внутренней логики СХД.

Показатели в таблице ориентировочные. Результат конкретного накопителя зависит от модели и параметров теста: размера блока, глубины очереди, числа потоков и профиля операций.

Для SSD также важно учитывать ресурс записи. Его указывают в TBW или DWPD.

Показатель DWPD - Drive Writes Per Day - показывает, сколько полных объёмов накопителя разрешено записывать ежедневно в течение гарантийного периода. Корпоративные SSD могут иметь 0,3, 1, 3 DWPD и более. Значение зависит от класса нагрузки и конкретной модели, поэтому одного обозначения Enterprise недостаточно.

Сначала нужно определить профиль нагрузки:

• сколько операций создаёт приложение;
• какая доля приходится на чтение и запись;
• какой размер запросов используется;
• какой RAID или класс облачного тома выбран;
• какие пиковые значения возникают в рабочее время.

Для предварительной оценки RAID можно использовать формулу:

Физические IOPS ≈ логические IOPS чтения + логические IOPS записи × RAID Write Penalty.

Формула упрощённая: она не учитывает кэш, запись полной полосы и внутренние оптимизации современной системы хранения.

Пример расчёта для SQL-базы

Допустим, база на RAID 10 обслуживает 500 транзакций в секунду. Каждая транзакция создаёт 10 операций чтения и 5 операций записи.

Нагрузка чтения:

500 × 10 = 5 000 IOPS.

Нагрузка записи с коэффициентом RAID 10:

500 × 5 × 2 = 5 000 физических IOPS.

Общий результат:

5 000 + 5 000 = 10 000 физических IOPS.

Если по результатам наблюдений системе нужен резерв 30% на пики:

10 000 × 1,3 = 13 000 IOPS.

Размер запаса нельзя выбирать автоматически. Он зависит от характера пиков, требований к росту и допустимой загрузки хранилища.

Пример расчёта для 1С

Для 1С важна не только численность пользователей, но и архитектура системы. Если сервер приложений и СУБД используют одни ресурсы, они конкурируют за CPU, RAM и дисковую подсистему.

Проведение документов, регламентные задания и закрытие периода часто создают пики. Их размер лучше снимать по мониторингу рабочей системы или воспроизводить в нагрузочном тесте.

Покажем расчёт для 50 активных пользователей на RAID 10. Предположим, мониторинг зафиксировал в среднем 45 операций чтения и 15 операций записи на одного пользователя.

Чтение:

50 × 45 = 2 250 IOPS.

Запись:

50 × 15 × 2 = 1 500 физических IOPS.

Итого:

2 250 + 1 500 = 3 750 физических IOPS.

Если во время закрытия периода нагрузка вырастает в четыре раза:

3 750 × 4 = 15 000 IOPS.

Для рабочей системы в расчёт нужно подставлять значения из мониторинга за период, включающий обычные дни, фоновые задания и закрытие месяца.

Пример расчёта для VDI

В VDI основную проблему часто создаёт не средняя нагрузка, а короткие массовые всплески:

• запуск виртуальных машин;
• одновременный вход пользователей;
• обновление ОС;
• антивирусное сканирование;
• запуск одинаковых заданий по расписанию.

Допустим, тест показал 150 IOPS на одну сессию во время одновременного входа.

Для 200 сессий:

200 × 150 = 30 000 IOPS.

Если пик длится пять минут:

30 000 × 300 секунд = 9 000 000 операций.

При запасе 25–30% целевое значение составит примерно 37 500–39 000 IOPS. Для проектирования его можно округлить до 40 000 IOPS.

Допустимую задержку определяют по времени запуска рабочего стола и отклику приложений. Само по себе значение 20 мс не является универсальным нормативом для всех VDI-систем.

Файловый сервер

Файловые серверы могут создавать принципиально разную нагрузку.

Если пользователи работают с архивами, видео, CAD-проектами и резервными копиями, операции чаще идут последовательно крупными блоками. Узким местом в таком случае может стать пропускная способность в МБ/с или сеть.

Если сервер хранит тысячи небольших документов, профили пользователей или файловые базы, возрастает количество случайных операций. Тогда важнее IOPS и задержка.

Рассчитать требуемую производительность только по числу сотрудников и размеру файлов нельзя. Для оценки снимите:

• количество операций в секунду;
• средний размер запроса;
• долю чтения и записи;
• пропускную способность;
• задержку;
• число одновременных обращений.

Резервное копирование, запущенное в рабочее время, добавляет последовательную нагрузку поверх пользовательских операций. Насколько сильно это повлияет на систему, зависит от скорости бэкапа и свободного ресурса хранилища.

Внутри виртуальной машины приложение работает не напрямую с физическим накопителем, а с виртуальным томом. Его производительность может ограничиваться сразу на нескольких уровнях:

• лимитом диска;
• суммарным лимитом ВМ;
• пропускной способностью сети;
• параметрами физического хранилища;
• правилами Burst.

Например, отдельные типы AWS EBS поддерживают до 256 000 IOPS и до 4 000 МиБ/с, но только при подходящей конфигурации инстанса и тома. Эти значения нельзя переносить на другие продукты и облачные платформы.

Правило 3 IOPS на 1 ГиБ относится к AWS EBS gp2. Том gp2 объёмом 1 ТиБ получает базовую производительность около 3 000 IOPS. У gp3 базовые 3 000 IOPS не зависят от объёма. Другие провайдеры используют собственные модели расчёта.

Burst IOPS позволяет на короткое время превысить базовую производительность. Когда накопленный кредит заканчивается, диск возвращается к постоянному лимиту.

Можно подключить к ВМ несколько томов по 10 000 IOPS, но упереться в общий предел виртуальной машины, например 20 000 IOPS. В этом случае увеличение количества дисков не даст ожидаемого результата.

В общей инфраструктуре возможен и эффект «шумного соседа», когда другая виртуальная машина создаёт высокую нагрузку на общий пул хранения. Снизить риск помогают тарифы с документированными лимитами, QoS и понятными условиями SLA.

Перед выбором облачного провайдера запросите:

• постоянный лимит IOPS;
• максимальную пропускную способность;
• правила работы Burst;
• ограничения на уровне ВМ;
• показатели задержки, если они входят в SLA;
• поведение тома при достижении лимита.

На проблему с хранилищем могут указывать:

• рост задержки чтения и записи;
• увеличение глубины очереди;
• высокий I/O Wait;
• замедление при запуске резервного копирования;
• достижение лимита тома или ВМ;
• ухудшение отклика в часы пик.

Эти симптомы не доказывают, что причина находится именно в диске. Похожие признаки возникают при нехватке CPU, памяти, проблемах с сетью, блокировках в СУБД и ошибках приложения.

У Disk Queue Length нет универсального допустимого значения. Для HDD небольшая постоянная очередь может быть проблемой, а для NVMe или распределённого хранилища десятки параллельных запросов иногда являются штатным режимом.

Смотрите очередь вместе с Latency. Если очередь растёт, но задержка остаётся стабильной, хранилище может справляться. Если увеличиваются оба показателя, нужно искать источник перегрузки.

Журналы транзакций особенно чувствительны к задержке. При обычном COMMIT СУБД ждёт фиксации соответствующих записей журнала. При этом несколько транзакций могут подтверждаться одной операцией group commit, поэтому рост Latency с 1 до 5 мс не означает автоматического падения общей производительности ровно в пять раз.

В Windows нужные метрики можно собирать через Performance Monitor:

• Disk Queue Length;
• Avg. Disk sec/Read;
• Avg. Disk sec/Write.

В Linux используют iostat -x.

В панели облачного провайдера дополнительно проверьте:

• фактические IOPS;
• пропускную способность;
• задержку;
• попадание в лимиты;
• остаток Burst-кредита.

Перед покупкой нового оборудования стоит проверить, можно ли уменьшить количество дисковых операций.

Увеличить объём оперативной памяти. Дополнительная RAM позволяет удерживать больше востребованных страниц в кэше и реже обращаться к диску. Эффект зависит от рабочего набора данных и текущего коэффициента попаданий в кэш.

Разнести данные, журналы и временные файлы. Это помогает, если они размещаются на физических носителях или томах с независимыми лимитами. Простое создание нескольких логических разделов внутри одного массива не гарантирует прироста.

Изменить конфигурацию RAID. Для базы с интенсивной записью переход с RAID 5 или RAID 6 на RAID 10 может снизить Write Penalty. За это придётся заплатить меньшей эффективностью использования дисковой ёмкости.

Оптимизировать индексы и запросы. Отсутствующий индекс может превратить точечный поиск в сканирование большого объёма таблицы. Правильный индекс способен заметно сократить число чтений, хотя конкретный эффект зависит от запроса и структуры данных.

Перенести фоновые задачи. Резервное копирование, перестроение индексов и тяжёлые отчёты лучше разводить по времени. Затянувшийся ночной бэкап может пересечься с началом рабочего дня и забрать часть IOPS у пользователей.

Сравнивайте показатели до и после каждого изменения. Если после оптимизации система всё равно стабильно достигает физического или тарифного лимита, потребуется более производительное хранилище.

Апгрейд накопителя не поможет, если узкое место находится в другом компоненте.

Нет подходящего индекса. Запрос сканирует большой объём таблицы и создаёт лишние чтения. В этом случае оптимизация индекса полезнее замены диска.

CPU загружен на 90–100%. Если система упирается в процессор, новый NVMe почти ничего не изменит.

Перегружена сеть. Для SAN, NAS и облачных дисков сетевой канал может ограничить производительность раньше накопителя.

Приложение создаёт лишние запросы. N+1, отсутствие пагинации, неоптимальные JOIN и фильтрация по неиндексированным полям увеличивают нагрузку независимо от класса диска.

Синтетический тест не соответствует рабочей нагрузке

Инженер тестирует накопитель крупным блоком и с высокой глубиной очереди, а приложение работает небольшими случайными запросами при QD1 или QD2.

В результате реальные показатели оказываются ниже. Тест не соврал - он измерял другой профиль нагрузки.

Скорость выбирают без учёта выносливости

Потребительский SSD может показать высокую пиковую производительность, но не выдержать постоянную интенсивную запись в течение расчётного срока.

При выборе диска для СУБД или 1С нужно учитывать TBW, DWPD, срок гарантии и фактический объём записи.

Хранилище рассчитывают только по объёму

Массив на 20 ТБ может полностью закрывать потребность в ёмкости и одновременно не справляться с тысячами мелких случайных операций.

Проектировать нужно сразу по двум параметрам: объёму данных и требуемой производительности.

Не учитывают долю записи

RAID 5 эффективнее использует дисковую ёмкость, но при интенсивной небольшой записи создаёт больше физических операций, чем RAID 10.

Если не разделить нагрузку на чтение и запись, расчёт получится заниженным.

Смешивают последовательную и случайную производительность

Высокая скорость последовательного чтения не гарантирует высоких Random IOPS. Сравнивать накопители нужно на том профиле, который создаёт приложение.

Ориентируются на среднее значение

Среднесуточные 3 000 IOPS могут скрывать короткие пики до 15 000 IOPS. Если система должна сохранять быстрый отклик в часы максимальной активности, хранилище рассчитывают по пиковым значениям с разумным запасом.

Игнорируют задержку

Высокое количество IOPS не компенсирует большую Latency. Пользователь может ощущать систему медленной даже при формально достаточном числе операций.

Запускают тест на рабочем сервере

Интенсивный тест способен повлиять на реальные бизнес-процессы, заполнить очередь и исчерпать Burst-кредит облачного диска. Проверку лучше проводить в отдельной среде или в согласованное окно обслуживания.

IOPS показывает, сколько операций чтения и записи хранилище выполняет за секунду. Но одного этого значения недостаточно.

Чтобы оценить реальную производительность, нужно учитывать размер блока, глубину очереди, задержку, долю чтения и записи, пропускную способность и ограничения конкретного хранилища.

Заявленные 300 000 IOPS не означают, что приложение получит такую производительность. Если рабочая нагрузка отличается от тестового профиля или упирается в лимит ВМ, сеть либо высокую Latency, фактический результат будет другим.

Что означает показатель 3000 IOPS?

Это означает, что накопитель или облачный том способен выполнить 3 000 операций ввода-вывода в секунду при определённых условиях.

Для облачного диска нужно проверить документацию тарифа. Например, правило 3 IOPS на 1 ГиБ относится к AWS EBS gp2, тогда как у gp3 базовые 3 000 IOPS не зависят от объёма.

Без размера блока, глубины очереди, соотношения чтения и записи и данных о задержке число 3 000 остаётся ориентиром.

Сколько IOPS нужно для 1С?

Единого значения на одного пользователя нет. Требования зависят от конфигурации 1С, СУБД, объёма базы, фоновых заданий и характера операций.

Точные показатели снимают по мониторингу рабочей системы или получают в нагрузочном тесте. В расчёт обязательно включают закрытие периода и другие пиковые сценарии.

Чем IOPS отличается от MB/s?

IOPS показывает количество операций за секунду, а MB/s - объём переданных данных.

При 16 000 IOPS пропускная способность составит:

• 62,5 МиБ/с при размере операции 4 КиБ;
• 4 000 МиБ/с при размере операции 256 КиБ.

На практике результат может быть ограничен интерфейсом, сетью или лимитом облачного тома.

Можно ли увеличить IOPS программно?

Физический предел накопителя или лимит облачного тарифа программно повысить нельзя. Но можно сократить количество обращений к диску:

• увеличить буферный кэш;
• оптимизировать запросы и индексы;
• разнести данные и журналы;
• настроить кэширование;
• перенести фоновые задачи на другое время.

Если после оптимизации система продолжает достигать лимита, потребуется другой класс хранилища или изменение архитектуры.