Тестирование производительности нескольких типов накопителей в виртуальной среде

[Naves]

С одной стороны, можно сказать, что используемый тест и настройки системы не позволяют корректно оценить скорость данной конфигурации и показывают производительность не диска, а оперативной памяти.

Вы хотя бы написали, какие настройки у вас для диска стоят, какой контроллер virtio, scsi, sata и какой режим кэширования. От этого значения могут отличаться на порядки.
Если делать тесты в плане замера потерь от железа, то надо ставить directsync, если же нужна максимальная производительность с допустимыми потерями, то включается writeback.

[karl77]

Использовался режим Virtio с no cache.

[midaw1]

А кто нибудь использует virtio в работе? У меня более менее стабильно работает только virtio scsi. Правда proxmox не использую.

[Naves]

Давно используем в проксмокс, проблем нет.
Простой виртио не рекомендуется, VirtIO block may get deprecated in the future.
Во времена 2003 винды были проблемы с определенными версиями, примерно как у старого линукса, нечетные версии нестабильны, четные стабильны.

[KorP]

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

За такие «типичные» варианты я бы ноги сразу отрывал всем, кто их упоминает.

Про показатели разных типов дисков написано тут вагон и маленькая тележка, при чём уже довольно давно, но с тех пор ничего не изменилось.

На каком объёме данных проходили тесты то? Диски предварительно заполнялись или нет? Какое время тестирования для флеша?

Ясное дело, что виртуализация вносит свои коррективы, но имхо Proxmox VE — далеко не показатель. ВОзьмите ради интереса хайпер-в или вмваре

[karl77]

Про показатели разных типов дисков написано тут вагон и маленькая тележка, при чём уже довольно давно, но с тех пор ничего не изменилось.

Не очень понятен выбор материала для сравнения. Да и как минимум цифры разные. Так что вероятно все-таки что-то изменилось. Например, условия тестирования.

На каком объёме данных проходили тесты то? Диски предварительно заполнялись или нет? Какое время тестирования для флеша?

Тесты проводились на блочных устройствах без ограничения объема. В случае виртуальных дисков на lvm и в формате raw диски имели объем 64 ГБ, как и указано в тексте. Диски предварительно не заполнялись. Время тестирования для каждого шаблона — пять минут.

ВОзьмите ради интереса хайпер-в или вмваре

Мне был интересен Proxmox. В принципе, можно попробовать повторить на vmware.

[karl77]

Сколько времени проводились тесты?

Один шаблон — пять минут.

Какой scheduler у дисков/ssd использовали?

Это отдельная история. Добавлять еще один параметр в эту статью не стал. Иначе бы история существенно занянулась. Так что все «из коробки».

Почему для последовательной записи использовали именно 256К блоки?

Так исторически сложилось. Не стояло задачи «выжать все», а так конечно можно было бы еще много разных параметров накрутить. Обычно можно использовать «блок достаточно большого размера». Так что увеличение, скажем до 512 КБ или 1024 КБ, мало что изменит.

P.s. Обычно используют опции sync, direct чтобы не мерить кэш.

Для самого fio конечно direct=1. Но все-таки «что б не мерить кэш» — это неоднозначный вопрос.

P.P.s. Тесты проводились в один поток, а это обычно не свойственно виртуализации. Было бы интереснее увидеть (iops\BW\lat) / threads.

Тесты проводились с изменением параметра iodepth от 1 до 256. Возможно стоило еще обратить внимание на numjobs. Надо будет попробовать и сравнить результаты.

[SergeyD]

Если Proxmox "из коробки", то у него scheduler по-умолчанию — deadline.

[karl77]

Читал несколько статей о выборе scheduler для «не жестких дисков». Результаты тестов, на мой взгляд, неоднозначные. Для конкретной задачи (например, базы данных) можно подобрать оптимальный, если сначала определиться с критериями. Для синтетических тестов это менее интересно/полезно.
А NVMe — это уже другая история и там обычные scheduler не используются.

