LINUX.ORG.RU
ФорумAdmin

ZFS низкая производительность, глубина очереди (queue depth).

 ,


0

2

Приветствую многоуважаемые! Осваиваю ZFS. Есть несколько серверов виртуализации KVM где хотелось бы применить силу ZFS в снапшотах, дистанционный incremental send.

Сейчас для тестов имеется следующий сервер: 2x2680v4, 8x32Gb DDR4 Reg, Карта бифуркации 16 на 4 NVMe SSD. В ней на время тестирования два Samsung 970 Evo Plus на 1Tb.

Чистый Debian 11. Из contrib установлена ZFS 2.0.3

Собран пул: зеркало из двух SSD, ashift=12. На глаз производительность не впечатлила. Начал копать. Настройки пула изменены минимально от дефолтовых.

zp_ssd recordsize 16K local

zp_ssd compression off default

zp_ssd atime off local

zp_ssd primarycache metadata local

zp_ssd secondarycache metadata local

zp_ssd sync standard default

В продакшене будет совсем по-другому, сейчас хочется понять «worst case» когда все читается с дисков, без ARC кэша, удачной компрессии.

Немного освоил fio. Начал с тестов на чтение. Обнаружил пренеприятную особенность. ZFS никак не реагирует на параметр iodepth. Зато великолепно реагирует на numjobs.

Набросал такой fio тест:

[global]

filename=/zp_ssd/fio.file

size=1G

time_based

runtime=10

direct=1

buffered=0

ioengine=libaio

numjobs=1 или 16

[SEQ_1M_Q8]

stonewall

rw=read

bs=1M

iodepth=8

[SEQ_1M_Q1]

stonewall

rw=read

bs=1M

iodepth=1

[RND_4K_Q32]

stonewall

rw=randread

bs=4K

iodepth=32

[RND_4K_Q1]

stonewall

rw=randread

bs=4K

iodepth=1

Меняя в этом тесте только один параметр numjobs получаются абсолютно разные результаты в ZFS:

При numjobs=1 все совсем грустно:

  1. READ: bw=820MiB/s (860MB/s), 820MiB/s-820MiB/s (860MB/s-860MB/s), io=8200MiB (8598MB)
  2. READ: bw=820MiB/s (860MB/s), 820MiB/s-820MiB/s (860MB/s-860MB/s), io=8205MiB (8604MB)
  3. READ: bw=24.1MiB/s (25.3MB/s), 24.1MiB/s-24.1MiB/s (25.3MB/s-25.3MB/s), io=241MiB (253MB)
  4. READ: bw=23.7MiB/s (24.8MB/s), 23.7MiB/s-23.7MiB/s (24.8MB/s-24.8MB/s), io=237MiB (248MB)

При numjobs=16 цифры начинают радовать, но разницы между 1-2 и 2-3 (где меняется iodepth нет):

  1. READ: bw=8205MiB/s (8603MB/s), 8205MiB/s-8205MiB/s (8603MB/s-8603MB/s), io=80.1GiB (86.1GB)
  2. READ: bw=9483MiB/s (9944MB/s), 9483MiB/s-9483MiB/s (9944MB/s-9944MB/s), io=92.6GiB (99.5GB)
  3. READ: bw=385MiB/s (404MB/s), 385MiB/s-385MiB/s (404MB/s-404MB/s), io=3851MiB (4038MB)
  4. READ: bw=383MiB/s (402MB/s), 383MiB/s-383MiB/s (402MB/s-402MB/s), io=3834MiB (4021MB)

Убиваю пул, форматирую в ext4 один диск. Получаю такие показатели:

При numjobs=1:

  1. READ: bw=3150MiB/s (3303MB/s), 3150MiB/s-3150MiB/s (3303MB/s-3303MB/s), io=30.8GiB (33.0GB)
  2. READ: bw=2405MiB/s (2522MB/s), 2405MiB/s-2405MiB/s (2522MB/s-2522MB/s), io=23.5GiB (25.2GB)
  3. READ: bw=921MiB/s (965MB/s), 921MiB/s-921MiB/s (965MB/s-965MB/s), io=9207MiB (9654MB)
  4. READ: bw=63.5MiB/s (66.6MB/s), 63.5MiB/s-63.5MiB/s (66.6MB/s-66.6MB/s), io=636MiB (666MB)

При numjobs=16:

  1. READ: bw=3159MiB/s (3313MB/s), 3159MiB/s-3159MiB/s (3313MB/s-3313MB/s), io=30.0GiB (33.3GB)
  2. READ: bw=3155MiB/s (3308MB/s), 3155MiB/s-3155MiB/s (3308MB/s-3308MB/s), io=30.8GiB (33.1GB)
  3. READ: bw=2417MiB/s (2534MB/s), 2417MiB/s-2417MiB/s (2534MB/s-2534MB/s), io=23.6GiB (25.3GB)
  4. READ: bw=887MiB/s (930MB/s), 887MiB/s-887MiB/s (930MB/s-930MB/s), io=8871MiB (9302MB)

