Як правильно протестувати VPS: yabs.sh, fio, sysbench

Що означає тестування VPS

Під час тестування VPS вимірюють чотири показники: швидкість роботи одного ядра CPU, пропускну здатність пам’яті, кількість малих довільних операцій диска, які сховище виконує за секунду, і пропускну здатність мережевого з’єднання. Один запуск yabs.sh дає всі чотири показники приблизно за десять хвилин. Інтерпретувати результат складніше, оскільки VPS (віртуальний приватний сервер) використовує фізичне обладнання спільно з іншими клієнтами. Тому той самий сервер може показати одне значення о 03:00 і зовсім інше о 20:00.

Спочатку запустіть yabs.sh, щоб швидко оцінити систему, а потім вручну запустіть інструменти, які він використовує. Самостійний запуск дає змогу змінити один прапорець, простежити, як змінюється показник, і зрозуміти, що саме він вимірює. Виконуйте це після налаштування сервера, а не до нього. Спочатку виконайте кроки з розділу перші десять хвилин на новому VPS, оскільки сервер, який ще встановлює свій перший набір оновлень, показує неточні результати тестування з причин, не пов’язаних з обладнанням.

Перевірте машину, перш ніж вимірювати її

Половина кожного ненадійного бенчмарку припадає на машину, яку автор не зрозумів.

nproc
lscpu | grep -E 'Model name|Hypervisor|Thread'
free -h
df -hT /
uname -r
systemd-detect-virt

Hypervisor vendor: KVM означає повну віртуалізацію, тому ви використовуєте власне ядро. systemd-detect-virt із виведенням lxc або openvz означає контейнерну віртуалізацію: ви використовуєте спільне ядро хоста, а обмеження CPU та пам’яті задаються параметрами cgroup (control group), а не віртуальним обладнанням. У системі з cgroup v2 ліміт CPU можна прочитати безпосередньо.

cat /sys/fs/cgroup/cpu.max

max 100000 означає, що квоти немає. 200000 100000 означає, що можна використовувати 200000 мікросекунд CPU у кожному періоді тривалістю 100000 мікросекунд, тобто квоту на два ядра. План, у якому заявлено 4 vCPU, але квота становить два ядра, ніколи не покаже результат на рівні чотирьох ядер, і жоден інструмент бенчмаркінгу не виведе рядок із поясненням причини.

df -hT / важливий з іншої причини: стовпець Type. Якщо в ньому вказано overlay, ви перебуваєте всередині контейнера, і наведений нижче тест диска потребує змін. Зверніть на це увагу зараз.

Постійно відстежуйте час, викрадений гіпервізором

Викрадений час — це частка часу, коли ваш віртуальний процесор був готовий до виконання, але гіпервізор передав фізичне ядро іншому користувачу. Це найкорисніший окремий показник, який дає змогу визначити, що причина пов’язана із сусідніми віртуальними машинами, а не з апаратним забезпеченням.

vmstat 1 10

Праворуч переглядайте стовпець st. Стабільні значення 0 або 1 є нормальними. Тривалі значення понад 5 означають, що в цей момент на хості недостатньо ресурсів для всіх віртуальних машин. Тому всі зафіксовані в цей період показники CPU будуть заниженими не з вини вашої машини. top показує те саме значення, що й %st у рядку CPU. Під час тестування продуктивності запустіть vmstat 1 у другому сеансі SSH і записуйте показник викраденого часу поруч із кожним результатом.

Почніть із yabs.sh

yabs.sh (Yet Another Bench Script) — це shell-скрипт, який завантажує статичні бінарні файли fio, iperf3 і Geekbench, запускає їх і виводить один зведений результат. Це стандартний формат для обговорення результатів тестування VPS, тому вивід yabs — найшвидший спосіб порівняти результати з іншими.

Власна однорядкова форма проєкту має такий вигляд.

curl -sL yabs.sh | bash

Ця команда передає в shell усе, що URL повертає на цей момент. Спочатку завантажте скрипт і перегляньте його, а потім запустіть.

