Пять российских VPS на Linux: fio, sysbench и грабли

Обзоров VPS ^[1] на Хабре хватает, но почти все сделаны Windows-утилитами и сводятся к тому, какой диск показал «отличный результат». Мне же нужна была батарея, которую можно прогнать по SSH на любой машине, и понимание, что конкретно означает каждое число.

Второй пункт оказался неожиданно объёмным. Я трижды получал красивые результаты, которые не имели отношения к тому, что я думал измерить: скорость оперативки вместо диска, кэш гипервизора вместо носителя, конфиг лимитера вместо производительности. Каждый раз цифры выглядели совершенно правдоподобно, и я бы их спокойно опубликовал.

Поэтому в этой статье: сначала стенд и методика, потом грабли по ходу замера, потом результаты. Ну и длинный список оговорок в конце.

Подопытные

Все характеристики сняты с самих машин (lscpu, free, lsblk, systemd-detect-virt, /etc/os-release).

¹Тип диска – единственная строка, которая не измерена, а процитирована по заявлению провайдера. Вернусь к этому в разделе с оговорками, там же объясню, почему проверить это изнутри ВМ нельзя.

Методика

Три полных прохода батареи на каждый хост – не три повтора одного теста подряд, а три круга. Так повторы одной метрики разнесены во времени и меньше ловят локальный шум соседей по гипервизору. Пауза 20 с после каждого теста, итог по метрике – медиана трёх проходов. Три точки – это не оценка с погрешностью, так что последний знак в таблицах читайте как ориентир, а не как точность. Хосты обрабатывались последовательно.

Версии инструментов – штатные из репозитория каждой ОС, намеренно не выравнивались: цель была измерить конфигурацию из коробки. fio 3.28 / 3.36 / 3.41, OpenSSL 3.0.2 / 3.0.13 / 3.5.5. Для fio и sysbench разница версий на результат практически не влияет, для openssl – влияет, см. раздел с оговорками.

Диск

Профили – те же четыре, что в CrystalDiskMark: по факту они давно стали стандартом, и результаты легко сопоставить с любыми чужими замерами:

# тестовый файл – ОБЯЗАТЕЛЬНО на дисковом разделе
TESTFILE=/var/tmp/fio_test

# SEQ1M Q8T1 – потолок в идеальных условиях
fio --name=seq1m_q8t1_read --filename=$TESTFILE --size=1G 
    --rw=read --bs=1M --iodepth=8 --numjobs=1 
    --ioengine=libaio --direct=1 --runtime=30 --time_based 
    --group_reporting

# SEQ1M Q1T1 – копирование одного большого файла
fio --name=seq1m_q1t1_read --filename=$TESTFILE --size=1G 
    --rw=read --bs=1M --iodepth=1 --numjobs=1 
    --ioengine=libaio --direct=1 --runtime=30 --time_based 
    --group_reporting

# RND4K Q32T1 – отзывчивость под нагрузкой (БД, много мелких файлов)
fio --name=rnd4k_q32t1_read --filename=$TESTFILE --size=1G 
    --rw=randread --bs=4k --iodepth=32 --numjobs=1 
    --ioengine=libaio --direct=1 --runtime=30 --time_based 
    --group_reporting

# RND4K Q1T1 – то же, но по одной операции за раз
fio --name=rnd4k_q1t1_read --filename=$TESTFILE --size=1G 
    --rw=randread --bs=4k --iodepth=1 --numjobs=1 
    --ioengine=libaio --direct=1 --runtime=30 --time_based 
    --group_reporting

Для записи – --rw=write и --rw=randwrite соответственно. Плюс отдельная контрольная серия ровно теми же командами, но с --size=6G – зачем, объясняю дальше.

CPU, память, крипто, архиватор

sysbench cpu --cpu-max-prime=20000 --threads=1 --time=30 run
sysbench cpu --cpu-max-prime=20000 --threads=4 --time=30 run

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

openssl speed -seconds 10 -evp aes-256-cbc
openssl speed -seconds 10 sha256

