Что такое IOPS на самом деле и почему цифра из прайса недостижима

MAATRIX

В характеристиках накопителя написано условное «до 500 000 IOPS», а на вашем сервере под реальной нагрузкой диск ощутимо тормозит — и это не значит, что вас обманули или диск бракованный. Цифра из прайса и то, что видит ваше приложение, — это два разных измерения, снятых в разных условиях. Разберёмся, что такое IOPS на самом деле, почему производитель имеет полное право писать именно ту цифру, что написал, и как замерить то число, которое действительно важно — под вашу нагрузку, а не под тестовую.

Что такое IOPS и как его считают

IOPS — input/output operations per second, число операций ввода-вывода в секунду. Операция — это одно обращение к накопителю: прочитать блок данных или записать блок данных. Не путайте с throughput (МБ/с) — это про объём данных, IOPS — про количество обращений, и это принципиально разные метрики, о которых чуть ниже отдельная секция.

Значение IOPS зависит от нескольких параметров одновременно, и производитель в характеристиках фиксирует конкретную комбинацию, которая даёт максимум:

• Размер блока (block size). Чем меньше блок, тем больше операций накопитель успевает сделать в секунду — но тем меньше данных передаётся за одну операцию. Стандарт для измерения IOPS — блок 4 КБ (4K random). Это исторически сложившийся ориентир, потому что мелкие случайные операции — самый тяжёлый паттерн для накопителя.
• Паттерн доступа: random vs sequential. Случайные операции (random) требуют от накопителя каждый раз обращаться к произвольному месту физического носителя. Последовательные (sequential) идут подряд, и контроллер накопителя может их предсказывать и оптимизировать. IOPS в характеристиках почти всегда — про random.
• Чтение или запись отдельно. Производитель публикует либо read IOPS, либо write IOPS, а иногда оба числа отдельно — потому что для флеш-памяти чтение и запись физически разные операции с разной стоимостью. Запись почти всегда медленнее чтения, особенно на насыщенном накопителе (подробнее о деградации SSD во времени — в статье про то, как SSD умирает медленно из-за wear leveling, но для темы IOPS важно, что write IOPS в характеристиках — это тоже потолок, а не гарантия).
• Глубина очереди (queue depth) и параллельность. Современные NVMe-накопители поддерживают десятки тысяч параллельных очередей команд. Чтобы выжать заявленный IOPS, тестовая нагрузка должна держать очередь максимально заполненной — обычно queue depth 32 и выше, с несколькими параллельными потоками (jobs). Одна программа, которая ждёт ответа на каждый запрос перед следующим (queue depth 1), никогда не приблизится к паспортному числу — не потому что диск плохой, а потому что тест снят в другом режиме.

Итог: паспортное «500 000 IOPS» почти всегда означает «500 000 операций чтения блоками по 4 КБ в случайном порядке при большой глубине очереди». Это честная цифра — но она отвечает на вопрос «что способен диск», а не на вопрос «что получит ваше приложение».

Почему заявленная цифра недостижима на практике

Дело не в маркетинговом обмане, а в том, что лабораторные условия почти никогда не совпадают с условиями реального сервера:

1. Реальная нагрузка смешанная. Веб-сервер параллельно читает статику и пишет логи. База данных читает индексы и одновременно пишет WAL/binlog. Смешанный read+write трафик на одном накопителе всегда медленнее, чем чистое чтение или чистая запись, потому что операции разного типа конкурируют за одну и ту же очередь и физический носитель переключается между режимами.
2. Размер блока в реальности другой. База данных чаще всего оперирует блоками 8–16 КБ (в зависимости от настроек), файловая система с логами и метаданными гоняет блоки разного размера, а копирование большого файла — это вообще sequential-паттерн с блоками в мегабайты. Чем крупнее блок, тем меньше операций в секунду совершает накопитель — за счёт того, что больше времени уходит на передачу самих данных.
3. Реальная глубина очереди ниже тестовой. Одно приложение с одним потоком запросов держит queue depth около 1. Даже нагруженная база данных с пулом соединений редко создаёт очередь в 32+ команды на один накопитель постоянно — обычно она колеблется, с пиками и провалами.
4. Файловая система и виртуализация добавляют накладные расходы. Между вашим приложением и физическим NAND-чипом стоит файловая система (ext4, XFS, ZFS со своими особенностями), в случае VPS — ещё и гипервизор с виртуальным диском, RAID-контроллер, а иногда и сетевое хранилище. Каждый слой добавляет свою латентность и снимает часть паспортного потолка.
5. Накопитель не пустой. Тестовая цифра часто снимается на пустом накопителе. По мере заполнения и накопления перезаписанных блоков контроллеру приходится делать garbage collection и wear leveling в фоне — это забирает часть IOPS у вашей нагрузки. Как это диагностировать на уже эксплуатируемом сервере — смотрите статью «Медленный диск на VPS: как проверить».