curl -sLo yabs.sh https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh
less yabs.sh
bash yabs.sh

Прапорці вказують після -s -- під час передавання через pipe або безпосередньо після імені файлу під час запуску локальної копії. Корисні прапорці: -f пропускає тест диска, -i пропускає мережевий тест, -g пропускає Geekbench, -r скорочує кількість розташувань iperf3 до двох, -j виводить результати у форматі JSON, а -w results.json записує цей JSON у файл.

bash yabs.sh -r -w yabs-run1.json

Перед першим запуском потрібно знати дві речі. Geekbench завантажує результат і виводить загальнодоступний URL на browser.geekbench.com, тому будь-хто, хто має це посилання, може переглянути модель процесора та результати. -g повністю пропускає цей тест. По-друге, етап iperf3 передає реальний мережевий трафік до серверів у кількох регіонах, і цей трафік враховується у вашому щомісячному ліміті. У каналі зі швидкістю 1 Gbit/s повний мережевий етап може передати десятки гігабайт, тому за невеликого ліміту використовуйте -r, а за тарифікації трафіку — -i.

Що означає кожна частина виводу yabs

Розділ диска запускає fio із співвідношенням читання та запису 50/50 для чотирьох розмірів блоків: 4k, 64k, 512k і 1m. Для кожного розміру він показує IOPS (операції введення-виведення за секунду) і пропускну здатність. Рядок 4k важливий для баз даних, поштових серверів і всіх систем, де виконується багато малих операцій запису, оскільки більшість серверних операцій введення-виведення мають малий розмір і виконуються фрагментовано. Рядок 1m важливий для резервного копіювання та роботи з відео, де передаються довгі послідовності байтів.

Мережевий розділ запускає iperf3 проти загальнодоступних серверів у кількох регіонах, в обох напрямках і з використанням паралельних потоків. Розглядайте низький показник як привід для перевірки, а не як остаточний висновок, оскільки загальнодоступні сервери iperf3 використовуються спільно та часто перевантажені. Тому низький результат може бути спричинений віддаленою стороною.

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

Диск: запустіть fio самостійно

fio (flexible IO tester) — це інструмент, який використовується в розділі yabs про диски. Якщо запускати його безпосередньо, параметри починають мати практичне значення.

sudo apt update && sudo apt install -y fio sysbench iperf3

Тест довільного читання блоками 4k із глибиною черги 32 у файловій системі, яка вас справді цікавить:

fio --name=randread4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randread --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting

Рядок підсумку, який потрібно знайти у виводі, має такий вигляд.

read: IOPS=184k, BW=719MiB/s (754MB/s)(42.1GiB/60001msec)

Нижче fio виводить блок clat percentiles. Варто наводити значення 99.00-го перцентиля, оскільки воно показує, скільки чекало найдовше одне з кожних ста запитів. Середня затримка приховує саме ті затримки, які помічає користувач.

• --direct=1 відкриває файл із параметром O_DIRECT, тому операції читання обходять кеш сторінок ядра. Без цього під час другого проходу файлом розміром 2G на машині з 8G RAM дані зчитуються з пам’яті, і fio показує мільйони IOPS. Це реальне значення, але воно характеризує пам’ять.
• --ioengine=libaio надсилає асинхронні запити, завдяки чому --iodepth=32 може одночасно обробляти 32 запити. Із синхронним рушієм, таким як psync, значення iodepth понад 1 нічого не змінює, тому запити вимірюються по одному.
• --time_based --runtime=60 запускає тест на фіксовані 60 секунд, а не на фіксований обсяг роботи. Тому швидкий і повільний диски працюють однаковий час, а порівняння залишається коректним.
• --size=2G задає розмір тестового файлу. Він має бути більшим за обсяг будь-якого кешу на шляху передавання даних. Спочатку перевірте, чи достатньо вільного місця.

Для довільного запису використовуйте ту саму команду з --rw=randwrite. Запустіть тест окремо, а потім видаліть файл.

fio --name=randwrite4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randwrite --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting
rm -f ./fio-testfile

