Бенчмарк виділеного сервера: fio, sysbench, iperf3
Диски вимірюють утилітою fio з прямим вводом-виводом і профілем, схожим на ваше навантаження; процесор і пам'ять — sysbench; канал — iperf3 до вузла в тій самій країні. Заміри роблять до перенесення проєкту, на порожньому сервері, і зберігають як еталон: без базової цифри будь-яка майбутня скарга на «сервер гальмує» нерозв'язна.
fioбез--direct=1вимірює сторінковий кеш ядра і показує фантастичні числа, не пов'язані з диском.- Тестовий файл має бути більшим за обсяг оперативної пам'яті щонайменше вдвічі, інакше дані осядуть у кеші.
- Випадковий запис блоком 4k — єдина цифра, що передбачає поведінку СУБД.
Підготовка: що зробити до першого тесту
Перевірте, що масив не відновлюється, диски не перегріті, а на сервері немає стороннього навантаження. Усе це спотворює результат сильніше, ніж різниця між моделями накопичувачів.
# Debian/Ubuntu
apt-get install -y fio sysbench iperf3 ioping hdparm
# RHEL, AlmaLinux, Rocky
dnf install -y epel-release
dnf install -y fio sysbench iperf3 ioping hdparm
# масив не в ребілді і не деградував
cat /proc/mdstat
Диски: fio
Чотири профілі закривають практично всі задачі. Випадкове читання і запис блоком 4k моделюють базу даних, послідовні — резервне копіювання і віддачу відео.
# випадкове читання 4k, глибина черги 32
fio --name=randread --filename=/mnt/test/fio.tmp --size=32G \
--rw=randread --bs=4k --iodepth=32 --numjobs=4 --direct=1 \
--ioengine=libaio --runtime=120 --time_based --group_reporting
# випадковий запис 4k — головна цифра для СУБД
fio --name=randwrite --filename=/mnt/test/fio.tmp --size=32G \
--rw=randwrite --bs=4k --iodepth=32 --numjobs=4 --direct=1 \
--ioengine=libaio --runtime=120 --time_based --group_reporting
# змішане навантаження 70/30 зі звітом за затримками
fio --name=mixed --filename=/mnt/test/fio.tmp --size=32G \
--rw=randrw --rwmixread=70 --bs=4k --iodepth=16 --numjobs=4 \
--direct=1 --ioengine=libaio --runtime=180 --time_based \
--group_reporting --percentile_list=50:95:99:99.9 2>&1 | tee fio-mixed.log
Дивіться не на середню швидкість, а на IOPS і на перцентилі затримки. Середня затримка 0,3 мс при 99-му перцентилі 40 мс означає регулярні підвисання, які користувач помітить, а середнє — ні. Швидкий контроль затримки без навантаження дає ioping -c 20 /mnt/test.
Процесор і пам'ять: sysbench
sysbench вимірює обчислення на цілих числах і пропускну здатність пам'яті. Для багатоядерних Xeon запускайте стільки потоків, скільки логічних ядер показує nproc.
# один потік: порівняння продуктивності на ядро
sysbench cpu --cpu-max-prime=20000 --threads=1 --time=60 run
# усі ядра
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) --time=60 run
# пропускна здатність пам'яті на запис
sysbench memory --memory-block-size=1M --memory-total-size=100G \
--memory-oper=write --threads=$(nproc) run
Канал: iperf3
Канал міряють до публічного сервера iperf3 у тій самій країні, що й майданчик. Один потік майже ніколи не вибирає гігабіт, тому запускають 8 і більше паралельних з'єднань.
# прийом: 8 потоків, 30 секунд
iperf3 -c SERVER -P 8 -t 30
# віддача з сервера у ваш бік
iperf3 -c SERVER -P 8 -t 30 -R
Отримане число звіряйте з характеристикою тарифу: на виділених серверах ZevsHost у Німеччині та Франції всі конфігурації йдуть на 1 Гбіт/с без ліміту, у Dedicated Start US гігабіт із квотою 30 ТБ, у Pro US та Enterprise US — 1 Гбіт/с без ліміту. Що означають unlimited і ліміт у 30 ТБ, розібрано у статті про канал сервера і трафік.
Що чим вимірювати
| Підсистема | Інструмент | Ключова метрика | Коли цифра погана |
|---|---|---|---|
| Диск, випадкове навантаження | fio randread/randwrite 4k | IOPS і затримка на 99-му перцентилі | NVMe віддає менше ніж 50 000 IOPS на читання |
| CPU, один потік | sysbench cpu --threads=1 | events per second | розбіжність з еталоном понад 15% |
| CPU, усі ядра | sysbench cpu --threads=nproc | events per second | масштабування гірше за 60% від числа ядер |
| Канал | iperf3 -P 8 | Гбіт/с в обидва боки | менше ніж 80% заявленої смуги |
Параметр --filename у fio приймає і блоковий пристрій. Вказавши --filename=/dev/sdb з профілем запису, ви затрете розділи і дані на цьому диску без жодного запитання, а на дзеркалі зміна поїде одразу на обидва накопичувачі. Завжди тестуйте через файл усередині змонтованої файлової системи: mkdir -p /mnt/test і --filename=/mnt/test/fio.tmp. Друге джерело сміттєвих цифр — тест поверх ребілду, що триває, або живого продакшену: перед запуском переконайтеся, що cat /proc/mdstat не містить рядка recovery, а vmstat 1 5 показує id близько 100. Як влаштований ребілд, описано у статті про заміну диска в масиві.
Як тлумачити результат
Цифри читають у порівнянні з еталоном тієї самої машини.
- Просідання випадкового запису в рази при нормальному читанні — зазвичай кеш контролера пішов у write-through або SSD вичерпав SLC-буфер.
- CPU в один потік нижче за еталон при нормальному багатопотоковому — увімкнене енергозбереження або обмеження частоти в прошивці.
Заміри зручно знімати одразу під час приймання виділеного сервера і складати в той самий файл, що й конфігурацію. Розбір вузьких місць за підсистемами продовжує стаття про профілювання продуктивності Linux.
Коротко
- fio завжди з
--direct=1і файлом удвічі більшим за обсяг оперативної пам'яті. - Головна дискова метрика для бази даних — IOPS на випадковому записі 4k і 99-й перцентиль затримки.
- Бенчмарк без збереженого еталона втрачає сенс: знімайте базові значення на порожньому сервері.
Часті питання
Чи обов'язково перевіряти усі три складники — диск, процесор і канал — чи досить одного бенчмарку?
Немає сенсу обмежуватися одним заміром: диск, процесор і мережевий канал — незалежні одна від одної підсистеми, і вузьке місце здатне опинитися у будь-якій з них. Сайт однаково гальмує і через брак IOPS на диску, і через слабкий один потік процесора, і через канал, що не дотягує до заявленої смуги, тому еталон знімають одразу за усіма трьома.
Чи можна запускати fio і sysbench одночасно з робочим навантаженням на сервері?
Краще не запускати: стороннє навантаження спотворює цифри сильніше, ніж різниця між моделями заліза, і результат перестає бути порівнянним з майбутнім еталоном. Перед тестом варто переконатися, що масив не в ребілді, диски не перегріті, а процесор простоює, інакше fio і sysbench покажуть стан боротьби за ресурси, а не реальні можливості сервера.
Що робити, якщо iperf3 показує швидкість помітно нижчу за заявлену в тарифі?
Перш за усе перевірте, що тест іде через декілька паралельних потоків і до сервера iperf3 у тій самій країні, що і сам майданчик — один потік майже ніколи не вибирає усю смугу. Якщо і тоді цифра помітно відстає від заявленої в тарифі, варто звернутися у підтримку з журналом тесту, а не повторювати замір в одиночному потоці ще раз.
Як часто варто повторювати бенчмарк після приймання сервера?
Жорсткого правила немає, та розумно повторити замір після перенесення проєкту під реальним навантаженням, а згодом — за будь-якої скарги на повільну роботу, звіряючи нові цифри з еталоном порожнього сервера. Без збереженого початкового результату таке порівняння неможливе, тому саме еталон, знятий на самому початку, робить повторні тести осмисленими.