7z b

К слову openssl speed sha256 -seconds 10 падает с Unknown algorithm -seconds. В OpenSSL 3.x опции обязаны идти до имени алгоритма. Правильно будет openssl speed -seconds 10 sha256.

Три грабли

Раздел важный, потому что от него зависит, можно ли верить таблицам ниже. Каждая из ошибок не ломает тест и не выдаёт ничего похожего на сбой – она просто подменяет то, что вы измеряете, и возвращает вполне правдоподобное число. Заметить подмену по самому результату нельзя, только по методике – что я и сделал.

Грабля №1: /tmp – это не диск

Классическое место для тестового файла – /tmp. На SmartApe (Ubuntu 26.04) /tmp смонтирован как tmpfs размером 981 МБ, то есть лежит в оперативной памяти.

В предварительном прогоне я получил у SmartApe 2.5 ГБ/с – файл на 256 МБ помещался в tmpfs целиком, и fio измерил скорость RAM. Цифра абсолютно правдоподобная для NVMe. Я бы её опубликовал.

Проверка по всем пяти хостам:

Один хост из пяти. Причём именно тот, у которого ОС новее всех.

Тестовый файл переехал в /var/tmp (дисковый раздел на всех пяти), а в скрипт добавлена явная проверка – на tmpfs/ramfs дисковые тесты теперь отказываются стартовать с ошибкой, а не меряют память:

FSTYPE=$(stat -f -c %T "$(dirname "$TESTFILE")")
case "$FSTYPE" in
  tmpfs|ramfs)
    echo "ОТКАЗ: $(dirname "$TESTFILE") – это $FSTYPE, тут вы измерите RAM" >&2
    exit 1 ;;
esac

Кто повторяет такие замеры – проверяйте stat -f -c %T /tmp до публикации, а не после.

Грабля №2: --direct=1 не отключает кэш гипервизора

Следите за руками.

--direct=1 в fio отключает страничный кэш внутри гостевой ОС. Кэширование на стороне хоста он не обходит, и изнутри ВМ отключить его невозможно в принципе. А тестовый файл на 1 ГБ целиком помещается в RAM хоста. Механизм такой: первое чтение идёт с носителя, а дальше файл целиком оседает в памяти физического хоста, и все последующие тесты в батарее читают уже оттуда. Вы думаете, что меряете диск, а меряете RAM чужого сервера.

Само по себе внутри одного прогона это не поймать: цифры выглядят естественно. Ловит только контроль на файле, который заметно крупнее – если результат на большом файле резко падает, значит на маленьком вы читали кэш. Поэтому основную батарею я оставил на 1 ГБ (чтобы результаты были сопоставимы между хостами), но добавил контрольную серию теми же командами на файле 6 ГБ.

В скобках – во сколько раз результат на файле 1 ГБ выше контрольного.

Две вещи, без которых таблицу можно прочитать неправильно.

1. Контроль снят только по чтению – колонки записи в результатах не проверены ничем.

2. У четырёх хостов из пяти расхождения нет (всё в диапазоне 0.7–1.02x), но это не значит, что цифры проверены. Совпадение исключает кэш меньше 6 ГБ и ничего не говорит про больший, а сколько памяти у хоста, изнутри ВМ не узнать. Тест асимметричен: падение результата – улика, а совпадение не оправдание.

У RUVDS расхождение кратное: последовательное чтение падает с 1 474.8 до 49.3 МБ/с (в 30 раз), случайное Q32 – с 47 510 до 6 010 IOPS. Красивые 1 474.8 МБ/с NVMe на большом файле оказались 49 МБ/с. Причём 49.3 при очереди 8 и 49.2 при очереди 1 – совпадение до 0.2% при восьмикратной разнице очереди, то есть это не скорость носителя, а полка лимитера, в которую упираешься после исчерпания бёрст-кредита.