Для суміші операцій, ближчої до реального мережевого трафіку, використовуйте --rw=randrw --rwmixread=70. Тип сховища, на якому працює система, впливає на ці результати сильніше, ніж будь-який параметр. Цю різницю розглянуто в матеріалі про відмінності між NVMe та SATA SSD у VPS.

Коли fio завершується з помилкою Unknown error -1

Прямий ввід-вивід доступний не в кожній файловій системі. overlay, файловій системі, яку Docker стандартно надає контейнеру, а також кількох мережевих файлових системах не підтримують O_DIRECT. Тому libaio надсилає запит, який ядро не може виконати, і fio припиняє роботу:

fio: io_u error on file ./fio-testfile: Unknown error -1: read offset=0, buflen=4096
fio: pid=1234, err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1

Спочатку виконайте df -hT .. Якщо у стовпці Type зазначено overlay, спрямуйте --filename до шляху на реальному сховищі, наприклад до змонтованого через bind mount тому, або запустіть fio на хості, а не в контейнері. Якщо доступу до реального сховища немає, запуск із буферизованим синхронним вводом-виводом принаймні підтвердить правильність самої команди.

fio --name=randread4k-buffered --filename=./fio-testfile --size=256M --bs=4k \
  --rw=randread --ioengine=psync --direct=0 --numjobs=1 \
  --runtime=15 --time_based --group_reporting
rm -f ./fio-testfile

Коректно інтерпретуйте результати цього запуску. Після першого проходу файл розміром 256M залишається в кеші сторінок, тому показник IOPS описує швидкодію RAM. Використовуйте цей запуск, щоб перевірити, що fio встановлено, а прапорці розпізнаються. Не подавайте цей показник як результат для диска.

Чому dd не є тестом продуктивності диска

dd часто згадують у темах про VPS. Він відповідає на одне вузьке запитання.

dd if=/dev/zero of=./ddtest bs=1M count=1024 oflag=direct conv=fdatasync
rm -f ./ddtest

Це вимірює послідовну швидкість запису в одному потоці, коли одночасно виконується один запит. Це прийнятна базова перевірка. Вона нічого не показує про випадкові операції вводу-виводу та про те, що відбувається, коли одночасно надходять 32 запити. Якщо прибрати oflag=direct, переважно вимірюється швидкість, з якою ваше ядро приймає операції запису в пам’ять. Саме тому значення dd, наведені у дописах на форумах, часто є абсурдними.

CPU: sysbench cpu

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

Основним показником є events per second. Спочатку запустіть тест в одному потоці. Це значення визначає, наскільки швидко завершується один PHP-запит або одне завдання компіляції. Воно найбільше відрізняється між хостами з однаковою ціною. Потім запустіть тест з усіма потоками. Це покаже, чи є ваші vCPU окремими ядрами, чи частинами одного ядра.

Важливо розуміти, що саме вимірює цей тест: sysbench cpu багаторазово знаходить прості числа, використовуючи 64-бітову цілочислову арифметику. Він не створює навантаження на пропускну здатність пам’яті, векторні блоки або кеш способом, подібним до реального робочого навантаження. Тому він добре підходить для порівняння двох хостів, але погано прогнозує роботу вашого застосунку.

Ubuntu 24.04 постачається із sysbench 1.0.20, де назва тесту вказується першою. Якщо скопіювати команду з --test=cpu зі старої публікації, буде отримано WARNING: the --test option is deprecated. Результати sysbench 0.4 і sysbench 1.0 взагалі не можна порівнювати. Тому не порівнюйте власний результат із опублікованим значенням, якщо для нього не вказано версію.

Пам’ять: sysbench memory

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write --threads=1 run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read --threads=1 run

Результат наведено в MiB/sec. На кожній машині швидкість читання вища за швидкість запису. Залишайте --memory-block-size рівним 1M і використовуйте це саме значення на всіх порівнюваних хостах. За значення 1K результат різко зменшується, оскільки накладні витрати на одну операцію виникають у тисячу разів частіше. У результаті вимірюється вартість циклу, а не пропускна здатність пам’яті. Це прапорець, значення якого найчастіше не узгоджується в опублікованих результатах тестування пам’яті.

