Медленные последовательные скорости на raidz2 с 9x7 накопителями (ZFS ZoL 0.8.1)

Я использую большой пул ZFS, созданный для последовательных операций чтения и записи размером 256 КБ + запроса по iSCSI (для резервных копий) в Ubuntu 18.04. Учитывая потребность в высокой пропускной способности и эффективности использования пространства, а также меньшую потребность в случайной производительности небольших блоков, я выбрал полосатый raidz2 поверх полосатых зеркал.

Однако производительность последовательного чтения 256K намного ниже, чем я ожидал (100–200 МБ / с, пики до 600 МБ / с). Когда zvols достигает iowait ~ 99% в iostat, устройства поддержки обычно работают на 10-40% iowait, что говорит о том, что узкое место - это то, чего мне не хватает в конфигурации, поскольку это не должно быть объединительной платой или процессорами в эта система, и последовательные рабочие нагрузки не должны работать ARC слишком усердно.

Я немного поиграл с параметрами модуля (текущая конфигурация ниже), прочитал сотни статей, проблемы на gitub OpenZFS и т. Д. Настройка предварительной выборки и агрегации вывела меня на этот уровень производительности - по умолчанию я работал на скорости ~ 50 МБ / с последовательное чтение, поскольку ZFS отправляла TINY-запросы на диски (~ 16K). С агрегацией и предварительной загрузкой все в порядке (я думаю), чтение с диска намного выше, в среднем около 64K в iostat.

Сетевые карты являются целевым объектом LIO iscsi с разгрузкой cxgbit + Windows Chelsio iscsi хорошо работает за пределами ZFS zolps, причем оптан напрямую сопоставляется, возвращая почти полную скорость линии на сетевых картах (~ 3,5 Гбит / с для чтения и записи).

Я ожидаю слишком многого? Я знаю, что ZFS отдает предпочтение безопасности над производительностью, но я ожидаю, что 7x9 raidz2 обеспечит лучшее последовательное чтение, чем один 9-дисковый mdadm raid6.

Системные спецификации и журналы / файлы конфигурации:

Chassis: Supermicro 6047R-E1R72L
HBAs: 3x 2308 IT mode (24x 6Gbps SAS channels to backplanes)
CPU: 2x E5-2667v2 (8 cores @ 3.3Ghz base each)
RAM: 128GB, 104GB dedicated to ARC
HDDs: 65x HGST 10TB HC510 SAS (9x 7-wide raidz2 + 2 spares)
SSDs: 2x Intel Optane 900P (partitioned for mirrored special and log vdevs)
NIC: Chelsio 40GBps (same as on initiator, both using hw offloaded iSCSI)
OS: Ubuntu 18.04 LTS (using latest non-HWE kernel that allows ZFS SIMD)
ZFS: 0.8.1 via PPA
Initiator: Chelsio iSCSI initiator on Windows Server 2019

Конфигурация бассейна:

ashift=12
recordsize=128K (blocks on zvols are 64K, below)
compression=lz4
xattr=sa
redundant_metadata=most
atime=off
primarycache=all

Конфигурация ZVol:

sparse
volblocksize=64K (matches OS allocation unit on top of iSCSI)

План бассейна:

7x 9-wide raidz2
mirrored 200GB optane special vdev (SPA metadata allocation classes)
mirrored 50GB optane log vdev

/etc/modprobe.d/zfs.conf:

# 52 - 104GB ARC, this system does nothing else
options zfs zfs_arc_min=55834574848
options zfs zfs_arc_max=111669149696

# allow for more dirty async data
options zfs zfs_dirty_data_max_percent=25
options zfs zfs_dirty_data_max=34359738368

# txg timeout given we have plenty of Optane ZIL
options zfs zfs_txg_timeout=5

# tune prefetch (have played with this 1000x different ways, no major improvement except max_streams to 2048, which helped, I think)
options zfs zfs_prefetch_disable=0
options zfs zfetch_max_distance=134217728
options zfs zfetch_max_streams=2048
options zfs zfetch_min_sec_reap=3
options zfs zfs_arc_min_prefetch_ms=250
options zfs zfs_arc_min_prescient_prefetch_ms=250
options zfs zfetch_array_rd_sz=16777216

# tune coalescing (same-ish, increasing the read gap limit helped throughput in conjunction with low async read max_active, as it caused much bigger reads to be sent to the backing devices)
options zfs zfs_vdev_aggregation_limit=16777216
options zfs zfs_vdev_read_gap_limit=1048576
options zfs zfs_vdev_write_gap_limit=262144

# ZIO scheduler in priority order 
options zfs zfs_vdev_sync_read_min_active=1
options zfs zfs_vdev_sync_read_max_active=10
options zfs zfs_vdev_sync_write_min_active=1
options zfs zfs_vdev_sync_write_max_active=10
options zfs zfs_vdev_async_read_min_active=1
options zfs zfs_vdev_async_read_max_active=2
options zfs zfs_vdev_async_write_min_active=1
options zfs zfs_vdev_async_write_max_active=4

# zvol threads
options zfs zvol_threads=32

Я рву свои волосы на этом. На пользователей приходится давить, чтобы они использовали Windows с пространством хранения, но я использовал паритетные пространства хранения (даже с прямым пространством хранения с зеркалами сверху), и это тоже не очень приятно. Я испытываю искушение перейти прямо на mdadm raid60 под iSCSI, но мне бы понравилось, если бы кто-то мог указать на то, чего мне не хватает, что откроет производительность с помощью защиты от побоев ZFS :)

Хороший вопрос.

• Я думаю, что ваш редкий размер блока zvol должен быть 128k.
• Все ваши настройки планировщика ZIO должны быть выше, например, минимум 10 и максимум 64.
• zfs_txg_timeout должен быть намного длиннее. Я делаю 15 или 30 с на моих системах.
• Я думаю, что несколько RAIDZ3 (или это была опечатка) являются излишними и играют большую роль в производительности. Можете ли вы сравниться с RAIDZ2?

Изменить: Установить Netdata в системе и отслеживать использование и статистику ZFS.

Edit2: это для хранилища Veeam. Veeam поддерживает Linux как цель и прекрасно работает с ZFS. Не могли бы вы сравнить это с вашими данными? zvols - не идеальный вариант использования того, что вы делаете, если только разгрузка NIC не является важной частью решения.