Предел IOPS: как отличить упор в диск от упора во всё остальное

MAATRIX

Сервер тормозит, а top показывает, что процессор почти свободен. Первая мысль — «диск». Но диск не сообщает о своём пределе прямым текстом: он просто отвечает медленнее, а причина может прятаться где угодно — от файловой системы до сетевого хранилища. У каждого накопителя есть потолок операций в секунду (IOPS), и разница между HDD, SSD и NVMe — не в разы, а на порядки. Разберём, как измерить этот потолок, отличить упор в диск от упора в CPU, память и сеть, и что делать, когда предел действительно найден.

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

IOPS (input/output operations per second) — число операций чтения или записи, которые накопитель успевает выполнить за секунду. В отличие от пропускной способности (MB/s), IOPS не зависит напрямую от размера блока — это метрика количества, а не объёма.

Предел IOPS складывается из нескольких независимых ограничений одновременно:

• Механика или электроника носителя. У HDD это время позиционирования головки и вращения пластины — по своей природе десятки операций в секунду. У SSD и NVMe — параллелизм NAND-кристаллов и контроллера, счёт уже на десятки и сотни тысяч.
• Интерфейс и глубина очереди. SATA ограничивает очередь 32 командами, NVMe — тысячами команд на очередь и десятками тысяч очередей. Если утилизируется только одна команда за раз, паспортный потолок диска попросту недостижим.
• RAID и его write penalty. Каждая операция записи в RAID 5/6 превращается в несколько физических операций (чтение блока, чтение чётности, запись блока, запись чётности), поэтому логический IOPS ниже суммы IOPS дисков в массиве.
• Файловая система и её накладные расходы. Журналирование, copy-on-write — всё это добавляет операции, которые не видны в приложении, но съедают часть предела.
• Программные лимиты аренды. В виртуализации диск нередко ограничен отдельно от физического предела носителя — это часть тарифа, а не свойство железа.

Важно: предел IOPS — не константа диска, а константа диска *в конкретном сценарии*. Один и тот же NVMe даст разные цифры на случайной записи 4К и на последовательном чтении 128К. Все паспортные цифры производителей — это IOPS на самом выгодном для диска паттерне, и в реальной нагрузке вы их не увидите.

Сколько IOPS дают разные типы хранилищ

Ниже — ориентировочные диапазоны для случайного доступа блоками 4К при достаточной глубине очереди. Это не гарантия и не бенчмарк конкретной модели — у вашего железа будет своя цифра, которую нужно мерить fio. Смысл таблицы — показать порядок величины, а не точное число.

Нюансы, которые таблица не показывает:

• HDD деградирует резко при случайном доступе. Последовательная запись даёт сотни MB/s, но на случайных операциях производительность падает на два-три порядка. Для баз данных это критично, поэтому HDD там почти не используют.
• SSD и NVMe теряют IOPS по мере заполнения и износа — из-за роста нагрузки на wear-leveling и write amplification.
• RAID меняет цифру, а не просто складывает диски. RAID 10 почти линейно масштабирует IOPS чтения и вдвое штрафует запись. RAID 5/6 штрафуют запись сильнее — из-за чтения-модификации-записи чётности.

Единственный способ узнать реальный предел именно вашего диска в вашей конфигурации — прогнать fio с паттерном, близким к вашей нагрузке (размер блока, доля чтения/записи, глубина очереди), а не полагаться на цифры из даташита или из статьи в интернете, включая эту. Методика честного замера разобрана в статье fio для честного замера диска.

Как читать iostat: %util, await, очередь

Базовый инструмент диагностики — iostat из пакета sysstat:

iostat -x 1

Ключевые колонки (имена немного отличаются между версиями sysstat, смысл один):

• r/s, w/s — операций чтения и записи в секунду. Это и есть текущий IOPS.
• await (или r_await/w_await) — среднее время ожидания операции в очереди плюс её выполнение, в миллисекундах. Главный индикатор задержки, которую реально чувствует приложение.
• aqu-sz (раньше avgqu-sz) — средняя глубина очереди запросов к устройству.
• %util — доля времени, когда у устройства была хотя бы одна необработанная операция.

Здесь скрывается частая ошибка чтения метрик: %util = 100% не означает, что диск физически исчерпан. Для однопоточного HDD это действительно предел — устройство обслуживает запросы строго последовательно. Но у NVMe с параллельными очередями %util показывает лишь долю времени с непустой очередью, а реальный запас по IOPS может ещё оставаться. Подробный разбор этой метрики — в статье почему 100% загрузки диска не значит предел.

Порядок диагностики:

1. Смотрите на await, а не только на %util. Если await растёт (для SSD/NVMe заметно выше долей-единиц миллисекунд, для HDD — выше 10-20 мс) вместе с ростом aqu-sz — очередь копится, диск не успевает.
2. Сравнивайте текущий r/s + w/s с пределом, измеренным fio для этого же паттерна. Если IOPS близок к максимуму, а await растёт — упор именно в диск.
3. Разложите нагрузку по устройствам (iostat -x 1 -p ALL или конкретные /dev/sdX) — часто тормозит только один раздел или один физический носитель в массиве.
4. Для конкретного процесса используйте pidstat -d 1 — покажет чтение/запись и задержки по PID.

Дополнительно полезны iotop -o (кто пишет/читает прямо сейчас) и для NVMe — nvme smart-log /dev/nvme0 (счётчики media errors укажут на аппаратную, а не нагрузочную причину).

Как отличить упор в диск от CPU, памяти и сети

Диск — не единственный подозреваемый. Симптомы (медленные ответы, растущие очереди в приложении) у разных причин выглядят похоже.