Ни один из этих пунктов не делает паспортную цифру неправильной — она просто измеряет другое. Разница между «до 500 000 IOPS» в характеристиках и «фактически видит ваше приложение 40 000–80 000 IOPS» (условный порядок, не измеренное значение) — это нормально, а не признак брака.

IOPS и throughput — это не одно и то же

Путаница между IOPS и мегабайтами в секунду — источник половины разочарований в характеристиках дисков. Разница простая:

• IOPS — сколько отдельных операций совершается в секунду. Критично для мелких случайных обращений: базы данных, почтовые серверы, виртуализация с множеством ВМ на одном хосте, любые сценарии с большим количеством маленьких файлов.
• Throughput (МБ/с) — сколько данных передаётся в секунду. Критично для последовательного чтения/записи больших файлов: видеомонтаж, бэкапы, стриминг, копирование образов.

Один и тот же накопитель показывает совершенно разные числа в зависимости от того, что вы измеряете:

Накопитель с огромным заявленным throughput (скажем, несколько ГБ/с последовательного чтения) может при этом не так сильно опережать конкурента по IOPS на мелких случайных операциях — throughput на sequential-паттерне и IOPS на random-паттерне зависят от разных характеристик контроллера и упираются в разные узкие места. Поэтому если ваша нагрузка — это база данных, ориентироваться на «скорость в МБ/с» из рекламы бессмысленно: смотрите IOPS и латентность. Почему это особенно критично для БД, разобрано отдельно в статье «Почему важна скорость диска для баз данных».

Что на самом деле нагружает ваш диск

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

• Реляционная БД (PostgreSQL, MySQL). Смешанный random read/write, блок обычно 8 КБ (PostgreSQL) или 16 КБ (InnoDB по умолчанию), плюс последовательная запись WAL/redo-лога отдельным потоком.
• NoSQL-хранилища (MongoDB, Redis с персистентностью). Похожий паттерн, часто с более крупными записями при флашах в память или на диск.
• Файловый сервер, много мелких файлов. Метаданные файловой системы — это отдельная категория IOPS-нагрузки, часто недооценённая: миллион мелких файлов создаёт огромное число операций на одни только inode и каталоги.
• Очереди сообщений, лог-агрегаторы. Почти всегда последовательная запись — здесь важнее throughput, чем IOPS.
• Виртуализация и контейнеры. Каждая ВМ или контейнер добавляет свой независимый поток операций, и на хосте они складываются в непредсказуемый смешанный паттерн — типичная причина, почему на «тихом» хосте вдруг проседает диск: соседняя ВМ начала бэкап.

Если не уверены, какой у вас паттерн — самый надёжный способ узнать это не гадать, а посмотреть на реальную статистику работающей системы (iostat -x 1, vmstat) хотя бы сутки, включая пиковые часы, прежде чем переходить к синтетическому тестированию.

Как честно замерить IOPS под свою нагрузку через fio

fio (Flexible I/O Tester) — стандартный инструмент для такого тестирования, доступен в репозиториях большинства дистрибутивов:

apt install fio    # Debian/Ubuntu
dnf install fio     # RHEL/Fedora/AlmaLinux

