iostat та iotop: діагностика вузьких місць у системі зберігання даних Linux

Коли сервер Linux працює повільно, одним із перших місць, на які слід звернути увагу, є система зберігання даних. iostat показує, чи перевантажений диск; iotop показує, який процес спричиняє навантаження. У поєднанні вони дають відповідь на два важливі запитання: чи дійсно диск є вузьким місцем, і якщо так, то що його перевантажує? Ця публікація охоплює встановлення, як читати вихідні дані (включно з тим, де на сучасному обладнанні знаходиться показник iostat %util на сучасному обладнанні), а також робочий процес від виявлення симптомів до усунення проблеми.

Встановлення iostat та iotop

iostat входить до складу пакета sysstat; iotop поставляється окремо. Встановіть обидва:

# Debian/Ubuntu
sudo apt install sysstat iotop
 
# RHEL, AlmaLinux, Rocky, CentOS Stream
sudo dnf install sysstat iotop
 
# Arch
sudo pacman -S sysstat iotop

В Ubuntu sysstat постачається у вимкненому стані. Щоб зібрати фонові дані для подальшого аналізу за допомогою sar, відредагуйте /etc/default/sysstat, встановіть ENABLED="true"та перезапустіть службу:

sudo systemctl restart sysstat

iotop повинен працювати як root. У RHEL 9 та новіших версіях облік затримок за замовчуванням вимкнено, що залишає IO і SWAPIN . Увімкніть її за допомогою:

echo 1 | sudo tee /proc/sys/kernel/task_delayacct

Додайте kernel.task_delayacct = 1 до /etc/sysctl.conf , щоб зберегти налаштування після перезавантаження.

Читання виводу iostat

Запустіть iostat з розширеною статистикою та проігноруйте перший зразок, який показує лише середні значення з моменту завантаження:

iostat -xz 2

Прапор -x додає розширену статистику, -z приховує неактивні пристрої, а 2 оновлює дані кожні дві секунди. Важливі стовпці:

• await: середній час у мілісекундах на виконання запиту вводу-виводу, включаючи час очікування в черзі. Найважливіше число, коли користувачі скаржаться на повільність.
• r/s та w/s: IOPS читання та запису. У поєднанні з rkB/s та wkB/s вони показують, чи є ваше навантаження випадковим (високі показники IOPS, низька пропускна здатність) чи послідовним (низькі показники IOPS, висока пропускна здатність).
• aqu-sz: середня глибина черги. Для HDD будь-яке значення, що стабільно перевищує 1, означає, що диск не встигає.
• %util: відсоток часу, протягом якого пристрій мав принаймні один операційний вхід-вихід у процесі. Корисно для HDD, оманливе для NVMe (див. нижче).

Короткий довідник порогових значень:

Саме там, де знаходиться %util

%util — це показник, до якого більшість людей звертається в першу чергу, і на NVMe він активно вводить в оману. Ядро підраховує %util як «будь-який вхід/вихід, що виконується в даний момент», що підходить для обертового диска, який обробляє один запит за раз, але не має сенсу для пристроїв NVMe, які обробляють тисячі запитів паралельно через апаратні черги. Диск NVMe може показувати 100% %util , працюючи на 5% своєї реальної потужності.

У випадку з NVMe довіряйте r_await, w_await, а aqu-sz замість цього. Якщо r_await залишається менше 1 мс, а глибина черги значно нижча за глибину апаратної черги пристрою (часто 1024 або більше), диск насправді не перевантажений, незалежно від того, що %util каже.

Щоб переглянути швидкість NVMe в МБ/с, а не в кБ/с:

iostat -xm 1

Для довготривалого збору даних ви можете пізніше співвіднести їх із журналами додатків:

iostat -x -t 5 720 > /var/log/iostat.log

Це зчитування кожні 5 секунд протягом години. sar з того ж пакету sysstat надає еквівалентні дані з постійним історичним зберіганням і є кращим вибором для постійного моніторингу.

Підтвердження за допомогою CPU iowait

Якщо iostat показує навантаження на сховище, перевірте це за допомогою %iowait колонкою в зведеній інформації про ЦП у верхній частині того ж виводу. Тривале %iowait показник вище 15–20% разом із високим await підтверджує, що вузьким місцем є система зберігання даних. Якщо %iowait високе, але await виглядає нормально, запустіть vmstat 1 і перевірте si та so . Не нульова активність обміну означає, що ви обмежені пам'яттю, а трафік диска — це пейджинг, а не введення-виведення додатка.

Аналіз виводу iotop

Як тільки iostat підтвердить наявність вузького місця в системі зберігання даних, iotop вкаже, який саме процес є його причиною. Почніть з:

sudo iotop -o

Прапор -o приховує неактивні процеси, залишаючи лише ті, що активно виконують операції вводу-виводу. Стовпці, на які слід звернути увагу:

• DISK READ / DISK WRITE: пропускна здатність у реальному часі для кожного процесу. Дозволяє виявити процеси, що споживають найбільше ресурсів.
• IO: відсоток часу, протягом якого процес заблокований на введенні-виведенні. Процес, що записує лише 50 кБ/с, може показувати 99% IO, якщо він виконує дрібні синхронні fsync() виклики. Цей стовпець має більше значення, ніж суто пропускна здатність.
• SWAPIN: відсоток часу очікування на сторінки підкачки. Не нульове значення тут означає, що система використовує підкачку, і ваша «проблема зі сховищем» насправді є проблемою пам'яті.