Отдельно про Reg.ru ^[1], и тут честно – я не знаю. Контроль расхождения не выявил, но 10-11 ГБ/с последовательного чтения для рядового VPS-тарифа выглядят оптимистично, и объяснить их я не могу ни одним механизмом целиком. Кэш? За 30 секунд контрольного теста прочитано около 337 ГБ, то есть примерно 56 проходов по файлу в 6 ГБ, – на пятьдесят шестом проходе упреждающее чтение уже ни при чём, это похоже на резидентность. Но тогда rnd4k Q1 на той же машине должен летать, а он даёт 6 046 IOPS, то есть 132 мкс на операцию, – для чтения из оперативки хоста это непозволительно долго.

Две цифры указывают в разные стороны, и изнутри ВМ я их не развожу. Поэтому корректная формулировка такая: для последовательных колонок Reg.ru ^[1] я не могу определить, что именно измерил. Это верхняя граница виртуального диска вместе со всем, что под ним кэширует, а не скорость носителя. Контроль на 6 ГБ тут не сработал – не потому, что цифры хорошие, а потому, что 6 ГБ для этого хоста оказалось мало.

Грабля №3: слишком ровные цифры – это лимитер

Казалось бы, если три прохода дали почти одинаковый результат – значит, стабильная площадка, ставим плюсик. Но неправдоподобная стабильность обычно означает, что вы упёрлись не в носитель, а в жёсткий QoS-лимит на стороне хранилища. У трёх хостов из пяти так и оказалось.

Про Cloud4U стоит сказать отдельно, потому что тут признак другой, чем у Reg.ru ^[1]. У Reg.ru ^[1] улика – разброс между проходами: 0.001% на трёх повторах. У Cloud4U разброс в такой детализации я не смотрел, зато совпали чтение и запись. Это разные пути в стеке хранилища: чтение обязано сходить за данными, запись обслуживается write-back кэшем, и на живом носителе они дают разные числа – что видно по остальным хостам выборки (у SmartApe 103 851 против 54 693, почти вдвое). Совпадение до 0.005% означает, что обе операции упираются не в носитель, а в общий для них счётчик.

И отдельное наблюдение, которое я не могу объяснить, но обязан отметить: полка в районе 40 000 IOPS обнаружилась сразу у двоих из трёх – у Reg.ru ^[1] (kvm) и у Cloud4U (vmware). Разные провайдеры, разные гипервизоры, разные ОС, а число одно. Похоже, 40k – это просто распространённая коммерческая ступень QoS, а не свойство какого-то конкретного железа. Если так, то встретить её вы можете где угодно, и это ещё один аргумент за то, чтобы проверять свои цифры на совпадения, а не радоваться их стабильности.

---

Результаты

Диск, файл 1 ГБ

Значения – МБ/с. По RUVDS достоверна не отдельная цифра, а пара «бёрст ~1.4 ГБ/с → полка ~50 МБ/с после его исчерпания» – см. граблю №2.

Значения – IOPS.

Про колонки записи. У всех пяти хостов запись при очереди 1 быстрее чтения – обычный признак write-back кэша: чтение обязано сходить за данными, а запись считается завершённой, как только её подтвердил кэш. Так что записи в таблицах – это скорее скорость подтверждения, чем гарантированная скорость на носителе.

Кроме уже разобранных лимитеров, тут стоит отметить одну связку. У IHC.host странно смотрится связка «126 тысяч IOPS на случайных операциях» и «526 МБ/с на последовательной записи». Первое – отличный результат, лучший в тесте на Q32-чтении (и 152 516 IOPS в контрольном замере на 6 ГБ). Второе – полка лимитера. Разные метрики упираются в разные ограничения, и это в целом нормально, просто не переносите одну на другую.

CPU и память

CPU – событий/с, больше лучше.

По sysbench Reg.ru ^[1] (Icelake) даёт 911 событий/с в один поток против 341–418 у остальных и 3 642 на всех ядрах против 1 353–1 661; масштабирование у всех пяти линейное, ×4 к однопоточному.