Упор в CPU. Смотрите vmstat 1 или mpstat -P ALL 1. Если %usr + %sys близки к 100% на всех ядрах, а iowait низкий — узкое место процессор, а не диск. Обратный признак: высокий %iowait в top/vmstat говорит, что процессы простаивают именно в ожидании диска.

Упор в память. Если free -h показывает мало свободной памяти и активный своп (si/so в vmstat не нулевые), падение производительности вызвано тем, что система вытесняет страницы в swap — а это тоже дисковые операции, только не те, что генерирует приложение напрямую. Сначала разбирайтесь с памятью, а потом возвращайтесь к диску.

Упор в сеть. Для сетевых хранилищ (NFS, iSCSI, Ceph RBD, облачные диски) задержка может складываться из сетевого RTT и очередей на стороне стораджа, а не из скорости самого носителя. iostat на клиенте покажет высокий await, но причина — не локальный диск. Проверяйте сеть и метрики самого storage-кластера отдельно.

Упор в приложении. Блокировки внутри СУБД или недостаточный буферный пул тоже выглядят как «тормоза», хотя iostat при этом показывает низкий IOPS и низкий await — диск ни при чём, проблема в самой нагрузке.

Быстрый чек-лист:

vmstat 1 5       # CPU, память, iowait в одном экране
mpstat -P ALL 1  # загрузка по ядрам
free -h          # память и swap
iostat -x 1 5    # диск: r/s, w/s, await, %util, aqu-sz
pidstat -d 1     # диск по процессам

Если высокий await и растущая очередь на диске совпадают по времени с падением отклика приложения — упор в диск подтверждён. Если в этот же момент iowait низкий, а %usr высокий — дело не в диске.

RAID и файловая система: как они меняют потолок

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

Write penalty — множитель, показывающий, сколько физических операций записи требуется на одну логическую:

• RAID 0 — penalty 1 (нет избыточности, нет и защиты от отказа).
• RAID 1 / RAID 10 — penalty 2 (пишем на зеркало).
• RAID 5 — penalty 4 (чтение блока данных, чтение чётности, запись блока, запись чётности).
• RAID 6 — penalty 6 (двойная чётность увеличивает число операций).

На чтении RAID 10 и RAID 5/6 обычно масштабируются близко к линейному числу дисков, разница проявляется на записи. Для нагрузки с высокой долей случайной записи (базы данных, очереди сообщений) RAID 10 почти всегда выигрывает по IOPS у RAID 5/6 при том же числе дисков — ценой меньшей полезной ёмкости.

Файловая система тоже вносит свой вклад: журналирование (ext4, XFS) добавляет операции записи в журнал до записи в основную область данных, а copy-on-write системы (ZFS, Btrfs) пишут новые блоки вместо перезаписи старых — это увеличивает число физических операций.

Отдельная деталь — аппаратный RAID-контроллер с батарейкой (BBU/supercap) может кэшировать записи в собственной памяти и подтверждать их приложению раньше физической записи на диск, резко увеличивая наблюдаемый IOPS. Но это зависит от исправности батарейки: разряженная батарейка часто переводит контроллер в режим write-through, и производительность падает без видимой причины на уровне ОС.

Измеряя IOPS, вы измеряете не диск как таковой, а всю цепочку «приложение → файловая система → RAID/LVM → драйвер → носитель». Узкое место может оказаться в любом её звене — подробнее об уровнях и выборе RAID под конкретную нагрузку в статье RAID на сервере: уровни и как выбрать.

Что делать, когда упёрлись в диск

Если диагностика (высокий await, растущая очередь, IOPS у измеренного fio предела) подтвердила, что узкое место — диск, вариантов действий несколько, и они не взаимоисключающие.

1. Кэширование, чтобы часть операций вообще не доходила до диска. Увеличение буферного пула СУБД (innodb_buffer_pool_size в MySQL, shared_buffers в PostgreSQL) переносит часть чтений из диска в память — иногда это даёт больший эффект, чем смена носителя, потому что буфер убирает операцию, а не ускоряет её.

2. Переход на более быстрый тип носителя. От HDD к SATA SSD — рост на порядки для случайной нагрузки. От SATA SSD к NVMe — рост в первую очередь по глубине очереди и параллелизму, что заметно под многопоточной нагрузкой (базы данных, много одновременных подключений).

3. Изменение паттерна нагрузки. Если приложение генерирует много мелких случайных операций там, где можно писать последовательно (батчинг записей, увеличение размера транзакции, отложенный flush), IOPS-нагрузка снижается без смены железа.

4. Распределение нагрузки между дисками. Вынос логов, временных файлов сортировки СУБД, бэкапов или журнала транзакций (WAL) на отдельный физический диск снимает конкуренцию за очередь с основной рабочей нагрузкой.

5. Смена уровня RAID под характер нагрузки. Если преобладает случайная запись и текущий массив — RAID 5/6, переход на RAID 10 при том же числе дисков увеличивает доступный IOPS записи ценой полезной ёмкости — компромисс, который стоит явно проговорить перед миграцией.

6. Проверка лимитов виртуализации, если сервер — виртуальный. В облаке и на VPS предел IOPS нередко устанавливается программно ниже физического предела носителя. Если fio упирается в круглое число (например, ровно 3000 или 5000 IOPS) независимо от блока и паттерна — это признак программного лимита, а не физического предела. Общая методика поиска причины медленного диска на VPS — в статье медленный диск на VPS: как проверить. На выделенном сервере с собственным NVMe такого программного потолка нет — только физический предел железа.

Ни один из пунктов не универсален: кэширование не поможет, если рабочий набор данных больше объёма памяти, которую можно выделить под буфер. Смена RAID не поможет, если предел упирается в интерфейс диска, а не в write penalty. Прежде чем менять конфигурацию, стоит убедиться через iostat и fio, что причина именно та, которую вы собираетесь лечить.

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