Дискова підсистема: черги, IOPS, затримка

Що таке черга запитів диска і чому вона важлива

Черга запитів (I/O queue depth) — це кількість операцій читання і запису, які диск обробляє одночасно. У жорсткого диска фізична черга обмежена швидкістю механіки, у SATA SSD — протоколом AHCI (глибина черги до 32), у NVMe — самим протоколом NVMe, який підтримує до 65535 черг по 65536 команд у кожній. Саме тому NVMe-диски тримають високе навантаження помітно стабільніше за SATA при однаковій кількості IOPS.

Коли черга на диску зростає швидше, ніж він встигає її обробляти, час відповіді на кожен наступний запит збільшується — це і є зростання латентності під навантаженням, а не зниження "швидкості" у звичному сенсі.

IOPS і латентність: у чому різниця і як їх рахувати

IOPS (input/output operations per second) — це кількість операцій за секунду. Латентність — час виконання однієї операції, в мілісекундах або мікросекундах. Ці дві метрики пов'язані через чергу: приблизно IOPS = глибина черги / середня латентність однієї операції.

Для HDD типова латентність випадкового читання — 5-10 мс, для SATA SSD — 0,1-0,2 мс, для NVMe — 0,02-0,05 мс. Різниця у 100-200 разів між HDD і NVMe означає, що за однакової глибини черги NVMe дає в сотні разів більше IOPS на випадкових операціях, хоча на послідовному читанні великими блоками різниця вже не така велика.

Як виміряти чергу і затримку в реальному часі

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

iostat -x 1 5

У виводі важливі три колонки: avgqu-sz (або aqu-sz у нових версіях) — середня глибина черги, await — середній час очікування запиту в мілісекундах, %util — частка часу, коли диск був зайнятий обробкою запитів. Якщо %util тримається біля 100%, а await зростає — диск став вузьким місцем системи, і далі варто дивитися, що саме його навантажує.

Процес, який створює найбільше навантаження на диск, знаходять через:

iotop -o

fio: синтетичний тест під профіль реального навантаження

Щоб перевірити диск не абстрактно, а під конкретний сценарій, використовують fio з параметрами, близькими до реального навантаження. Для бази даних із великою кількістю дрібних випадкових операцій:

fio --name=randread --filename=/dev/nvme0n1 --rw=randread \
  --bs=4k --iodepth=32 --numjobs=4 --runtime=60 --time_based \
  --group_reporting

Для послідовного запису великими блоками, як під час бекапу або логування:

fio --name=seqwrite --filename=/data/testfile --rw=write \
  --bs=1M --size=10G --iodepth=8 --runtime=60 --time_based

У звіті fio дивляться на clat (completion latency) в процентилях — середнє значення маскує рідкісні, але болючі затримки на 99-му перцентилі, які саме і відчувають користувачі як підвисання.

NVMe проти SATA: різниця в глибині черги на практиці

На практиці різниця відчувається найсильніше в багатопотокових навантаженнях — бази даних, віртуалізація з десятками ВМ на одному хості, черги повідомлень. Для окремого диска під сервер бази даних NVMe майже завжди кращий за SATA SSD саме через глибину черги, а не лише через вищу лінійну швидкість.

Чек-лист діагностики проблем з диском

• %util в iostat стабільно біля 100% — диск справді впирається у межу, а не є проблема в іншому місці.
• await зростає швидше, ніж зростає навантаження — черга не встигає розвантажуватися, варто перевірити RAID-контролер і режим кешування.
• Тест fio проведено з параметрами, близькими до реального профілю (розмір блоку, iodepth, частка читання/запису), а не з налаштуваннями за замовчуванням.
• Порівняння з паспортними IOPS диска показує розрив більший за 20-30% — варто перевірити вирівнювання розділів і режим TRIM.
• Для критичних БД і високонавантажених сервісів чергу і латентність перевірено на профілі рівня RAID (RAID 10 з кількох дисків), а не на окремому накопичувачі.

Вимірювання черги і латентності до запуску сервісу в продакшн економить години розбору інцидентів пізніше: більшість скарг на "гальмуючий сервер" насправді зводиться до диска, який впирається у межу своєї черги.