Ваш SSD повільний без причини: помилка драйвера зберігання

February 18, 2026 • February 18, 2026 • Читання: 4 хв • Views: 0

Було корисно?

Ви купили швидку флеш-пам’ять. Ви перенесли навантаження. Ви мрійливо дивилися на рекламні «до» показники виробника.
А потім продакшен сказав: «Мило. Я робитиму 40 MB/s і 30 ms затримки».

Коли SSD повільні, люди звинувачують файлову систему, додаток, «якимось чином мережу» або фазу місяця.
Часто справжній винуватець нудний: неправильний шлях драйвера, неправильний режим черг або шар сумісності, що тихо бере керування.
Ви не зможете налаштуваннями виправити неправильний стек.

Як виглядає «SSD повільний» у продакшені

Повільність SSD зазвичай не виражається одним числом. Це характер. Вона проявляється як:
хвостова латентність, що перетворюється на таймаути сторінок, ідеально середня пропускна здатність з рандомними затримками 200 ms,
база даних, яка «працює нормально» до контрольної точки, або черга повідомлень, що випадково стала пакетним процесором.

Страшне в тому, що диск може бути в нормі. PCIe-з’єднання може бути в нормі. NAND може бути в нормі.
Але якщо ОС спілкується з диском через неправильний драйвер, неправильний транспорт або неправильну модель черг,
ви опинитеся з шасі Ferrari, що тягнеться візочним колесом.

Те, що робить цей тип проблем підступним — наскільки правдоподібні інші пояснення. Файлові системи можуть бути повільними.
Додатки можуть бути повільними. Хмарні томи можуть бути повільними. Звісно. Але «неправильний шлях драйвера» ховається на очах,
бо все ще працює. Просто… депресивно функціонує.

Цікаві факти та історія (бо зберігання пам’ятає і мстить)

NVMe — це не просто «швидший SATA». Він створений для низької затримки та паралельної відправки команд з багатьма чергами; SATA/AHCI орієнтувався на одначергову модель.
За замовчуванням глибина черги AHCI мізерна за сучасними стандартами. NCQ існує, але архітектура була побудована навколо обертових дисків і помірної конкуренції.
Багаточерговий блоковий шар Linux (blk-mq) став поворотним моментом. Він допоміг масштабувати відправку IO по CPU, але також додав нові поверхні для налаштування і нові підводні камені.
Планувальники IO не зникли — деякі просто стали неактуальними. Для NVMe часто правильний вибір — «none»; для деяких SATA SSD за контролерами HBA планувальник ще може мати значення.
Політика кешу запису десятиліттями сперечається з адміністраторами. «Швидше» і «безпечніше» часто — протилежні релігії.
TRIM/DISCARD — це не безкоштовний обід. Онлайн-discard може створювати сплески латентності в залежності від прошивки пристрою та поведінки ядра; періодичний fstrim часто поводиться краще.
Шари емуляції SCSI повсюди. Багато гіпервізорів і систем зберігання експонують «SCSI-диски», навіть коли бекенд — SSD/NVMe; це може обмежувати черги і ускладнювати налаштування.
Multipath може бути фішкою продуктивності або податком на неї. Одна невірна політика може перетворити паралельні шляхи на послідовну сумну історію.
Проблеми узгодження ширини/швидкості PCIe трапляються частіше, ніж визнають. Один брудний контакт може «понизити» ваш NVMe до дуже дорогого SATA-пристрою.

Швидкий план діагностики (перший/другий/третій)

У вас немає часу на духовну подорож по підсистемах ядра. Хочеться сигналу, швидко.
Ось порядок, який найчастіше ловить найбільші «SSD повільний» помилки драйвера з найменшими зусиллями.

Перший: підтвердьте, що думає ядро про пристрій

Це справді nvme, чи воно з’являється як sdX через трансляцію SCSI?
Чи знаходиться за апаратним RAID/HBA у режимі, який ви не мали на увазі?
Чи ввімкнено multipath без вашого відома?