[t-131]

Интересно было бы увидеть qcow2 под нагрузкой.
Все-таки это формат по-умолчанию в том же прокмоксе
На реддите проскакивало, что raw и qcow2 ноздря в ноздрю идут на тестах, а zvol никак не определится с позицией
Еще в qcow2 можно тюнинговать как минимум: L2 кеширование, preallocation, ну и lazy_refcounts (но по нему никакой информации кроме devel-переписки не нашел)
Лично я пока все эти настройки не крутил — хватает дефолтных с SSD дисками

[karl77]

Вопрос стоял не в «получить максимальные результаты на данном железе настройкой ПО и выбором опций/параметров/режимов». Хотя конечно решение этой задачи очень даже интересно и полезно на практике.

[ktotomskru]

Вы осуществляя последовательное чтение одного 2ТБ жеского диска получили скорость в тысячи МБ/с? Вы издеваетесь что ли?! =)

Простите ради бога, но выглядит что вы что-то не то делали и получили какие-то подозрительные результаты.

[karl77]

Могу только предложить еще раз прочитать текст, а не только посмотреть на картинки.

[speshuric]

Когда я читаю обзоры дисков и вижу что-то очередь 256, то у меня всегда вопрос: а какие выводы можно делать из показателей очереди 8 и больше? Ну то есть если очередь 8, то всё, не имеет смысла дальше смотреть, диск уже захлебнулся. Дальше уже только вопрос, как быстро он всплывет.
Всё бы ничего, но из-за этого диапазона приходится использовать логарифмические шкалы и самое интересная часть графика (очереди 1 и 2) сравнить уже сложно. На графике задержек 1 и 1,5 мс почти в одной точке, а реально это разница в полтора раза.

[karl77]

«Диск» — именно жесткий диск или накопитель в общем смысле этого слова? Причин попробовать 256 несколько — на реальной нагрузке (файловый сервер) видел 150 и более, некоторые конфигурации и на этом значении не упираются в свой предел, часто интересно смотреть до какого значения можно увеличивать очередь с сохранением задержек ниже заданных.

Да, формально 1 и 1,5 — разница в полтора раза. Но найти приложение, которое это заметит, непросто.

[speshuric]

150 на протяжении секунд/минут или на протяжении часов/суток? Если первое, то, да ну бывает по каким-то причинам. Например, СУБД пошла read-ahead делать или что-то подобное — на этом очередь может прыгать и до 300 и до 500 и до 1000. Сервер знает, то читать и поставил в очередь. Я больше с СУБД сталкиваюсь, поэтому мне эта ситуация знакома и обычна. Для OLTP такой всплеск в целом неприятен, но если это не авария, то он «рассасывается».
Но тут такой момент, что с точки зрения разгребания между очередью 16 и очередью 256 разницы почти нет. У вас это тоже в графиках видно: посмотрите, latency просто линейно растет (там обе шкалы логарифмические, поэтому в итоге всё равно линейно). Как в супермаркете: если очередь 5 человек, то ждать 10 минут, если очередь 10 человек, то 20. Наверное есть какая-то оптимизация, объединение смежных чтений, перестановки и т.п., но в реальности картина простая: есть большая очереди и её не волшебное разгребание. Этот диапазон линеен, его не интересно смотреть.

Но найти приложение, которое это заметит, непросто

Любое критичное к дисковой производительности приложение. СУБД, например.

[karl77]

Если смотреть только на «задержки-очередь», то конечно почти везде все линейно. Но на «скорость-очередь» разница между 16 и 256 обычно заметна. Можно было бы ограничиться скажем 128, но все-таки удобнее иметь дополнительные точки для более четкого понимания, что «полка» точно наступила.

В описанной задаче речь не идет про СУБД. Хотя конечно Intel Optane с базами данных смотрелся бы скорее всего отлично.