Мережа: iperf3

Надійний спосіб перевірити пропускну здатність — виконати тест із другим комп’ютером, яким ви керуєте. Так ви знаєте, що відбувається на обох кінцях з’єднання.

На віддаленому комп’ютері:

iperf3 -s

Ця команда прослуховує TCP-порт 5201. Відкрийте порт лише для адреси, з якої виконуєте тест, і закрийте його після завершення. У розділі Основні правила брандмауера ufw на VPS описано відповідний синтаксис.

На VPS, який тестується:

iperf3 -c 203.0.113.10 -t 30
iperf3 -c 203.0.113.10 -t 30 -R
iperf3 -c 203.0.113.10 -t 30 -P 8

Перша команда вимірює вихідний трафік із машини, яку тестують. -R змінює напрямок і вимірює вхідний трафік. -P 8 відкриває вісім паралельних потоків.

Запустіть і тест з одним потоком, і паралельний варіант, оскільки вони відповідають на різні запитання. Одне TCP-з’єднання може передавати лише такий обсяг непідтверджених даних, який дозволяє його вікно, тому його гранична швидкість приблизно дорівнює розміру вікна, поділеному на час проходження сигналу туди й назад. За затримки 80 ms і вікна 4 MB це обмеження становить приблизно 400 Mbit/s, незалежно від фактичної швидкості каналу. Результат для одного потоку показує швидкість, яку отримає одне завантаження. Результат для паралельних потоків показує пропускну здатність каналу.

Під час тесту стежте за доступним обсягом трафіку. За 30 секунд на швидкості 1 Gbit/s передається приблизно 3.75 GB, а тест потрібно буде виконати кілька разів у кожному напрямку.

Еталонні показники та інтерпретація власних результатів

[
  {
    "device": "Local NVMe",
    "iops_4k_read": "180,000"
  },
  {
    "device": "Local SATA SSD",
    "iops_4k_read": "90,000"
  },
  {
    "device": "Network block",
    "iops_4k_read": "12,000"
  },
  {
    "device": "Spinning disk",
    "iops_4k_read": "180"
  }
]

У опублікованих результатах локальний том NVMe зазвичай показує близько 180,000 IOPS для довільного читання блоками 4k. Локальний SSD SATA зазвичай показує близько 90,000. Мережеве блочне сховище, де кожен запит проходить через мережу, перш ніж досягти диска, зазвичай показує близько 12,000, а механічний диск забезпечує приблизно 180, оскільки для кожного довільного запиту переміщує фізичну головку.

Це типові опубліковані показники для кожного класу сховищ, а не результати вимірювань на одному хості. Використовуйте їх лише для однієї мети: перевірити, чи має ваш результат правильний порядок величини. Якщо план, заявлений як NVMe, показує під час тестування кілька тисяч IOPS для блоків 4k, спочатку перевірте, чи було ввімкнено --direct=1. Якщо так, то сховище або не відповідає опису на сторінці продукту, або ви використовуєте його спільно з дуже завантаженим сусіднім клієнтом.

Чому один запуск не є бенчмарком

Один результат — це знімок однієї хвилини на спільній машині. Вважайте його однією вибіркою.

• Запускайте кожен тест щонайменше п’ять разів у різні години та щонайменше у два різні дні. Зберігайте медіану та розкид. Результат без указаного розкиду є маркетинговим показником.
• Записуйте steal time поруч із кожним запуском. Відкидайте запуски, під час яких st мав високе значення, або принаймні зазначайте це.
• Запускайте тест диска з двома значеннями тривалості. Багато тарифів надають burst-ліміт IOPS, який з часом відновлюється, тому 60-секундний запуск fio вимірює burst, тоді як --runtime=600 вимірює мінімальну продуктивність. Саме її ви отримуєте в несприятливий день.
• Переконайтеся, що нічого іншого не запущено. Запуск unattended-upgrades транзакції apt посеред тесту CPU коштує вам реальних балів, а виконання ps -e -o comm= | grep -E 'apt|dpkg' перед кожним запуском займає секунду.
• Змінюйте лише одну змінну за раз. Різні версії інструментів, розміри блоків або кількість потоків дають числа, які не можна порівнювати, хоч би наскільки схожими вони здавалися.

