Бенчмаркінг дискової підсистеми: де втрачається продуктивність
Дискова підсистема майже завжди виявляється тією ланкою, яка першою впирається в стелю, коли навантаження зростає.
База даних починає віддавати запити довше, черга накопичує необроблені повідомлення, віртуальні машини на спільному сховищі «підвисають» — і все це при тому, що процесор і пам'ять завантажені наполовину.
Бенчмаркінг дискової підсистеми потрібен не заради гарних цифр у звіті, а щоб відокремити реальне вузьке місце введення-виведення від симптомів, які на нього лише схожі.
Проблема в тому, що без вимірювань причину шукають навмання.
Адміністратор бачить зростання затримок операцій читання і запису, додає пам'яті, змінює параметри ядра, переносить сервіс на інший вузол — а деградація повертається через тиждень, бо корінь був в іншому: у вичерпанні черги на накопичувачі, у неправильному розмірі блоку, у тому, що профіль навантаження на запис не збігається з профілем, під який підбирали сховище.
Кожна така ітерація — це простій, втрачений час команди і ризик для сервісу, який весь цей час працює на межі.
Продуктивність дискової підсистеми не можна оцінити одним числом. Послідовне читання великими блоками, випадковий запис дрібними, змішане навантаження з переважанням читання — це три різних сценарії з різною поведінкою, і оптимізація під один легко погіршує два інших.
Тому коректний замір завжди починається з питання «який профіль у нашого реального навантаження», а не із запуску першого-ліпшого тесту.
Далі розбираємо, як це закривається: які сценарії відтворюємо, як знімаємо метрики затримок і пропускної здатності, і як за результатами відрізнити нестачу ресурсу сховища від помилки в конфігурації застосунку.
Що дає коректний замір: режими навантаження та метрики
Коректний замір починається з вибору профілю навантаження, а не із запуску першої-ліпшої команди. Послідовне читання блоками по кілька мегабайтів показує стелю пропускної здатності — це сценарій резервного копіювання та вивантаження великих файлів.
Випадковий доступ блоками по 4 КБ із глибиною черги 32 відтворює роботу бази даних: тут стелю задає не пропускна здатність, а затримка на операцію.
Профілі навантаження: що і навіщо міряти
- Послідовний доступ — великі блоки, один потік або кілька. Показує, скільки даних пройде під час копіювання, стримінгу, реплікації.
- Випадковий доступ — дрібні блоки, висока глибина черги. Показує поведінку під транзакційним навантаженням і при змішаному читанні-записі.
- Змішаний режим — частка запису 70/30 або 50/50. Найближче до реальної роботи сервісу, де читання і запис ідуть одночасно.
Метрики, за якими ухвалюють рішення
Пропускна здатність (МБ/с) відповідає на питання «чи встигне перенести дані за вікно обслуговування». Затримка — на 95-му і 99-му процентилі — відповідає на питання «чи не почнуть запити до бази впиратися в диск».
Середня затримка бреше: рідкісні, але тривалі операції тонуть у загальній кількості й не видно, а саме вони дають сплески відгуку застосунку. Тому дивимося на хвіст розподілу, а не на середнє.
Чим міряти: порівняння підходів
| Інструмент | Коли підходить | Обмеження |
|---|---|---|
| fio | Гнучкі профілі: задається розмір блока, глибина черги, частка запису, число потоків. Основний інструмент для відтворюваних замірів | Потребує акуратної конфігурації — неправильні параметри дають гарний, але безглуздий результат |
| bonnie++ | Швидка перевірка файлової системи та дискового вводу-виводу «з коробки» | Менше контролю над профілем, гірше підходить для точного порівняння конфігурацій |
| dd | Разовий замір послідовного запису і читання, перевірка «диск взагалі живий» | Не дає затримок і випадкового доступу, легко обманюється кешем |
Для відтворюваності наші інженери прогрівають кеш, фіксують розмір файлу більше за обсяг пам'яті, вимикають кешування на рівні файлової системи і проганяють кожен профіль кілька разів. Інакше розкид між запусками перекриває різницю між конфігураціями, і замір втрачає сенс.
Порівняння ведемо на одному й тому самому наборі параметрів — так видно ефект від зміни типу диска, налаштувань масиву або файлової системи, а не шум. Результати зводимо в таблицю «профіль — пропускна здатність — затримка p95/p99», за нею й ухвалюється рішення про конфігурацію.
fio
Як ми проводимо вимірювання: етапи інженерної роботи
Перш ніж запускати заміри, ми розбираємо задачу: який профіль навантаження важливий — випадкове читання дрібними блоками, послідовний запис великими, змішаний потік із переважанням читання.
Від цього залежить вибір інструменту та параметрів, інакше цифри виходять гарними, але до реальної роботи не належать. Далі фіксуємо цільову конфігурацію — тип носія, режим кешування, файлову систему, — щоб стенд повторював продакшн, а не абстрактне «залізо взагалі».
- Аудит задачі та постановка гіпотези. Збираємо вимоги застосунку: розмір блоку вводу-виводу, частка читання й запису, глибина черги, чутливість до затримки. Формулюємо, що саме перевіряємо — стелю пропускної здатності, поведінку під навантаженням або деградацію з часом.
- Підготовка стенда для замірів. Розгортаємо чисту конфігурацію, вимикаємо фонові процеси та зайвий кеш, вирівнюємо розділи, прогріваємо носій перед серією. Один і той самий сценарій проганяємо на різних налаштуваннях, змінюючи лише одну змінну за раз.
- Зняття профілю навантаження. Проганяємо серію замірів на кількох інструментах, щоб виключити помилку методики: один дає детальну картину щодо затримок, другий — стійкий потік, третій — швидку перевірку на послідовних операціях. Розбіжність між ними — сигнал переперевірити умови.
- Розбір результатів і пошук вузького місця. Дивимося не середні, а розподіл затримок: дев'яносто дев'ятий процентиль показує, що відчує користувач, тоді як середнє його приховує. Зіставляємо заміри з налаштуваннями файлової системи, планувальника та кешу.
- Перевірка рекомендацій повторним прогоном. Кожне налаштування підтверджуємо контрольним заміром на тому самому сценарії — інакше це здогад, а не висновок. Фіксуємо, який параметр дав приріст, а який виявився нейтральним.
- Передача звіту із замірами. Віддаємо таблиці за кожним сценарієм, графіки розподілу затримок, список змінених параметрів і очікуваний ефект. Окремо зазначаємо, які висновки переносяться на продакшн, а які прив'язані до стенда.
- Рекомендації щодо налаштування. Зводимо результат у конкретні правки конфігурації та порядок їх застосування, щоб команда могла впровадити їх без повторного розбору.
Такий порядок прибирає головну проблему замірів — коли цифри є, а рішення на їх основі ухвалити не можна. Опишіть вашу задачу та поточну конфігурацію — повернемося з оцінкою та планом робіт.
Чим синтетичний тест відрізняється від реального навантаження?
Синтетичний тест подає на диск заздалегідь заданий потік операцій: фіксований розмір блоку, глибину черги, частку читання й запису, відсутність конкуренції за ресурс.
Реальне навантаження так не виглядає — воно неоднорідне в часі, залежить від кешу файлової системи, від того, як застосунок групує запити, і від того, що відбувається на сусідніх шарах: мережа, база, планувальник.
Тому цифри зі звіту утиліти й поведінка бойової системи розходяться не тому, що інструмент бреше, а тому що вимірюють різне.
Ключове джерело розходження — кеш. Якщо тест читає файл, який уже лежить у сторінковому кеші, замір показує швидкість пам'яті, а не носія.
Коректний замір вимагає або прямого введення-виведення в обхід кешу, або попереднього скидання кешу перед кожним прогоном, інакше достовірність замірів падає до нуля.
Другий фактор — черги: глибина черги в тесті задається вручну, а в бою її формує число одночасних запитів від застосунків. Один і той самий носій на глибині черги 1 і на глибині 32 поводиться як два різних пристрої.
Третій шар — умови коректного порівняння. Порівнювати два варіанти зберігання можна, тільки якщо збігаються розмір блоку, частка читання й запису, глибина черги, спосіб обходу кешу та тривалість прогону. Зміна будь-якого параметра між замірами робить висновок недійсним.
Окремо варто пам'ятати про прогрів: перші секунди тесту носій і контролер ще виходять на режим, тому короткі прогони показують завищений або занижений результат.
Практичний висновок: синтетичний тест відповідає на питання «яка верхня межа цього носія за заданого профілю», а не «як система поведеться під навантаженням».
Він потрібен, щоб відсіяти явно невідповідні варіанти й зловити деградацію після змін, але рішення про конфігурацію ухвалюється за змішаним сценарієм, наближеним до профілю застосунку.
Ми будуємо такі сценарії за логами реальних операцій і тримаємо однакові умови між прогонами — тоді порівняння дає відповідь, яка підтверджується на бойовій системі.
Кейс: як вимірювання прибрали деградацію сховища
Кластер віртуалізації з шести вузлів обслуговував продуктовий контур: бази, кеш, черги. Скарги йшли хвилями — «ввечері все гальмує», але метрики процесора та пам'яті залишалися в нормі, тому проблему списували на застосунок.
Поки не зняли профіль введення-виведення на рівні томів: з'ясувалося, що пікові операції читання впираються в чергу дискового масиву, а затримка накопичувача зростає сходинками при досягненні певного рівня одночасних запитів.
Що показали вимірювання
Спочатку зняли базову лінію: послідовні та випадкові операції читання й запису при різному розмірі блоку, різній кількості одночасних потоків і глибині черги.
Прогони робили на порожньому томі та на бойовому, щоб побачити різницю між «паспортною» швидкістю та реальною картиною під навантаженням. Окремо перевірили профіль змішаного навантаження — частка читання до запису відповідала продакшену.
Картина виявилася нелінійною: до певної кількості одночасних операцій затримка трималася рівно, далі зростала в рази. Це і було джерело вечірніх провалів — застосунок збільшував паралелізм, а накопичувач відповідав чергою замість даних.
Що змінили
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Налаштування планувальника та глибини черги | Латентність зростає при паралелізмі | Не допомагає, якщо впирається у фізику носія |
| Розділення томів за профілем навантаження | Змішані читання та запис на одному масиві | Потребує перезбирання томів і міграції даних |
| Кеш запису на рівні контролера | Переважає запис | Ризик втрати даних без захищеного живлення |
| Заміна носіїв на швидкі | Вичерпано ресурс і запас за латентністю | Капітальні витрати, простій на міграцію |
Обрали комбінацію: розвели томи за профілем, налаштували планувальник під змішане навантаження та обмежили паралелізм на боці застосунку. Вимірювання повторювали після кожного кроку — щоб бачити внесок саме цієї зміни, а не сумарний ефект.
Результат
Затримка накопичувача під піковим навантаженням вирівнялася, розкид між мінімальним і максимальним часом відгуку скоротився в рази. Вечірні провали зникли як клас: вузьке місце перестало бути прихованим.
Побічний ефект — застосунок перестав «наздоганяти» чергу повторами, навантаження на кластер знизилося.
Методологію вимірювань зафіксували в регламенті: ті самі прогони тепер ідуть перед кожним розширенням сховища, і деградація ловиться на етапі планування, а не в проді.
Інструментарій — fio для профілів введення-виведення та bonnie++ для файлових операцій; зв'язка закриває і синтетику, і поведінку під реальним навантаженням.
Сумніви перед стартом: сумісність, доступи, відкат
Бенчмаркінг дискової підсистеми на бойовому сервері — законне питання: заміри створюють навантаження, а частина утиліт пише тестові файли прямо в робочу файлову систему. Ми не запускаємо заміри «в лоб» на продуктивному контурі.
Спочатку знімаємо профіль поточного навантаження, обираємо вікно мінімальної активності та підбираємо режим, за якого тест не конкурує з робочими процесами за дискову чергу.
Що якщо заміри все-таки зачеплять бойову систему?
Перед запуском фіксуємо точку повернення: знімок конфігурації, поточні параметри монтування та планувальника введення-виведення, список запущених сервісів. Тестові файли пишемо в окремий каталог з обмеженням за розміром і часом, а не поверх робочих даних.
Якщо навантаження виходить за узгоджений поріг — замір зупиняється, зміни відкочуються за заздалегідь описаним планом, сервіс повертається до початкового стану.
Що якщо потрібен доступ до продакшену? Працюємо за принципом мінімально необхідних прав: читання метрик і конфігурації, запуск утиліт у узгодженому вікні, без постійного доступу адміністратора. Усі дії логуються, доступ видається на час робіт і закривається після завершення.
Що якщо заміри покажуть деградацію? Це і є результат: звіт з профілем навантаження, вузькими місцями та рекомендаціями щодо налаштування — без змін у конфігурації до вашого погодження.
За підсумками робіт ви отримуєте на руки:
- скрипти запуску замірів із зафіксованими параметрами та зрозумілими порогами;
- профіль поточного навантаження та результати замірів у читабельному вигляді;
- план відкату змін із точками повернення;
- перелік виданих доступів і прав із порядком їх закриття;
- документацію щодо методики замірів, щоб повторити їх самостійно;
- рекомендації щодо налаштування дискової підсистеми з обґрунтуванням кожної зміни.
Опишіть задачу та поточний контур — повернемося з оцінкою та планом робіт, включно зі схемою безпечного проведення замірів.