Другий: підтвердьте базові параметри лінку і черг

Ширина і швидкість PCIe (NVMe): x4 проти x1, Gen4 проти Gen1 має значення.
Кількість черг і глибина черги: одна черга змусить багатоядерну коробку плакати.
Розподіл IRQ: один CPU, що обробляє всі завершення NVMe, — класичний «чому CPU на 20% і все ще повільно?» випадок.

Третій: правильно виміряйте латентність перед налаштуванням

Використовуйте iostat -x для завантаження та середньої латентності.
Використовуйте nvme smart-log (NVMe) або smartctl (SATA/SAS) для підказок з боку пристрою.
Запустіть контрольований fio тест, щоб зрозуміти, чи повільність специфічна для навантаження або системна.

Лише після цього торкайтеся планувальників, nr_requests, read-ahead, прапорців монтування файлової системи або налаштувань БД.
Якщо стек драйверів неправильний, налаштування — це просто декоративні зміни проблеми.

Помилка драйвера зберігання, що за цим стоїть

Помилка буває кількох відтінків, але вони римуються: ОС не використовує прямий, передбачений драйвер для апаратури,
або використовує правильний драйвер з невірною моделлю черг/переривань через налаштування за замовчуванням або спадщину конфігурацій.

Варіант 1: «Це NVMe» (але представлено як SCSI)

На bare metal справжній NVMe-пристрій з’являється як /dev/nvme0n1 і використовує драйвер nvme.
У багатьох середовищах — особливо віртуалізованих і деяких пристроях зберігання — швидкий бекенд може бути представлений як диск SCSI:
/dev/sda, ланцюг драйверів через virtio-scsi, mpt3sas, device-mapper або multipath.

Іноді це нормально. Іноді це тихо обмежує черги, змінює поведінку завершень або вводить єдину точку звуження черги.
Бекенд може робити 800k IOPS. Ваш гостьовий ОС може надсилати 30k. Всі звинувачують SSD.

Варіант 2: AHCI/SATA шлях використовується, коли існує NVMe шлях

Це трапляється через дивні налаштування BIOS, незвичні carrier-карти або пристрої, що можуть працювати в кількох режимах.
Диск, який мав би бути на PCIe/NVMe шляху, в результаті маршрутизується через SATA-контролер або шар трансляції.
Він працює. Але при конкуренції залишає продуктивність на столі.

Варіант 3: blk-mq/черги/IRQ не узгоджені з топологією CPU

NVMe розрахований на паралелізм. Linux здатний на паралелізм. Але ви все одно можете отримати:
одну чергу, один IRQ, один CPU і 63 інших ядра, що лише дивляться на це.
Або ви можете отримати потоки переривань, закріплені на CPU0 через старі налаштування irqbalance, старі правила initramfs,
або через когось, хто «оптимізував переривання» в 2019 і забув про це.

Варіант 4: Шари device-mapper роблять більше, ніж ви думаєте

LVM, dm-crypt, dm-multipath, MD RAID — вони можуть бути цілком нормальними. Вони також можуть бути налаштовані в глухий кут:
невірний розмір шматка, неправильний планувальник, помилкова політика кешу запису, невірний вибір шляху.
Профіль продуктивності стає «добре в бенчмарках, сумно в продакшені», бо реальний IO не такий чемний.

Операційне правило: перед тим як звинувачувати SSD, прослідкуйте IO-шлях від початку до кінця і підтвердіть драйвер та модель черг на кожному шарі.

Одна перефразована ідея від W. Edwards Deming болісно підходить для роботи зі зберіганням: Без даних ви просто ще одна людина з думкою. (перефразована ідея)

Практичні завдання: команди, виводи та рішення (12+)

Це перевірки, які я реально виконую, коли SSD «повільний». Кожне завдання містить: команду, що означає вивід, і рішення, яке ви приймаєте.
Виконуйте від імені root там, де потрібно.

