Langsame sequenzielle Geschwindigkeiten bei 9x7-Laufwerken raidz2 (ZFS ZoL 0.8.1)

Ich verwende einen großen ZFS-Pool, der für sequentielle Lese- und Schreibvorgänge mit einer Anforderungsgröße von 256 KB + über iSCSI (für Sicherungen) unter Ubuntu 18.04 erstellt wurde. Angesichts des Bedarfs an hohem Durchsatz und Raumeffizienz sowie des geringeren Bedarfs an zufälliger Small-Block-Leistung habe ich mich für gestreifte raidz2 über gestreifte Spiegel entschieden.

Die sequentielle Leseleistung von 256 KB ist jedoch weitaus geringer als erwartet (100 - 200 MBit / s, Spitzenwerte bis zu 600 MBit / s). Wenn die zvols in iostat ~ 99% iowait erreichen, laufen die Backing-Geräte normalerweise zwischen 10 und 40% iowait, was mir nahe legt, dass der Engpass in der Konfiguration fehlt, da es sich nicht um die Backplane oder die CPUs handeln sollte Dieses System und sequentielle Workloads sollten den ARC nicht zu hart arbeiten.

Ich habe ziemlich viel mit Modulparametern gespielt (aktuelle Konfiguration unten), Hunderte von Artikeln gelesen, Probleme mit OpenZFS-Github usw. Durch das Optimieren von Prefetch und Aggregation habe ich dieses Leistungsniveau erreicht - standardmäßig lief ich mit ca. 50 MBit / s sequentielle Lesevorgänge, während ZFS TINY-Anforderungen an die Festplatten sendete (~ 16 KB). Wenn Aggregation und Prefetch in Ordnung sind (glaube ich), sind die Festplattenlesevorgänge viel höher und liegen in iostat im Durchschnitt bei ~ 64 KB.

NICs sind LIO-iscsi-Ziele mit cxgbit-Offload + Windows Chelsio iscsi-Initiator funktioniert gut außerhalb der ZFS-zvols, wobei ein direkt zugeordnetes Optan nahezu die volle Zeilenrate auf den NICs zurückgibt (~ 3,5 GBit / s Lesen und Schreiben).

Erwarte ich zu viel? Ich weiß, dass ZFS der Sicherheit Vorrang vor der Leistung einräumt, aber ich würde erwarten, dass ein 7x9-Raidz2 bessere sequenzielle Lesevorgänge bietet als ein einzelner MDADM-Raid6 mit 9 Laufwerken.

Systemspezifikationen und Protokolle / Konfigurationsdateien:

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

Poolkonfiguration:

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

ZVol-Konfiguration:

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

Poollayout:

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

Ich reiße mir die Haare aus. Die Benutzer stehen unter dem Druck, Windows mit Speicherbereichen zu verwenden, aber ich habe Paritätsspeicherbereiche verwendet (auch mit Storage Spaces Direct mit Spiegeln oben), und es ist auch nicht schön. Ich bin versucht, mdadm raid60 unter iSCSI direkt zu starten, würde es aber lieben, wenn jemand auf etwas hinweisen könnte, das mir fehlt, das die Leistung mit dem Bitrot-Schutz von ZFS freischaltet :)

Gute Frage.

• Ich denke, Ihre spärliche zvol-Blockgröße sollte 128k betragen.
• Ihre ZIO-Scheduler-Einstellungen sollten alle höher sein, z. B. mindestens 10 und maximal 64.
• zfs_txg_timeout sollte viel länger sein. Ich mache 15 oder 30s auf meinen Systemen.
• Ich denke, die mehreren RAIDZ3 (oder war das ein Tippfehler) sind übertrieben und spielen eine große Rolle in der Leistung. Können Sie mit RAIDZ2 Benchmarking durchführen?

Bearbeiten: Installieren Sie Netdata auf dem System und überwachen Sie die Auslastung und die ZFS-Statistiken.

Edit2: Dies ist für ein Veeam-Repository. Veeam unterstützt Linux als Ziel und funktioniert wunderbar mit ZFS. Würden Sie in Betracht ziehen, dies mit Ihren Daten zu vergleichen? zvols sind kein idealer Anwendungsfall für das, was Sie tun, es sei denn, das Auslagern der Netzwerkkarte ist ein kritischer Teil der Lösung.