Порівнюючи двох провайдерів, запускайте тести в ту саму годину того самого дня. Інакше ви вимірюєте час доби.

Спочатку протестуйте власне робоче навантаження

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

time tar -czf /tmp/bench.tgz /usr/share
rm -f /tmp/bench.tgz

Ця операція стискає кілька сотень мегабайтів, тому одночасно навантажує процесор і диск. Результат змінюється, якщо змінюється будь-який із них. Попередження Removing leading / from member names є нормальним. Ще краще виміряти час власної збірки, власного найповільнішого запиту або власного рендерингу сторінки. Якщо збірка триває 4 хвилини на одному хості та 7 на іншому, це остаточно відповідає на запитання, незалежно від оцінки Geekbench. Це також вимірювання, яке показує, коли збільшення ресурсів машини перестає бути виправданим за витратами. Це варто знати до того, як ви прочитаєте скільки насправді коштує VPS на місяць або перенесете робоче навантаження на виділений сервер.

FAQ

Чому я щоразу отримую інший результат тесту продуктивності?

VPS використовує фізичні ресурси CPU, сховища та мережі спільно з іншими орендарями, тому результат залежить від їхніх дій у цей момент. Запустіть vmstat 1 під час тестування та перегляньте стовпчик st: стабільне значення steal time понад 5 означає, що хост був зайнятий, а показник CPU низький через причини поза межами вашої машини. Важливий метод, а не оптимізація. Запускайте кожен тест щонайменше п’ять разів у різні години, а потім наводьте медіану разом із розкидом результатів.

Чому fio показує мільйони IOPS?

Майже завжди це відбувається через відсутність --direct=1. Без нього fio читає через кеш сторінок ядра, тому після першого проходу тестовий файл розміром 2G обслуговується з RAM, і ви фактично вимірюєте пропускну здатність пам’яті. Додайте --direct=1 і використовуйте тестовий файл, більший за будь-який кеш на шляху. Якщо --direct=1 завершується помилкою err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1, виконайте df -hT .: Type розміром overlay не підтримує O_DIRECT, тому спрямуйте тест на реальне сховище.

Чи достатньо самого yabs.sh?

Для первинної оцінки — так. Він запускає fio із чотирма розмірами блоків, iperf3 в обох напрямках і Geekbench, а також виводить один підсумок, який можуть прочитати інші. Цього недостатньо, коли потрібно зрозуміти причину конкретного показника, оскільки не можна змінювати його прапорці для кожного тесту окремо. Якщо результат yabs виглядає неправильним, відтворіть тест безпосередньо за допомогою fio або sysbench і змінюйте по одному прапорцю за раз.

Яке одне число найкраще прогнозує швидкодію моєї програми?

Для більшості вебнавантажень і навантажень баз даних — швидкість одного ядра CPU та затримка довільного читання 4k, саме в такому порядку. Показники пропускної здатності мають вражаючий вигляд, але рідко щось визначають, оскільки типовий запит невеликий. Наводьте 99-й перцентиль із блоку fio clat percentiles, а не середнє значення, оскільки саме один повільний запит зі ста помічає користувач.

Чи потрібно щось інсталювати перед тестуванням продуктивності?

fio, sysbench та iperf3 доступні в архівах Ubuntu і Debian: sudo apt install -y fio sysbench iperf3. Для yabs.sh потрібен лише curl, оскільки він завантажує статичні бінарні файли всього відсутнього. Після завершення видаліть усі тестові файли, оскільки залишений на диску обсягом 20G файл fio розміром 2G через кілька тижнів може спричинити сповіщення про заповнення диска.