Завдання 1: Визначте пристрій і транспорт (NVMe проти SCSI/SATA)

cr0x@server:~$ lsblk -o NAME,MODEL,SIZE,ROTA,TYPE,TRAN,MOUNTPOINTS
NAME        MODEL               SIZE ROTA TYPE TRAN MOUNTPOINTS
nvme0n1     SAMSUNG MZVL21T0HCLR 1.0T    0 disk nvme
├─nvme0n1p1                      1G    0 part nvme /boot
└─nvme0n1p2                   1023G    0 part nvme /

Значення: TRAN nvme і ROTA 0 — те, що вам потрібно для локального NVMe SSD.
Якщо бачите sda з TRAN sas або порожнім транспортом замість очікуваного NVMe — скоріш за все у вас шлях трансляції.

Рішення: Якщо транспорт не той, що ви очікуєте, припиніть налаштування й промапуйте IO-шлях (Завдання 2–4).

Завдання 2: Подивіться, який драйвер зв’язано з пристроєм у ядрі

cr0x@server:~$ readlink -f /sys/block/nvme0n1/device/driver
/sys/bus/pci/drivers/nvme

Значення: Це підтверджує драйвер ядра. Для SATA-пристроїв ви побачите PCI-драйвери, пов’язані з AHCI; для HBA — mpt3sas/megaraid_sas тощо.

Рішення: Якщо драйвер не той, що ви очікували, досліджуйте режим BIOS/контролера і кабелювання/бекаплейн.

Завдання 3: Для SCSI-дисків ідентифікуйте HBA/віртуальний контролер

cr0x@server:~$ lsscsi -t
[0:0:0:0]    disk    ATA      SAMSUNG SSD 860  3B6Q  /dev/sda
  \_ transport: sata: phy-0:0:0

Значення: Це показує, який стек презентує диск. У VM ви можете побачити virtio або SCSI-контролер вендора.

Рішення: Якщо ви на спадщині емульованого контролера, переключіться на virtio-blk/virtio-scsi або віртуальний NVMe, якщо підтримується.

Завдання 4: Перевірте шари device-mapper (LVM, crypt, multipath)

cr0x@server:~$ lsblk -o NAME,TYPE,FSTYPE,SIZE,MOUNTPOINTS
NAME            TYPE FSTYPE      SIZE MOUNTPOINTS
sda             disk             1.8T
└─mpatha         mpath            1.8T
  └─vg0-lvdata    lvm  xfs        1.8T /data

Значення: mpath вказує на dm-multipath. Це не «погано», але це цілий політичний двигун між вами та SSD.

Рішення: Якщо присутній multipath — перевірте політику шляхів і чергування (Завдання 10). Якщо він випадковий — видаліть обережно.

Завдання 5: Підтвердіть ширину/швидкість PCIe (NVMe)

cr0x@server:~$ lspci -s 01:00.0 -vv | sed -n '/LnkCap:/,/LnkSta:/p'
LnkCap: Port #0, Speed 16GT/s, Width x4
LnkSta: Speed 8GT/s (downgraded), Width x1 (downgraded)

Значення: Пристрій може працювати в Gen4 x4, але погодився на Gen3 x1. Це може розлити пропускну здатність і збільшити латентність під навантаженням.

Рішення: Пересадіть диск, перевірте бекаплейн, налаштування BIOS, якість riser’ів і прошивку. Не витрачайте час на програмні налаштування, поки це не виправлено.

Завдання 6: Перевірте можливості контролера NVMe і інформацію про namespace

cr0x@server:~$ nvme id-ctrl /dev/nvme0 | egrep -i 'mn|fr|mdts|oacs|sqes|cqes'
mn      : SAMSUNG MZVL21T0HCLR
fr      : GXA7401Q
mdts    : 9
oacs    : 0x17
sqes    : 0x66
cqes    : 0x44

Значення: Ревізія прошивки має значення; так само й обмеження, як MDTS (max data transfer size). Маленький MDTS може обмежувати ефективність розміру IO.