Общий принцип: тест должен как можно точнее повторять параметры вашей реальной нагрузки — размер блока, соотношение read/write, глубину очереди, — а не параметры из рекламного буклета.

Базовый тест на случайное чтение, приближенный к нагрузке БД (блок 8К, глубина очереди умеренная):

fio --name=randread_test \
    --filename=/path/to/testfile \
    --size=4G \
    --bs=8k \
    --rw=randread \
    --ioengine=libaio \
    --direct=1 \
    --iodepth=16 \
    --numjobs=4 \
    --runtime=60 \
    --time_based \
    --group_reporting

Смешанный read/write (70/30 — типичная пропорция для многих OLTP-нагрузок, но проверьте свою реальную пропорцию через iostat):

fio --name=mixed_test \
    --filename=/path/to/testfile \
    --size=4G \
    --bs=8k \
    --rw=randrw \
    --rwmixread=70 \
    --ioengine=libaio \
    --direct=1 \
    --iodepth=16 \
    --numjobs=4 \
    --runtime=60 \
    --time_based \
    --group_reporting

Ключевые параметры, которые нужно осознанно подбирать под себя, а не копировать из примера:

• --bs — размер блока, соответствующий вашему приложению (проверьте документацию своей СУБД или посмотрите реальный размер блока файловой системы и настройки БД).
• --rw — паттерн: read/write (последовательно), randread/randwrite (случайно), randrw (смешанно, с --rwmixread для пропорции).
• --iodepth и --numjobs — вместе задают эффективную глубину очереди. Начните с низких значений (1–4), которые ближе к типичной нагрузке одного приложения, и отдельно прогоните высокие (32+), чтобы увидеть паспортный потолок — разница между этими прогонами и есть ответ на вопрос «сколько теряется на моей реальной нагрузке».
• --direct=1 — обходит кэш файловой системы, иначе тест меряет скорость RAM, а не диска.
• --runtime и --time_based — тест должен идти достаточно долго (не 5 секунд), чтобы накопитель вышел на устойчивый режим, особенно если он уже частично заполнен.

Важно: тестируйте на файле сопоставимого с реальным использованием размера, а лучше — на самом разделе, где будет жить нагрузка (создав тестовый файл, который потом удалите). На почти пустом накопителе результаты будут оптимистичнее, чем на заполненном на 70–80%.

Как читать результаты и не обмануться самому

fio выдаёт много цифр, и IOPS — не единственная важная метрика:

• IOPS (read/write отдельно и суммарно) — базовое число, но само по себе неполное без контекста латентности.
• Latency (клат, среднее и percentiles — p50, p95, p99). Это критичнее голого IOPS: одна и та же средняя цифра IOPS может скрывать стабильную работу или редкие, но болезненные задержки в 99-м перцентиле. Для интерактивных приложений (веб-запрос, ожидающий ответа от БД) p99 латентность часто важнее среднего IOPS.
• bw (bandwidth) — throughput в том же прогоне, полезно смотреть вместе с IOPS, чтобы понимать, где вы упираетесь: в количество операций или в объём данных.

Практический подход к интерпретации:

1. Прогоните тест с параметрами, максимально близкими к вашей реальной нагрузке (шаг выше) — это и есть «ваш» реальный IOPS, честное число для планирования.
2. Прогоните тот же тест с параметрами из рекламного буклета производителя (4K, чистое чтение, iodepth 32+) — это подтвердит или опровергнет паспортную цифру и покажет масштаб разрыва именно на вашем железе.
3. Сравните латентность, а не только IOPS, между прогонами при разной глубине очереди — рост латентности при увеличении iodepth подскажет, где именно накопитель или контроллер начинает захлёбываться.
4. Повторите тест через несколько недель эксплуатации на заполненном накопителе — деградация со временем реальна и не всегда видна на новом диске.

Не гонитесь за одним «правильным» числом IOPS — правильного числа не существует вне контекста конкретной нагрузки. Задача — получить воспроизводимый бенчмарк, который вы сможете сравнить между разными серверами или после смены конфигурации (например, после перехода с SATA SSD на NVMe или после настройки RAID).

Частые вопросы