Ext4 прекрасно реагирует и на numjobs и на iodepth.

Прошу помочь.



Последнее исправление: rcSergey (всего исправлений: 3)

ZFS никак не реагирует на параметр iodepth.

что это и нафига оно нужно, когда у openzfs свой планировщик io?

darkenshvein ★★★★★
()
Ответ на: комментарий от mord0d

1.Вы про спойлеры, попытался исправить. Результата нет.

Проверка

  1. В тексте есть «Собран пул: зеркало из двух SSD, ashift=12»

Еще раз хотел обратить внимание на то что при numjobs=16 на том же самом пуле, без каких либо изменений цифры вполне достойные.

rcSergey
() автор топика
Ответ на: комментарий от darkenshvein

iodepth параметр бенчмарка fio, как мной понято (могу ошибаться)

  1. iodepth отвечает за глубину очереди
  2. numjobs отвечает за количество потоков

Плохие результаты в однопотоке (numjobs=1) (в моем тесте 25.3MB/s vs 24.8MB/s) говорят о том что ZFS обрабатывает запросы с очередью 32 так же как и запросы с очередью 1.

А ext4 дает прирост при увеличении очереди с 66.6MB/s до 965MB/s.

При этом при увеличении количества потоков (numjobs=16) в ZFS происходит отличное масштабирование.

То есть чтобы получить от ZFS хороших скоростей ее нужно долбить многопотоком ?

rcSergey
() автор топика

фигнёй занимаешься, при проектировании zfs производительность стояла не на первом месте.

по тестам:
у тебя recordsize<>bs
тестируй отдельно линейное и рендомное чтение, предварительно выставив recordsize=bs
и планировщик io для nvme дисков поставь в none.

Minona ★★☆
()

На линуксе с nvme и так все фигово, а ты еще зеркалирование на zfs делаешь. Ставь ос Windows там таких проблем нет инфа сотка.

anonymous
()
Ответ на: комментарий от Minona

Почему фигней, ZFS вне конкуренции по возможностям дистанционных инкрементных бэкапов. Понимаю что она больше про надежность и возможности. Готов смирится с разумными потерями в производительности за ее ништяки. Все ее капризы будут исполнены, много регистровой памяти, в планах отдельный ZIL на Optane, и Enterprise SSD в качестве основы.

И самое главное - вполне радуют цифры ZFS во втором по очереди тесте при numjobs=16. Этот тест на том же пуле,тех же ashift, recordsize<>bs и прочих настройках. Вполне достойные цифры SEQ1M 8205MiB/s (8603MB/s) и RND4K 383MiB/s (402MB/s).

Может она в многопоток отдавать хорошо. Нужно чтобы смогла в однопоток очередями >1 и нет никаких вопросов.

«io для nvme дисков поставь в none» - Попробую посмотреть в эту сторону.

rcSergey
() автор топика
Ответ на: комментарий от anonymous

Смотри тесты 2,3,4 все прекрасно в Linux с NVMe. Я наоборот ухожу с Windows. Там все грустно по возможностям за последние 10 лет. В целом один и тот же функционал из года в год (Win2012-Win2019) ни GPU, USB passthrough, ни файловых систем как ZFS. Венде капец - инфа сотка.

rcSergey
() автор топика
Ответ на: комментарий от Minona

«планировщик io для nvme дисков поставь в none.»