Рішення: Якщо прошивка стара або відома проблемна у вашому флоті — заплануйте вікно оновлення. Якщо MDTS маленький, слідкуйте за навантаженнями з великими IO.

Завдання 7: Перевірте кількість черг і планувальник для блочного пристрою

cr0x@server:~$ cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadline kyber bfq

Значення: Для більшості NVMe none є доречним; він покладається на внутрішнє планування пристрою і уникає зайвих накладних витрат ядра.
Для деяких пристроїв/навантажень mq-deadline може стабілізувати латентність.

Рішення: Якщо на сервері встановлено bfq для робочого навантаження — це підозріло. Використовуйте none або mq-deadline, якщо немає перевіреної причини інакше.

Завдання 8: Перевірте обмеження глибини черги (nr_requests, max_sectors_kb)

cr0x@server:~$ cat /sys/block/nvme0n1/queue/nr_requests
64

Значення: Це глибина черги запитів на рівні блоку. Надто мало — може обмежувати конкуренцію; надто багато — підвищує латентність і використання пам’яті.

Рішення: Якщо бачите дуже низькі значення на зайнятому NVMe-пристрої — з’ясуйте причину (udev-правила, профілі tuned). Міняйте тільки після вимірювань з fio.

Завдання 9: Подивіться реальну латентність пристрою та завантаження

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0 (server)  02/04/2026  _x86_64_ (64 CPU)

Device            r/s     w/s   rMB/s   wMB/s   await  svctm  %util
nvme0n1         1200    800     90.0   110.0    18.5   0.4   98.0

Значення: %util близько до 100% з низьким svctm але високим await натякає на черги: пристрій швидкий, але запити чекають.
Це може бути нормою під сильним навантаженням — але також може означати, що ви маєте вузьке місце однієї черги upstream.

Рішення: Якщо await високий, а пропускна здатність не вражає — заглиблюйтеся в черги/IRQ і будь-які DM-шари.

Завдання 10: Перевірте політику dm-multipath і стан шляхів

cr0x@server:~$ multipath -ll
mpatha (3600508b400105e210000900000490000) dm-2 NETAPP,LUN
size=1.8T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:1 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:1 sdc 8:32 active ready running

Значення: Політика і пріоритет визначають, як IO розподіляється. Деякі політики фактично серіалізують IO на один шлях, якщо не налаштовано інакше.

Рішення: Якщо ви очікували балансування навантаження, але бачите один шлях, що виконує всю роботу — виправте конфіг multipath (і валідуйте через iostat для sdb/sdc).

Завдання 11: Перевірте розподіл IRQ для NVMe (тест «CPU0 сумний»)

cr0x@server:~$ grep -i nvme /proc/interrupts | head
  45:  98234120   1023      0      0      0      0      0      0  IR-PCI-MSI 524288-edge  nvme0q0
  46:       120 98220110      0      0      0      0      0      0  IR-PCI-MSI 524289-edge  nvme0q1

Значення: Бажано, щоб переривання були розподілені по CPU. Якщо всі лічильники сходяться на одному CPU — латентність може зростати під навантаженням.

Рішення: Якщо спотворено, перевірте irqbalance, CPU affinity і чи система не закріплює переривання через старі налаштування.

Завдання 12: Перевірте поведінку TRIM/discard

cr0x@server:~$ findmnt -no TARGET,OPTIONS /
/ rw,relatime,discard

Значення: Онлайн discard ввімкнено. Це може бути нормально, або може створювати сплески латентності залежно від диска і ядра.

Рішення: Якщо бачите періодичні латентні шторми, що корелюють з видаленнями — розгляньте вимкнення discard і використання запланованого fstrim.

Завдання 13: Підтвердіть підтримку discard і вирівнювання

cr0x@server:~$ lsblk -D -o NAME,DISC-GRAN,DISC-MAX,DISC-ZERO
NAME     DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1       512B       2T         0

