Vitesses séquentielles lentes sur raidz2 à 9x7 disques (ZFS ZoL 0.8.1)


9

J'exécute un grand pool ZFS conçu pour des lectures et des écritures séquentielles de taille de demande 256K + via iSCSI (pour les sauvegardes) sur Ubuntu 18.04. Étant donné le besoin d'un débit élevé et d'une efficacité de l'espace, et moins de performances aléatoires en petits blocs, j'ai opté pour raidz2 rayé sur des miroirs rayés.

Cependant, les performances de lecture séquentielle de 256K sont bien inférieures à ce que j'aurais prévu (100 - 200MBps, pics jusqu'à 600MBps). Lorsque les zvols atteignent ~ 99% iowait dans iostat, les périphériques de support fonctionnent généralement entre 10 et 40% iowait, ce qui me suggère que le goulot d'étranglement est quelque chose qui me manque dans la configuration, étant donné qu'il ne devrait pas s'agir du fond de panier ou des processeurs dans ce système, et les charges de travail séquentielles ne devraient pas trop travailler l'ARC.

J'ai joué un peu avec les paramètres du module (configuration actuelle ci-dessous), lu des centaines d'articles, des problèmes sur OpenZFS github, etc. Le réglage de la prélecture et de l'agrégation m'a permis d'atteindre ce niveau de performance - par défaut, je fonctionnais à environ ~ 50 Mo sur lectures séquentielles lorsque ZFS envoyait de minuscules requêtes aux disques (~ 16 Ko). Avec l'agrégation et le prefetch fonctionnant bien (je pense), les lectures de disque sont beaucoup plus élevées, autour de ~ 64K en moyenne dans iostat.

Les cartes réseau sont une cible iscsi LIO avec déchargement cxgbit + l'initiateur Windows Chelsio iscsi fonctionne bien en dehors des zvols ZFS, avec un optane directement mappé retournant un débit de ligne presque complet sur les cartes réseau (~ 3,5 Go / s en lecture et en écriture).

Est-ce que j'attends trop? Je sais que ZFS priorise la sécurité sur les performances, mais je m'attends à ce qu'un raidz2 7x9 fournisse de meilleures lectures séquentielles qu'un seul raid mdadm à 9 disques6.

Spécifications du système et fichiers journaux / config:

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

Configuration du pool:

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

Configuration de ZVol:

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

Disposition de la piscine:

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

J'arrache mes cheveux là-dessus. La pression est exercée par les utilisateurs pour passer à Windows avec des espaces de stockage, mais j'ai utilisé des espaces de stockage paritaires (même avec des espaces de stockage directs avec des miroirs en haut), et ce n'est pas joli non plus. Je suis tenté d'aller directement mdadm raid60 sous iSCSI, mais j'adorerais que quelqu'un me signale quelque chose de stupide qui me manque et qui débloquera les performances avec la protection bitrot de ZFS :)

Réponses:


7

Bonne question.

  • Je pense que votre taille de bloc zvol clairsemée devrait être de 128k.
  • Vos paramètres de planificateur ZIO devraient tous être plus élevés, comme minimum 10 et maximum 64.
  • zfs_txg_timeout devrait être beaucoup plus long. Je fais 15 ou 30s sur mes systèmes.
  • Je pense que les multiples RAIDZ3 (ou était-ce une faute de frappe) sont exagérés et jouent un grand rôle dans les performances. Pouvez-vous comparer avec RAIDZ2?

Edit: installez Netdata sur le système et surveillez l'utilisation et les statistiques ZFS.

Edit2: c'est pour un référentiel Veeam. Veeam prend en charge Linux comme cible et fonctionne à merveille avec ZFS. Envisageriez-vous de comparer cela avec vos données? zvols n'est pas un cas d'utilisation idéal pour ce que vous faites, à moins que le déchargement de la carte réseau ne soit un élément essentiel de la solution.


Merci! Point par point dans les commentaires de suivi, sauf Z3 qui était en effet une faute de frappe :). Sur volblocksize, j'ai testé avec 128k et 64k, et les performances n'ont pas beaucoup changé pour les lectures séquentielles. 128k serait probablement un peu plus économe en espace, mais 64k correspond à la taille de l'unité d'allocation du système d'exploitation client initiateur, et semble faire beaucoup mieux dans les scénarios d'E / S aléatoires (qui sont rares), tout en n'ayant pas beaucoup d'importance dans les scénarios d'E / S séquentiels .
obrienmd

Je vais tester avec txg_timeout plus haut - cela importerait-il le moins pour les lectures séquentielles? Étant donné le faible débit sur les disques de support, il ne semble pas que les vidages d'écriture aient beaucoup affecté / affecté les vitesses de lecture moyennes.
obrienmd

1
Les commentaires les plus intéressants que j'ai pour vous (je pense) concernent le planificateur ZIO. Lorsque je déplace l'aiguille sur les minutes et les maximales asynchrones, cela détruit l' agrégation io et le résultat net est assez mauvais. Pour les lectures, ce qui m'importe vraiment ici, car les écritures sont excellentes, passer à 10/64 fait des E / S moyennes sur les disques ~ 16 Ko dans l'iostat et réduit la vitesse de lecture moyenne de 75% (~ 30 à 60 Mo / s) compte tenu de ces disques «IOPS. J'ai également peaufiné les lectures de synchronisation et je n'ai pas vu beaucoup d'effet, mais je vais donner un autre coup malgré tout :)
obrienmd

zfs zfs_dirty_data_max_percent = 25 - Je suis généralement de 40% ou plus là-bas.
ewwhite

Oh, les lectures sont un problème? De quel type de données s'agit-il? Quelle est la taille de la piscine?
ewwhite
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.