Записывать это в «быстрый процессор» я бы не стал: другие счётные тесты отрыва не подтверждают. Относительно второй машины в каждом тесте Reg.ru ^[1] впереди на 3% по 7-Zip (16 176 против 15 666 у RUVDS), на 14% по AES и на 3% по чтению из памяти – против 118% по sysbench. При этом 7-Zip и sysbench cpu оба целочисленные и оба грузят все ядра, так что расхождение в разы не спишешь ни на архитектуру (Icelake против Cascadelake – это проценты IPC, не разы), ни на соседей по гипервизору – те просадили бы и 7-Zip. Steal time я не снимал ни на одном хосте, поэтому назвать причину уверенно не могу; но аномалия тут скорее у метрики, чем у машины. По прикладной нагрузке – 7-Zip – все пятеро укладываются в 22%.

Остальное совпадает: разница между «Xeon Gold 6248 @ 2.50GHz» и «Xeon Processor (Cascadelake)» в названии не отражает ничего интересного, а по памяти разброс 18 951–21 708 МиБ/с – все пятеро в одной весовой категории.

Крипто и архиватор

На SHA-256 у Reg.ru ^[1] отрыв выглядит совсем неприличным – 1 050 против 340–401. Но, полагаю, часть отрыва может давать не процессор, а версия OpenSSL. Их я намеренно не выравнивал, поэтому корректная интерпретация колонки – «производительность связки CPU + штатный OpenSSL этой ОС», а не «производительность CPU». Если вы соберёте одинаковый OpenSSL на всех пяти, разрыв уменьшится; насколько – вопрос нового исследования.

Аномалии и нестабильность

То, что не попало в медианы, но должно попасть в статью.

Одна из двух строк – у RUVDS. Вместе с кратным расхождением на контрольном замере это складывается в довольно последовательную картину: у этой конфигурации производительность заметно зависит от того, что творится вокруг и сколько вы уже успели прочитать.

---

Что можно утверждать, а что нет

Дальше идёт моя интерпретация. Выборка по одной машине на провайдера, снята в один заход, поэтому это утверждения про пять конкретных виртуалок. Но, тарифы у них разные. У SmartApe 1.9 ГБ RAM против 7.8 у трёх других, диски от 32 до 80 ГБ, цены я не нормировал. Так что ниже не привычный для восприятия «топ», а что может показать конкретная виртуалка на конкретном тарифе.

• IHC.host – случайные операции. 152 516 IOPS на Q32 в контроле и лучший Q1 в выборке (8 095, то есть 124 мкс). Это самый прочный дисковый результат статьи: он и высокий, и не рассыпался на большом файле. Но есть потолок в 526 МБ/с на последовательной записи, и нагруженная запись в него упрётся. Оговорюсь, что 126 076 IOPS из основной таблицы – это те же 492 МиБ/с, подозрительно близко к потолку записи, так что часть Q32-результата может быть той же полкой, только в других единицах. Контрольные 152 516 (596 МиБ/с) её пробивают, значит на чтении лимит либо выше, либо другой.

• Cloud4U – второй в выборке по Q1 (7 903 IOPS, 127 мкс), идёт вплотную за лидером. По последовательному чтению среди проверенных тоже второй (3 074.8 МБ/с на контроле). По счётной части в верхней половине: второй AES (874 МБ/с), третий 7-Zip (14 895, от лидера 9%). Но главное, единственная машина без строк в разделе аномалий. Потолок 40k на глубокой очереди у него есть, но это единственный хост, про который я могу точно сказать, где этот потолок проходит: 40 329 на чтении, 40 327 на записи, 40 302 в контроле.

• SmartApe – лучшее последовательное чтение из проверенных (5 387 МБ/с) и второй Q32 (107 062). Плюс единственный хост, у которого чтение и запись на Q32 расходятся вдвое (103 851 против 54 693) – по логике грабли №3 это признак живого носителя, а не общего счётчика, и полки я у него не нашёл ни одной. Из минусов – разброс ×1.5 на последовательной записи, худший Q1 из четвёрки (155 мкс) и tmpfs на /tmp меньше гигабайта, о который можно споткнуться далеко за пределами бенчмарков.