Значення: Гранулярність і максимум discard мають значення. Якщо discard не підтримується (zeros), fstrim не допоможе і опція discard марна.

Рішення: Якщо не підтримується — перестаньте думати, що TRIM вас врятує. Дивіться в бік overprovisioning, write amplification і шаблонів навантаження.

Завдання 14: Запустіть контрольований fio тест латентності (не бенчмаркуйте продакшен-том БД прямо)

cr0x@server:~$ fio --name=randread --filename=/dev/nvme0n1 --direct=1 --ioengine=io_uring --iodepth=32 --rw=randread --bs=4k --numjobs=4 --time_based=1 --runtime=20 --group_reporting
randread: (groupid=0, jobs=4): err= 0: pid=1234: Tue Feb  4 12:00:00 2026
  read: IOPS=320k, BW=1250MiB/s (1310MB/s)(24.4GiB/20s)
  lat (usec): min=45, max=2200, avg=120.3, stdev=35.7

Значення: Це дає вам базову випадкову read IOPS і латентність. Якщо це жахливо на сирому пристрої — то це не ваша файлова система.

Рішення: Якщо fio показує, що пристрій швидкий, а ваш додаток повільний — дивіться нагору (файлова система, сторінка кешу, шаблон IO додатку).
Якщо fio теж повільний — продовжуйте розкопки в драйвері/чергах/шляху PCIe.

Завдання 15: Перевірте політику кешу записів (SATA/SAS)

cr0x@server:~$ hdparm -W /dev/sda
/dev/sda:
 write-caching =  1 (on)

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

Рішення: Якщо ви працюєте без PLP і вам важлива довговічність, будьте обережні. Якщо PLP є, а кеш відключений — увімкнення може дати безпечний виграш.

Жарт №1: Зберігання — єдине місце, де «воно працює» може означати «воно тихо руйнує ваш квартал».

Три корпоративні міні-історії (анонімно, правдоподібно й технічно коректно)

Міні-історія 1: Інцидент, спричинений неправильною припущенням

Команда мігрувала завантажений кластер метрик з старих SATA SSD на блискучі NVMe. Вони зробили розумні речі:
клонували образи ОС, перенесли монтування, перевірили SMART, запустили швидкий fio тест у стенді. Числа виглядали добре.
Потім продакшен зустрів 9 ранку, і система алертів почала дзвонити про «латентність диску > 50ms».

Припущення було простим: «NVMe це NVMe». Сервери мали M.2 диски, але вони були встановлені у carrier-картку,
яка могла маршрутизувати ці пристрої або як PCIe NVMe, або як SATA — залежно від налаштування BIOS, успадкованого від попередньої версії заліза.
Половина флоту погоджувала PCIe; інша половина з’являлася як SATA-пристрої під AHCI.

Схема симптомів була заплутана: деякі вузли були в порядку, деякі — жахливі, а навантаження було «рівномірно розподілене».
Балансувальник навантаження робив свою роботу. Просто балансував користувачів між двома різними світом зберігання.

Виправлення не було хитрим sysctl. Це була таблиця: серійні номери, мапінг до профілів BIOS, вікно обслуговування
і суворий «перевіряти транспорт при провізуванні». Після зміни латентність нормалізувалася одразу,
і команда отримала нагадування, що стандартні апаратні налаштування — не контракт.

Міні-історія 2: Оптимізація, що відгукнулась боком

Інженер з продуктивності помітив, що IO-планувальник на кількох хостах баз даних не встановлений послідовно.
Вони розгорнули зміну через udev-правила, щоб примусити mq-deadline усюди «для передбачуваної латентності».
Це добре проходило тести на невеликій групі, і розгортання продовжилося.

Через два дні OLTP-навантаження почало показувати періодичні паузи. Не постійну повільність — гірше.
Кожні кілька хвилин p99 латентність стрімко зростала, реплікація відставала, а потім все відновлювалося.
Метрики виглядали так, ніби система робить інтервальне тренування.

