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

> Дискова підсистема сервера під навантаженням впирається в чергу запитів — IOPS, латентність, iostat і тести fio крок за кроком.

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

Черга запитів (I/O queue depth) — це кількість операцій читання і запису, які диск обробляє одночасно. У жорсткого диска фізична черга обмежена швидкістю механіки, у SATA SSD — протоколом AHCI (глибина черги до 32), у NVMe — самим протоколом NVMe, який підтримує до 65535 черг по 65536 команд у кожній. Саме тому [NVMe-диски](https://www.zevshost.net/uk/kb/nvme-sata-hdd-server-diski/) тримають високе навантаження помітно стабільніше за 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](https://www.zevshost.net/uk/kb/benchmark-servera-fio-sysbench/) з параметрами, близькими до реального навантаження. Для бази даних із великою кількістю дрібних випадкових операцій:

```
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: різниця в глибині черги на практиці

| Параметр | SATA SSD (AHCI) | NVMe |
| --- | --- | --- |
| Макс. глибина черги | 32 | 65536 на чергу |
| Кількість черг | 1 | до 65535 |
| Латентність випадкового читання | 0,1-0,2 мс | 0,02-0,05 мс |

На практиці різниця відчувається найсильніше в багатопотокових навантаженнях — бази даних, віртуалізація з десятками ВМ на одному хості, черги повідомлень. Для окремого диска під [сервер бази даних](https://www.zevshost.net/uk/kb/server-pod-bazu-dannyh/) NVMe майже завжди кращий за SATA SSD саме через глибину черги, а не лише через вищу лінійну швидкість.

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

- `%util` в iostat стабільно біля 100% — диск справді впирається у межу, а не є проблема в іншому місці.
- `await` зростає швидше, ніж зростає навантаження — черга не встигає розвантажуватися, варто перевірити RAID-контролер і режим кешування.
- Тест fio проведено з параметрами, близькими до реального профілю (розмір блоку, iodepth, частка читання/запису), а не з налаштуваннями за замовчуванням.
- Порівняння з паспортними IOPS диска показує розрив більший за 20-30% — варто перевірити вирівнювання розділів і режим TRIM.
- Для критичних БД і високонавантажених сервісів чергу і латентність перевірено на профілі рівня RAID (RAID 10 з [кількох дисків](https://www.zevshost.net/uk/kb/raid-urovni-0-1-5-10/)), а не на окремому накопичувачі.

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

---

Джерело: https://www.zevshost.net/uk/kb/diskovaya-podsistema-ocheredi/