• Reg.ru ^[1] – отличные память и 7-Zip, правда, с отрывом в 3%, то есть в пределах шума. Вообще по счётной нагрузке разброс между всеми пятью – 22% по 7-Zip, и на фоне дисковых расхождений в разы это не повод для выбора. Отдельно стоит SHA-256: 1 050 против 340–401 у остальных, но это связка «CPU + штатный OpenSSL», а не свойство машины, так что переносить эту цифру на выбор хостера я бы не стал. Также потолок 40k на глубокой очереди и последовательные числа, но ориентироваться на них при выборе я бы тоже не стал, выше уже объяснял почему.

• RUVDS – по счётной части претензий нет: второй 7-Zip (15 666 MIPS). По диску – 771 мкс на операцию при Q1 и полка ~50 МБ/с, в которую упирается и Q8, и Q1 (49.3 и 49.2 – совпадение до 0.2% при восьмикратной разнице очереди). Плюс обе строки раздела аномалий с разбросом ×1.5–1.8. Что именно даёт верхние цифры – бёрст-кредит или кэш хоста, – я не развёл: за 30 секунд теста на 1 474.8 МБ/с прочитано около 44 ГБ, и кредита такого объёма при полке 50 МБ/с не бывает, так что на кэш это похоже больше. Практический вывод одинаков в обоих случаях: эту машину надо мерить своей нагрузкой, а не бенчмарком, промежуточных состояний тут не видно.

И то, ради чего всё писалось

Дисковых чисел в этой статье сорок. Как минимум три из тех, что я собирался публиковать, оказались неправдой: 2.5 ГБ/с у SmartApe были скоростью RAM, 1 474.8 МБ/с у RUVDS – кэшем или бёрстом, но не носителем, «стабильные» 40 132 IOPS у Reg.ru ^[1] – не диском, а конфигом лимитера. Все три выглядели совершенно нормально, и ни одну из них нельзя было опознать по самому результату – только по методике.

---

Оговорки

Тип носителя не измерен, а процитирован. Столбец «Тип диска» заполнен по заявлению провайдера. Изнутри гостевой ОС тип носителя не верифицируется: ни одного nvme*-устройства гость не видит ни на одном хосте, а флаг ROTA в виртуалках недостоверен – у части хостов он равен 1 (как у вращающегося диска), у части 0, притом что заявленный тип носителя у всех пяти одинаковый. То есть флаг не различает даже одинаковые конфигурации. Проверить можно самим:

lsblk -d -o NAME,ROTA,MODEL
ls /dev/nvme* 2>/dev/null || echo "nvme-устройств не видно"

Меряется виртуальный диск, а не носитель. Все диски виртуальные (virtio / QEMU / VMware / Hyper-V). Результаты отражают производительность виртуального диска так, как её видит гостевая ОС, включая накладные расходы виртуализации.

--direct=1 не отключает кэш гипервизора. Флаг обходит кэш только внутри гостя; на стороне хоста изнутри ВМ его не отключить. Контроль на большем файле необходим, но недостаточен.

Маленький вывод

Скорее всего мой маленький эксперимент столкнётся с критикой – но лучше дайте советов на будущее. Полагаю, это не последний мой тест и ваши замечания будут крайне полезны.

Также, если у вас есть машины у этих же или других провайдеров – прогоните команды из раздела «Методика» и киньте цифры в комментарии, особенно контроль на 6 ГБ. Мне сильно интереснее собрать выборку больше одной машины на хостера, чем защищать текущую таблицу.

И главное, ради чего всё писалось: перед публикацией любых дисковых замеров с VPS ^[1] сделайте три вещи – проверьте stat -f -c %T на каталоге с тестовым файлом, повторите тест на файле, заметно превышающем вашу собственную RAM (и помните, что даже это не гарантирует выход за пределы кэша хоста – его объём вам неизвестен), и посмотрите на разброс между проходами. Работы немного, зато вы хотя бы будете знать, чего ваши цифры не доказывают.