Корінь проблеми не в тому, що mq-deadline поганий. Він полягав у тому, що udev-правило застосувалося до device-mapper вузлів
та до підлеглих NVMe namespace непослідовно. Деякі томи опинилися з конфліктуючими планувальниками між шарами, і IO-шаблони взаємодіяли з вибуховою поведінкою TRIM на одній моделі диска.

Відкат відновив стабільність. Тривале виправлення було прозаїчнішим: встановлювати планувальник тільки на фізичні пристрої,
уникати встановлення на dm-* вузлах і окремо валідувати стратегію discard. І ще: ніколи не «стандартизувати» налаштування продуктивності
без перевірки класів пристроїв, до яких ви це застосовуєте.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Сервіс з великим навантаженням зберігання працював на VM з міксом локальних NVMe і мережевих томів.
SRE команда мала пункт у чек-листі деплойменту, над яким всі кепкували: «Занотуйте модель блочного пристрою, транспорт і прив’язку драйвера».
Це виглядало як паперова робота. Воно так і було.

Одного тижня оновлення образу хост-ОС змінило контролер віртуального зберігання за замовчуванням для підгрупи VM.
Вони все ще стартували. Все ще монтували. Все ще проходили перевірки здоров’я додатку.
Але хвостова латентність погіршилася, і сервіс почав скидати запити під піковим навантаженням.

Оскільки у них була нудна інвентаризація з минулого, вони могли швидко зробити diff «було добре» проти «зараз»:
той самий том, той самий гіпервізор, інший контролер і поведінка черг. Команда не витрачала два дні на звинувачення бази даних.
Вони ескалували у віртуалізаційну команду з доказами.

Виправлення полягало у відкаті вибору контролера, а потім тестуванні нового контролера правильно з реальним профілем навантаження.
Пункт чек-листа пережив, і люди, які над ним глузували, тихо припинили глузувати.

Жарт №2: Найшвидший спосіб покращити продуктивність зберігання — перестати «оптимізувати» її в п’ятницю.

Поширені помилки: симптоми → корінь проблеми → виправлення

1) Симптом: NVMe в бенчмарках швидкий, додаток усе ще повільний

Корінь: Додаток потрапляє на інший шлях (dm-crypt, мережева файлова система, multipath), ніж ваш бенчмарк, або забитий fsync/журналюванням.

Виправлення: Бенчмаркуйте фактичний блочний пристрій, що використовує файлова система (слідкуйте за ланцюжком lsblk), потім тестуйте з fio шаблонами, що імітують fsync та глибину черг.

2) Симптом: Пропускна здатність стримана до підозріло низьких значень, CPU переважно вільний

Корінь: Пристрій погодився на PCIe x1/низький Gen, або ви в режимі AHCI/SATA, або одна черга відправлення/завершення обмежує паралелізм.

Виправлення: Перевірте стан лінку lspci -vv, підтвердіть TRAN у lsblk, перевірте розподіл IRQ і кількість черг.

3) Симптом: Високе `await`, низьке `svctm`, %util близько 100%

Корінь: Запити чекають у програмних чергах, часто через обмежену глибину черги або погано закріплені переривання.