for i in ls -d /sys/block/*; do echo $i; cat ${i}/queue/scheduler; done

Выдал: /sys/block/nvme0n1 [none] mq-deadline /sys/block/nvme1n1 [none] mq-deadline /sys/block/nvme2n1 [none] mq-deadline

rcSergey
() автор топика
Ответ на: комментарий от rcSergey

Почему фигней

потому что ты задал датасету recordsize=16K, а читаешь последовательно по bs=1М.
у тебя на один 1М запрос из fio система 64 раза по 16К считывает с диска и 64 раза вычисляет КС.
отсюда и просадка при последовательном чтении.
оставь у recordsize или дефолтный размер 128К или задай 1М.
при тестировании рандом для bs=4K также задай recordsize=4K и получишь больший iops.

в планах отдельный ZIL на Optane, и Enterprise SSD в качестве основы.

зачем пулу из SSD отдельный ZIL на SSD?!
под какие профили нагрузки планируется этот пул?

Minona ★★☆
()
Ответ на: комментарий от Minona

при проектировании zfs производительность стояла не на первом месте.

лол, и поэтому там есть l2arc и slog?

anonymous
()

ZFS создавалась для больших массивов вращающейся ржавчины. Её пытаются как-то натянуть на SSD, но что поделать, если defective by design.

anonymous
()
Ответ на: комментарий от anonymous

при проектировании zfs производительность стояла не на первом месте.

лол, и поэтому там есть l2arc и slog?

да! и поэтому там есть l2arc и slog!

Minona ★★☆
()
Ответ на: комментарий от rcSergey

1.Вы про спойлеры, попытался исправить. Результата нет.

Я про код. Спойлеры работают только в ленте.

В тексте есть

Пул мог быть собран с ashift=12 а фактически могло быть что угодно (я пару раз натыкался на созданные другими админами пулы «я собирал с ashift=12!!!11», с фактическим ashift=9; да и сам пару раз не помню как собирал не с тем ashift).

Про попугаев ничего не скажу, не занимаюсь.

mord0d ★★★★★
()
Последнее исправление: mord0d (всего исправлений: 1)
Ответ на: комментарий от Minona

Еще раз, я понимаю что у меня не оптимальный вариант где recordsize=bs, но мой вопрос не про это! Мой вопрос почему ZFS не дает прироста при увеличении глубины iodepth, тогда как другие файловые системы дают! Производительность ZFS же масштабируется только от количества потоков, а на очередь ей пофиг.

Чтобы наглядней показать я немного меняю настройки и еще раз запускаю тесты.

  1. Увеличил файл фио до 16Gb.
  2. Убрал тесты на чтение 1M, оставил только RND 4K, но с разной глубиной

Из 252Gb RAM доступные системе 248Gb отданы в HugePages, primarycache=metadata

Итак тесты делаю в таких вариантах:

  1. RND4K iodepth=1
  2. RND4K iodepth=4
  3. RND4K iodepth=16
  4. RND4K iodepth=32

Поехали:

В один поток (numjobs=1)

  1. READ: bw=24.2MiB/s (25.4MB/s), 24.2MiB/s-24.2MiB/s (25.4MB/s-25.4MB/s), io=242MiB (254MB)
  2. READ: bw=24.3MiB/s (25.5MB/s), 24.3MiB/s-24.3MiB/s (25.5MB/s-25.5MB/s), io=243MiB (255MB)
  3. READ: bw=24.3MiB/s (25.5MB/s), 24.3MiB/s-24.3MiB/s (25.5MB/s-25.5MB/s), io=243MiB (255MB)
  4. READ: bw=24.8MiB/s (26.0MB/s), 24.8MiB/s-24.8MiB/s (26.0MB/s-26.0MB/s), io=248MiB (260MB)

меняем (numjobs=2)

  1. READ: bw=50.5MiB/s (52.9MB/s), 50.5MiB/s-50.5MiB/s (52.9MB/s-52.9MB/s), io=505MiB (529MB)
  2. READ: bw=51.3MiB/s (53.8MB/s), 51.3MiB/s-51.3MiB/s (53.8MB/s-53.8MB/s), io=513MiB (538MB)
  3. READ: bw=52.0MiB/s (55.6MB/s), 52.0MiB/s-52.0MiB/s (55.6MB/s-55.6MB/s), io=530MiB (556MB)
  4. READ: bw=51.1MiB/s (53.6MB/s), 51.1MiB/s-51.1MiB/s (53.6MB/s-53.6MB/s), io=511MiB (536MB)

поднимаем выше (numjobs=4)

  1. READ: bw=114MiB/s (120MB/s), 114MiB/s-114MiB/s (120MB/s-120MB/s), io=1144MiB (1200MB)
  2. READ: bw=113MiB/s (118MB/s), 113MiB/s-113MiB/s (118MB/s-118MB/s), io=1127MiB (1182MB)
  3. READ: bw=113MiB/s (118MB/s), 113MiB/s-113MiB/s (118MB/s-118MB/s), io=1127MiB (1182MB)
  4. READ: bw=112MiB/s (118MB/s), 112MiB/s-112MiB/s (118MB/s-118MB/s), io=1122MiB (1176MB)

еще больше потоков (numjobs=16)

  1. READ: bw=369MiB/s (387MB/s), 369MiB/s-369MiB/s (387MB/s-387MB/s), io=3692MiB (3871MB)
  2. READ: bw=372MiB/s (390MB/s), 372MiB/s-372MiB/s (390MB/s-390MB/s), io=3717MiB (3898MB)
  3. READ: bw=377MiB/s (396MB/s), 377MiB/s-377MiB/s (396MB/s-396MB/s), io=3773MiB (3956MB)
  4. READ: bw=378MiB/s (396MB/s), 378MiB/s-378MiB/s (396MB/s-396MB/s), io=3779MiB (3962MB)

нужно больше потоков (numjobs=32)

  1. READ: bw=517MiB/s (542MB/s), 517MiB/s-517MiB/s (542MB/s-542MB/s), io=5168MiB (5419MB)
  2. READ: bw=518MiB/s (543MB/s), 518MiB/s-518MiB/s (543MB/s-543MB/s), io=5177MiB (5428MB)
  3. READ: bw=518MiB/s (543MB/s), 518MiB/s-518MiB/s (543MB/s-543MB/s), io=5179MiB (5430MB)
  4. READ: bw=518MiB/s (543MB/s), 518MiB/s-518MiB/s (543MB/s-543MB/s), io=5179MiB (5430MB)

предыдущий раз мы уже стучались в потолок (numjobs=56)

  1. READ: bw=518MiB/s (544MB/s), 518MiB/s-518MiB/s (544MB/s-544MB/s), io=5184MiB (5436MB)
  2. READ: bw=518MiB/s (543MB/s), 518MiB/s-518MiB/s (543MB/s-543MB/s), io=5176MiB (5428MB)
  3. READ: bw=518MiB/s (543MB/s), 518MiB/s-518MiB/s (543MB/s-543MB/s), io=5182MiB (5434MB)
  4. READ: bw=518MiB/s (544MB/s), 518MiB/s-518MiB/s (544MB/s-544MB/s), io=5186MiB (5438MB)

Неплохой же рост ? c одного потока: READ: bw=24.2MiB/s (25.4MB/s), 24.2MiB/s-24.2MiB/s (25.4MB/s-25.4MB/s), io=242MiB (254MB) до в потолка который впервые встретился в 32 потока: READ: bw=518MiB/s (543MB/s), 518MiB/s-518MiB/s (543MB/s-543MB/s), io=5179MiB (5430MB)

И все это на одном и том же пуле с одним и тем же ashift, неоптимальным bs и т.д.

То есть ZFS может отдавать много, но не хочет в глубину, как это могут другие.

rcSergey
() автор топика
Ответ на: комментарий от rcSergey

хз как fio отправляет запросы в ФС.
у меня на экспортированном через smb датасете все прекрасно масштабируется по глубине очереди.

повторю вопрос: «под какие профили нагрузки планируется этот пул?»

Minona ★★☆
()
Последнее исправление: Minona (всего исправлений: 1)
Ответ на: комментарий от Minona

«зачем пулу из SSD отдельный ZIL на SSD?!»

Причин несколько: Если я правильно понимаю ZFS, ZIL у нее есть всегда, просто если он не отдельный, то в случае SYNC записи, сначала впопыхах пишется в ZIL который внутри пула, а потом уже по красоте пишется еще раз.

А если мы пишем два раза то:

  1. это изнашивает быстрее SSD
  2. отвлекает по IO на эту двойную запись

Optane это не классический SSD. Там ведь другой тип памяти. Насколько помню очень маленькие задержки на честную запись, а не обман с RAM кэшем на борту SSD. То есть в случае факапа Optane может успеть записать. Ну и вроде по выносливости на запись Optane круче. Единственное это только Intel, а они много о себе думают в ценовой политике.

«под какие профили нагрузки планируется этот пул?» Ракету по скоростям хочу построить :-)

rcSergey
() автор топика
Ответ на: комментарий от Minona

Может дело и в fio, но хотелось бы разобраться, если связка fio - zfs, не умеет в очереди. Может и в другой реальной связке zfs не увидит очереди.

rcSergey
() автор топика
Ответ на: комментарий от rcSergey

Тогда не вижу ничего "криминального". Может где планировщик подсирает (у меня не Linux, так что тут ничего не подскажу)?

// Научись уже в оформление постов/комментариев!

mord0d ★★★★★
()
Ответ на: комментарий от rcSergey

Причин несколько: Если я правильно понимаю ZFS, ZIL у нее есть всегда, просто если он не отдельный, то в случае SYNC записи, сначала впопыхах пишется в ZIL который внутри пула, а потом уже по красоте пишется еще раз.

ну как то так, да =)

А если мы пишем два раза то:
это изнашивает быстрее SSD
отвлекает по IO на эту двойную запись

Optane это не классический SSD. Там ведь другой тип памяти. Насколько помню очень маленькие задержки на честную запись
Ракету по скоростям хочу построить

если у тебя там будет СУБД с миллионами транзакций/с на запись — то да, Optane имеет смысл.

Minona ★★☆
()
Ответ на: комментарий от Minona

потому что ты задал датасету recordsize=16K, а читаешь последовательно по bs=1М. у тебя на один 1М запрос из fio система 64 раза по 16К считывает с диска и 64 раза вычисляет КС. отсюда и просадка при последовательном чтении. оставь у recordsize или дефолтный размер 128К или задай 1М. при тестировании рандом для bs=4K также задай recordsize=4K и получишь больший iops.

Minona, спасибо за объяснение!

Harliff ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.