Для багатопотокових додатків (MySQL, PostgreSQL, навантаження на Java) об'єднайте потоки назад у процеси за допомогою -P, і додайте -a для накопичення підсумків з моменту запуску iotop:

sudo iotop -oPa

Флаг -a — це трюк для виявлення імпульсних навантажень, таких як завдання резервного копіювання, які виконуються лише протягом кількох секунд за раз і які інакше було б важко помітити в режимі реального часу.

Для автоматичного логування під час нічних вікон, коли ніхто не стежить:

sudo iotop -botqq -d 10 > /var/log/iotop.log

Це записує неінтерактивний знімок кожні 10 секунд. Поєднайте це з часовими мітками з ваших завдань резервного копіювання або cron, щоб знайти винуватця після того, як все відбулося.

Діагностичний робочий процес

Більшість досліджень дискового вводу-виводу проходять за однаковим алгоритмом:

1. iostat -xz 2 щоб підтвердити, що диск дійсно є вузьким місцем. Перегляньте await, aqu-sz, і %iowait. Якщо ці показники в нормі, проблема не в сховищі, і вам слід шукати її зовсім в іншому місці.
2. iotop -oPa щоб знайти процес, який спричиняє навантаження. Звертайте увагу більше на стовпець вводу-виводу, ніж на стовпець пропускної здатності. Найгіршими порушниками часто є програми, що виконують багато дрібних синхронних записів, а не ті, що переміщують найбільшу кількість байтів.
3. lsof -p <pid> щоб побачити, з якими файлами працює цей процес. Зазвичай це одразу визначає тип навантаження: журнал попереднього запису бази даних, файл журналу програми, точка монтування резервної копії, тимчасовий файл.

Два шаблони, про які варто знати.

Якщо ви бачите потоки ядра, такі як jbd2/... (журнал ext4) або txg_sync (ZFS) у верхній частині списку записувачів iotop, вони реагують на записи від інших процесів, а не ініціюють їх. Процес у просторі користувача, що спричиняє трафік журналу, є фактичною причиною; продовжуйте пошук.

На VPS високий await з низьким %util — це класичний сигнал про «галасливого сусіда». Інший орендар монополізує спільне сховище, і ваші операції вводу-виводу стоять у черзі на стороні гіпервізора, а не на вашому віртуальному диску. Ви можете підтвердити, але не виправити це зсередини гостьової системи; рішенням є або звернення до провайдера, або перехід на сервер з ізольованим сховищем.

Усунення типових вузьких місць вводу-виводу

Як тільки ви з’ясуєте, що саме навантажує диск, усунути проблему зазвичай не складно.

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

ionice -c 3 -p <pid>
sudo ionice -c 3 rsync -a /data /backup

Перша форма змінює запущений процес; друга запускає новий, який вже знаходиться в класі простою. У iotop ви можете інтерактивно змінити пріоритет запущеного процесу, натиснувши i.

Перемістіть активні робочі навантаження на швидше сховище. Якщо iostat показує, що диск SATA перевантажений записом даних бази даних, а в тому ж корпусі є NVMe, що простоює, перемістіть каталог даних бази даних. Різниця в IOPS на кілька порядків робить це найефективнішим доступним рішенням.

Встановіть правильний планувальник вводу-виводу. Сучасні ядра мають розумні налаштування за замовчуванням, але варто перевірити. Для NVMe та SSD встановіть планувальник на none. Пристрій краще обробляє черги на апаратному рівні, ніж ядро:

echo none > /sys/block/nvme0n1/queue/scheduler

Для HDD, що обробляють змішані навантаження, mq-deadline зазвичай вибирають

Змонтуйте з опцією noatime. Кожне читання за замовчуванням оновлює мітку часу останнього доступу до файлу, генеруючи запис для кожного читання. У файлових системах з великим обсягом читання це зайвий ввід-вивід. Додайте noatime до опцій монтування в /etc/fstab:

UUID=... /data ext4 defaults,noatime 0 2

Налаштуйте writeback для імпульсних записів. На серверах з великим об'ємом оперативної пам'яті, стандартні порогові значення для брудних сторінок дозволяють кешу сторінок накопичувати гігабайти незаписаних даних, а потім скидати їх одним великим пакетом. Зменшіть порогові значення в /etc/sysctl.conf , щоб вирівняти це:

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

Сам диск зазвичай не є проблемою. Коли iostat показує високі показники IOPS і низьку пропускну здатність, робоче навантаження виконує випадкові операції вводу-виводу з даними, які могли б бути послідовними, або виконує багато дрібних записів, які можна було б об'єднати в пакети. Перевірте програму, перш ніж звинувачувати апаратне забезпечення.

Якщо ви виконуєте робочі навантаження, що вимагають значних обсягів пам'яті, на сервері, де мережа може випереджати диск, виділені сервери FDC на базі NVMe надають вам запас потужності для продуктивного застосування налаштувань, описаних вище.