Виправлення: Перевірте /sys/block/*/queue/nr_requests, налаштування черг NVMe і /proc/interrupts. Спочатку виправте affinity/irqbalance.

4) Симптом: Випадкові стрибки латентності після видалень або компактів

Корінь: Онлайн discard/TRIM викликає синхронну роботу, або прошивка GC взаємодіє з вашим навантаженням.

Виправлення: Приберіть опцію монтування discard; заплануйте fstrim. Підтвердіть підтримку discard через lsblk -D.

5) Симптом: Multipath-пристрій повільніший, ніж один шлях

Корінь: Політика multipath не балансує, пріоритети шляхів нерівні, або поведінка черг, як queue_if_no_path, викликає паузи.

Виправлення: Перевірте multipath -ll. Встановіть відповідний селектор шляху (наприклад, service-time) і переконайтеся, що обидва шляхи несуть IO.

6) Симптом: «SSD повільний» лише всередині VM

Корінь: Емульований контролер, неправильний паравіртуальний драйвер, низькі обмеження черг або тротлінг на стороні хоста.

Виправлення: Перейдіть на virtio (або віртуальний NVMe) і підніміть налаштування черг де потрібно; перевірте, що гість бачить очікуваний транспорт/черги.

7) Симптом: Записи значно повільніші за зчитування, навіть на свіжих дисках

Корінь: Кеш запису вимкнений, хибні припущення про PLP або диск у консервативному енергетичному стані; іноді RAID-контролер змушує write-through.

Виправлення: Перевірте політику кешу (hdparm -W / інструменти контролера), перевірте стани енергозбереження і переконайтеся в наявності PLP, якщо вмикаєте write-back.

8) Симптом: Продуктивність погіршилася після «оновлення ядра»

Корінь: Змінені значення за замовчуванням: вибір планувальника, поведінка io_uring, параметри nvme_core або udev-правила, що були перезаписані tuned-профілями.

Виправлення: Зробіть diff значень у /sys/block/*/queue, перевірте tuned/udev і підтвердіть, що прив’язка драйвера залишилася тією самою.

Чек-листи / покроковий план

Покроково: діагностувати і безпечно виправити повільність через неправильний драйвер

