IOPS простыми словами: как правильно читать характеристики дисков и SSD

Будем откровенны: большинство людей узнают про IOPS не из учебника, а в тот момент, когда база начинает ползать, а мониторинг показывает загадочное «диск загружен на 100%». Лезешь в спецификации, видишь гордые «до 500 000 IOPS», а у тебя в продакшене - не то, что сотни тысяч, там и пара тысяч «честных» операций уже подарок.

Разобраться, что именно стоит за этой цифрой, полезно всем: админам, которые считают дисковую подсистему под виртуализацию, разработчикам, которые удивляются задержкам в проде, и тем, кто просто выбирает SSD под рабочую станцию и не хочет переплачивать за бумажный «миллион IOPS».

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

Что такое IOPS и почему вокруг столько шума

Если отбросить официальные формулировки, IOPS - это просто ответ на вопрос «сколько раз диск успеет что-то прочитать или записать за секунду». Не мегабайты, не гигабайты, а именно количество отдельных операций ввода-вывода. Маленький блок 4 КБ - это одна операция, большой блок 1 МБ тоже одна операция, хотя данных там уже совсем другой объём.

Вот тут и начинается путаница. Маркетинг любит крупные цифры, поэтому в паспортах обычно пишут IOPS на мелких блоках (классические 4 КБ) и в идеальном режиме. В итоге на бумаге получается «сотни тысяч операций», а в реальном приложении, которое пишет крупными блоками и еще что-то параллельно читает, цифры оказываются скромнее. Не потому, что диск плохой, а потому что условия другие.

Сравнивать IOPS с мегабайтами в секунду смысла особого нет. Это не «или-или», это две проекции одного и того же процесса. Можно получить высокий IOPS и довольно скромный поток в МБ/с (если работаем мелкими блоками), а можно выдавать приличную пропускную способность и при этом иметь совсем небольшое количество операций (крупные последовательные блоки). На уровне приложений обычно важны оба параметра: базам и виртуализации критичны IOPS и latency, а бэкапам и видеоархивам важнее поток.

Если смотреть по классам железа, картина такая: обычный HDD в случайной нагрузке даёт десятки-сотню IOPS, быстрый SAS-диск - пару сотен, потребительский SSD - десятки тысяч, серверный NVMe - сотни тысяч. И это всё при одинаковом определении операции. Как только меняем размер блока, глубину очереди или профиль нагрузки - цифры становятся другими.

Что действительно влияет на IOPS

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

Во-первых, задержка одной операции. Звучит банально, но математике всё равно. Если диску нужно 10 миллисекунд, чтобы выполнить одну случайную операцию, выше ~100 IOPS вы в этих условиях не прыгнете, хоть обвесьте его наклейками «enterprise». У HDD львиная доля задержки - механика: пока головка доедет, пока пластина довернется. У SSD время тратится на контроллер и флеш, зато нет механики, поэтому IOPS вырастают на порядки.

Во-вторых, размер блока. Чем мельче рубим данные, тем больше операций в секунду теоретически можно уместить при той же пропускной способности. На 4 КБ всё выглядит бодро, на 64 КБ цифры уже падают, на мегабайтных блоках IOPS становятся совсем небольшими - и это нормально. Поэтому «100 000 IOPS» без приписки «на каком блоке», примерно, как «максимальная скорость до 300 км/ч» без уточнения, с горки это или по городу.

В-третьих, глубина очереди. Современные контроллеры отлично чувствуют себя, когда им подсовывают пачку запросов сразу, а не по одному. На одиночной операции диск показывает одно значение, на очереди в десятки-сотни запросов - совсем другое. В бенчмарках это любят: выставили Queue Depth 32 или 64, получили «вау-цифру», повесили в презентацию. На рабочей станции обычного пользователя такой параллелизм не всегда возникает, зато в виртуализации с десятком машин на одном datastore -пожалуйста

Четвертый слой - это всё, что вокруг диска. RAID-уровень, контроллер, кэш, интерфейс, сеть, HBA, виртуализация поверх всего этого. Один и тот же SSD в виде одиночного диска, в составе RAID10, в SAN и под сотней виртуальных машин даёт четыре разных сценария по IOPS, и каждый раз узкое место может быть в новом месте. Поэтому «500 000 IOPS на массив» звучит грозно, но без деталей о конфигурации это мало что говорит.

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

• задержка операции и всё, что её увеличивает;
• размер блока и профиль нагрузки (случайный/последовательный, чтение/запись);
• глубина очереди и уровень параллелизма;
• класс накопителя (HDD, SATA SSD, NVMe), контроллер и интерфейс;
• конфигурация системы хранения и соседние слои (RAID, кэш, сеть, гипервизор).

Как я бы проверял IOPS на живом сервере, а не в вакууме

Теоретические формулы удобны, когда нужно «на салфетке» прикинуть порядок величин. Если вы знаете среднюю задержку операции, грубая оценка получается простой: одна операция занимает X миллисекунд - делим секунду на X и понимаем, сколько влезет. Но в работе этого мало. Хочется увидеть, как ведет себя конкретный диск или массив под конкретной нагрузкой.

В Linux стандартный рабочий инструмент - fio. Утилита не самая дружелюбная к новичкам, но за это платим гибкостью. Я обычно делаю так: беру профиль, похожий на реальное приложение (например, случайное чтение/запись 4-8 КБ, смешанное 70/30 или 50/50), задаю разумную глубину очереди и прогоняю тест на отдельном разделе или LUN. Важно не превращать это в спорт: наша задача не «выжать максимум ради скрина», а понять, как себя ведёт система под нагрузкой, похожей на боевую.

В Windows картина похожая. Есть DiskSpd, есть готовые пресеты для разных сценариев, есть Performance Monitor, который показывает реальные IOPS и latency под живой нагрузкой. И вот здесь кроется самый полезный приём: сначала смотрим, что творится на рабочем сервере сейчас (какие IOPS в пике, какие задержки, какой разброс по размеру блоков), а уже потом бежим запускать синтетику. Так не приходится гадать, какой именно профиль нагрузки выбирать - мы его уже подсмотрели.

Отдельная история - облачные диски. Там провайдер обычно сам даёт рекомендации: какие параметры указать в fio/DiskSpd, чтобы проверить заявленные пределы по IOPS и пропускной способности. Смысл тот же: прогнать тест, убедиться, что цифры хотя бы примерно совпадают с обещаниями, и уже после этого завязывать на такой диск базу, кластер или файловое хранилище. Если тест показывает половину от заявленного, лучше выяснить причину сейчас, чем потом искать её в продакшене.