Зробіть інвентар ланцюжка пристроїв.
Використайте lsblk і підтвердіть, чи файлова система сидить на сирому NVMe, dm-crypt, LVM, md або multipath.
Підтвердіть прив’язку драйвера.
Використовуйте readlink -f /sys/block/DEVICE/device/driver.
Якщо це не те, що ви очікуєте — зупиніться і з’ясуйте чому.
Підтвердіть транспорт і модель контролера.
Використовуйте lsblk -o TRAN, lsscsi -t і lspci для контролера пристрою.
Перевірте PCIe лінк (NVMe).
Використовуйте lspci -vv і шукайте зниження швидкості/ширини.
Виправте проблеми апаратного узгодження перш ніж займатися софтовим тюнінгом.
Перевірте налаштування черг і планувальник.
Прочитайте /sys/block/*/queue/scheduler і nr_requests.
Уникайте «широкомасштабних» (fleet-wide) перевизначень, якщо класи пристроїв різні.
Перевірте розподіл IRQ.
Використовуйте /proc/interrupts.
Якщо одне ядро обробляє всі завершення — виправте affinity і перевірте поведінку irqbalance.
Виміряйте перед змінами.
Використовуйте iostat -x і безпечний fio тест.
Зафіксуйте базові p50/p95/p99 латентності.
Змініть одну річ.
Зміни шляху драйвера/режиму контролера потребують вікна обслуговування. Зміни планувальника/affinity часто робляться вживу, але валідуйте обережно.
Перевірте після змін.
Повторіть fio та iostat перевірки, потім валідуйте з SLO додатку (хвостова латентність, час у черзі, кількість помилок).
Зробіть процес повторюваним.
Впровадьте в верифікацію при провізуванні: транспорт, прив’язка драйвера, PCIe лінк і налаштування черг мають перевірятися автоматично.

Операційний чек-лист: що додавати в тікет

lsblk -o NAME,MODEL,SIZE,ROTA,TYPE,TRAN,MOUNTPOINTS
readlink -f /sys/block/DEVICE/device/driver
lspci -vv фрагмент, що показує стан лінку (NVMe)
iostat -x 1 10 під час вікна інциденту
/proc/interrupts відфільтровано за зберіганням
Вивід multipath, якщо є: multipath -ll
Стан trim/discard: findmnt -no OPTIONS, lsblk -D

Поширені питання

1) Чи проблема «неправильний драйвер зберігання» — переважно Linux-річ?

Linux робить це видимим, бо ви можете інспектувати стек. Але цей клас проблем існує всюди:
неправильний режим контролера, шари емуляції, обмеження черг і політичні двигуни можуть нашкодити будь-якій ОС.

2) Якщо мій диск — `/dev/sda`, чи значить це, що це не NVMe?

На bare metal — так: NVMe namespaces показуються як /dev/nvme*. У VM або за деякими контролерами швидкий бекенд все ще може виглядати як SCSI-диск (/dev/sd*).
Головне — ідентифікувати реальний транспорт і ланцюжок драйверів.

3) Чи завжди потрібно використовувати IO-планувальник `none` для SSD?

Для NVMe none часто є правильним вибором. Для SATA SSD або коли є багатошарування (dm-crypt, md, multipath) mq-deadline може згладжувати латентність.
Не вгадуйте — вимірюйте на вашому навантаженні.

4) Чому зміна глибини черги іноді погіршує латентність?

Глибші черги можуть підвищити пропускну здатність, але збільшують час очікування для окремого IO, особливо при конкуренції.
Якщо ваш додаток піклується про хвостову латентність — «більше черги» може бути самопошкодженням.

5) Чи онлайн `discard` — погана практика?

Не завжди. Це залежить від прошивки пристрою, версії ядра і навантаження. Багато продакшенів надають перевагу періодичному fstrim,
бо це контролює, коли робота discard відбувається.

6) Мій NVMe лінк показує «downgraded». Це завжди апаратна проблема?

Зазвичай так. Налаштування BIOS, погані riser-и, проблеми з бекаплейном, неправильне прилягання або проблеми з живленням можуть спричинити відкат узгодження лінку.
Програмне забезпечення не виправить проблему фізичного рівня узгодження.

7) Чи може шифрування (dm-crypt) бути «помилкою драйвера»?

Шифрування — не помилка, але це шар з власними чергами і витратами CPU. Якщо ви бенчмаркували сирий NVMe і оголосили перемогу,
а потім монтуєте зашифрований том і дивуєтеся, куди поділися IOPS — це помилка вимірювання.

8) Як дізнатися, чи multipath допомагає чи шкодить?

Якщо у вас є резервні шляхи, multipath вартий наявності. Але перевірте, що він розподіляє IO як задумано і не серіалізує на один шлях.
Використовуйте multipath -ll плюс per-path iostat.

9) Яка найбезпечніша «перша зміна», коли підозрюю проблему драйвера/черг?

Почніть з спостереження: транспорт, прив’язка драйвера, стан лінку, розподіл IRQ, планувальник. Найбезпечніша зміна часто — виправлення дисбалансу IRQ
(affinity/irqbalance), бо це відкатно і не змінює формат на диску.

10) Чи може самої прошивки вистачити, щоб SSD став повільним?

Так — особливо через обробку станів живлення, поведінку GC і баги на межі випадків. Але розглядайте прошивку як частину стека:
не оновлюйте випадково, і не ігноруйте її, коли всі OS-рівневі перевірки чисті.

Висновок: практичні наступні кроки

Коли SSD повільний «без причини», припускайте, що причина є — ви просто ще не знайшли шар, який вам брешe.
Звичайний підозрюваний — не NAND. А шлях драйвера і модель черг, які ОС опинилася використовувати, часто через налаштування за замовчуванням,
спадщину або вибір віртуалізації.

Зробіть наступне:

На одному ураженому хості захопіть lsblk, прив’язку драйвера і (для NVMe) стан PCIe лінку.
Перевірте розподіл IRQ і налаштування черг/планувальника; виправте очевидне закріплення і невідповідності.
Запустіть контрольований fio тест на фактичному шляху пристрою, який використовує додаток (не на тому, який вам би хотілося бачити).
Якщо пристрій погодився на нижчий рівень (PCIe) або презентований через невірний режим контролера — заплануйте апаратне/BIOS-виправлення — не «налаштовуйте навколо» це.
Зафіксуйте перевірки у провізуванні, щоб вам ніколи не довелося дебажити це двічі.