Lecture séquentielle lente du pool ZFS

J'ai une question connexe à propos de ce problème, mais elle est devenue trop compliquée et trop grande, j'ai donc décidé de diviser le problème en NFS et en problèmes locaux. J'ai également essayé de poser des questions à ce sujet sur la liste de diffusion zfs-discuter sans grand succès.

Copie lente entre les répertoires NFS / CIFS sur le même serveur

Aperçu: comment je suis configuré et ce que j'attends

1. J'ai un pool ZFS avec 4 disques. 2 To RED configurés comme 2 miroirs qui sont entrelacés (RAID 10). Sous Linux, zfsonlinux. Il n'y a pas de périphériques de cache ou de journal.
2. Les données sont équilibrées entre les miroirs (important pour ZFS)
3. Chaque disque peut lire (brut w / dd) à 147 Mo / s en parallèle, ce qui donne un débit combiné de 588 Mo / sec.
4. J'attends environ 115 Mo / sec d'écriture, 138 Mo / sec de lecture et 50 Mo / sec de réécriture des données séquentielles de chaque disque, en fonction des repères d'un disque ROUGE similaire de 4 To. Je n'attends pas moins de 100 Mo / s en lecture ou en écriture, car n'importe quel disque peut le faire de nos jours.
5. Je pensais que je verrais une utilisation d'E / S à 100% sur les 4 disques lors de la lecture ou de l'écriture de données séquentielles. Et que les disques produiraient plus de 100 Mo / s avec une utilisation à 100%.
6. Je pensais que le pool me donnerait environ 2x en écriture, 2x en réécriture et 4x en lecture sur un seul disque - je me trompe?
7. NOUVEAU Je pensais qu'un zvol ext4 sur le même pool serait à peu près à la même vitesse que ZFS

Ce que j'obtiens réellement

Je trouve que les performances de lecture du pool ne sont pas aussi élevées que prévu

bonnie ++ benchmark on pool il y a quelques jours

Version 1.97 ------ Sortie séquentielle ------ - Entrée séquentielle - - Aléatoire -
Concurrence 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Taille de la machine K / s% CP K / s% CP K / s% CP K / s% CP K / s% CP / s% CP
igor 63G 99 99 232132 47 118787 27 336 97 257072 22 92,7 6

bonnie ++ sur un seul disque RED de 4 To seul sur un zpool

Version 1.97 ------ Sortie séquentielle ------ - Entrée séquentielle - - Aléatoire -
Concurrence 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Taille de la machine K / s% CP K / s% CP K / s% CP K / s% CP K / s% CP / s% CP
igor 63G 101 99 115288 30 49781 14326 97 138250 13111,6 8

En fonction de cela, les vitesses de lecture et de réécriture sont appropriées sur la base des résultats d'un seul lecteur RED de 4 To (ils sont doubles). Cependant, la vitesse de lecture que j'attendais aurait été d'environ 550 Mo / s (4x la vitesse du lecteur de 4 To) et j'espérerais au moins environ 400 Mo / s. Au lieu de cela, je vois environ 260 Mo / s

bonnie ++ sur le pool à partir de maintenant, tout en rassemblant les informations ci-dessous. Pas tout à fait comme avant, et rien n'a changé.

Version 1.97 ------ Sortie séquentielle ------ - Entrée séquentielle - - Aléatoire -
Concurrence 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Taille de la machine K / s% CP K / s% CP K / s% CP K / s% CP K / s% CP / s% CP
igor 63G 103 99 207518 43 108810 24 342 98 302350 26 256,4 18

zpool iostat pendant l'écriture. Ça me semble bien.

                                                 bande passante des opérations de capacité
pool allocation libre lecture écriture lecture écriture
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1,23 T 2,39 T 0 1,89 K 1,60 K 238 M
  miroir 631G 1.20T 0 979 1.60K 120M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 0 1007 1.60K 124M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 0 975 0 120M
  miroir 631G 1.20T 0 953 0 117M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 0 1.01K 0 128M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 0 953 0 117M

zpool iostat pendant la réécriture. Ça me semble bien, je pense .

                                                 bande passante des opérations de capacité
pool allocation libre lecture écriture lecture écriture
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1,27 T 2,35 T 1015923 125M 101M
  miroir 651G 1.18T 505 465 62.2M 51.8M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 198 438 24,4 M 51,7 M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 306384 37,8M 45,1M
  miroir 651G 1.18T 510457 63.2M 49.6M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 304371 37,8M 43,3M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 206 423 25,5 M 49,6 M

C'est là que je me demande ce qui se passe

zpool iostat pendant la lecture

                                                 bande passante des opérations de capacité
pool allocation libre lecture écriture lecture écriture
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.27T 2.35T 2.68K 32 339M 141K
  miroir 651G 1.18T 1.34K 20 169M 90.0K
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 748 9 92,5 M 96,8 K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 623 10 76.8M 96.8K
  miroir 651G 1.18T 1.34K 11 170M 50.8K
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 774 5 95,7M 56,0K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 599 6 74,0M 56,0K

iostat -x pendant la même opération de lecture. Notez que IO% n'est pas à 100%.

Périphérique: rrqm / s wrqm / sr / sw / s rkB / s wkB / s avgrq-sz avgqu-sz attendent r_await w_await svctm% util
sdb 0,60 0,00 661,30 6,00 83652.80 49,20 250,87 2,32 3,47 3,46 4,87 1,20 79,76
sdd 0,80 0,00 735,40 5,30 93273,20 49,20 251,98 2,60 3,51 3,51 4,15 1,20 89,04
sdf 0,50 0,00 656,70 3,80 83196.80 31,20 252,02 2,23 3,38 3,36 6,63 1,17 77,12
sda 0,70 0,00 738,30 3,30 93572,00 31,20 252,44 2,45 3,33 3,31 7,03 1,14 84,24

zpool et tester les paramètres de l'ensemble de données:

• atime est éteint
• la compression est désactivée
• ashift vaut 0 (détection automatique - si j'ai bien compris, c'était correct)
• zdb dit que les disques sont tous ashift = 12
• module - options zfs zvol_threads = 32 zfs_arc_max = 17179869184
• sync = standard

Édition - 30 octobre 2015

J'ai fait plus de tests

• ensemble de données bonnie ++ w / recordsize = 1M = 226MB en écriture, 392MB en lecture bien meilleure
• ensemble de données dd avec taille d'enregistrement = 1 Mo = 260 Mo en écriture, 392 Mo en lecture bien meilleure
• zvol w / ext4 dd bs = 1M = 128 Mo d'écriture, 107 Mo de lecture pourquoi si lent?
• ensemble de données 2 processess en parallèle = 227 Mo d'écriture, 396 Mo de lecture
• dd direct io ne fait aucune différence sur le jeu de données et sur zvol

Je suis beaucoup plus satisfait des performances avec l'augmentation de la taille des enregistrements. Presque tous les fichiers du pool dépassent largement 1 Mo. Je vais donc le laisser comme ça. Les disques n'obtiennent toujours pas une utilisation à 100%, ce qui me fait me demander si cela pourrait encore être beaucoup plus rapide. Et maintenant, je me demande pourquoi les performances de zvol sont si nulles, car c'est quelque chose que j'utilise (légèrement).

Je suis heureux de fournir toute information demandée dans les commentaires / réponses. Il y a aussi des tonnes d'informations publiées dans mon autre question: Copie lente entre les répertoires NFS / CIFS sur le même serveur

Je suis pleinement conscient que je ne comprends tout simplement pas quelque chose et que ce n'est peut-être pas du tout un problème. Merci d'avance.

Pour être clair, la question est: pourquoi le pool ZFS n'est-il pas aussi rapide que prévu? Et peut-être que quelque chose d'autre ne va pas?

J'ai réussi à obtenir des vitesses très proches des chiffres que j'attendais.

Je cherchais 400 Mo / sec et gérais 392 Mo / sec . Je dis donc que le problème est résolu. Avec l'ajout ultérieur d'un périphérique de cache, j'ai réussi à lire 458 Mo / s (mis en cache, je crois).

1. Au début, cela a été réalisé simplement en augmentant la recordsizevaleur de l' ensemble de données ZFS à1M

zfs set recordsize=1M pool2/test

Je crois que ce changement entraîne simplement moins d'activité sur le disque, donc des lectures et des écritures synchrones plus efficaces. Exactement ce que je demandais.

Résultats après le changement

• bonnie ++ = 226 Mo d'écriture, 392 Mo de lecture
• dd = 260 Mo d'écriture, 392 Mo de lecture
• 2 processus en parallèle = 227 Mo d'écriture, 396 Mo de lecture

2. J'ai réussi encore mieux lorsque j'ai ajouté un périphérique de cache (SSD 120 Go). L'écriture est un peu plus lente, je ne sais pas pourquoi.

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G           208325  48 129343  28           458513  35 326.8  16

L'astuce avec le périphérique de cache était de définir l2arc_noprefetch=0dans /etc/modprobe.d/zfs.conf . Il permet à ZFS de mettre en cache les données de streaming / séquentielles. Ne faites cela que si votre périphérique de cache est plus rapide que votre baie, comme la mienne.

Après avoir profité du changement de taille d'enregistrement sur mon jeu de données, j'ai pensé que cela pourrait être une manière similaire de gérer les mauvaises performances de zvol.

J'ai rencontré plusieurs personnes mentionnant qu'elles avaient obtenu de bonnes performances en utilisant un volblocksize=64k, alors je l'ai essayé. Pas de chance.

zfs create -b 64k -V 120G pool/volume

Mais ensuite, j'ai lu que ext4 (le système de fichiers avec lequel je testais ) prend en charge des options pour RAID comme strideet stripe-widthque je n'ai jamais utilisées auparavant. J'ai donc utilisé ce site pour calculer les paramètres nécessaires: https://busybox.net/~aldot/mkfs_stride.html et formaté à nouveau le zvol.

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume

J'ai couru bonnie++pour faire un simple benchmark et les résultats étaient excellents. Je n'ai malheureusement pas les résultats avec moi, mais ils étaient au moins 5 à 6 fois plus rapides pour les écritures, si je me souviens bien. Je mettrai à jour cette réponse à nouveau si je fais à nouveau un benchmark.

Vos résultats sont parfaitement raisonnables, alors que vos attentes ne le sont pas: vous surestimez l'amélioration des performances de lecture donnée par RAID1 (et, par extension, par RAID10). Le fait est qu'une mise en miroir bidirectionnelle donne au plus 2x la vitesse de lecture / IOP du disque unique, mais les performances réelles peuvent être comprises entre 1x-2x.

Clarifions avec un exemple. Imaginez avoir un système avec miroir bidirectionnel, avec chaque disque capable de 100 Mo / s (séquentiel) et 200 IOPS. Avec une profondeur de file d'attente de 1 (max une seule demande en attente), cette baie n'aura aucun avantage sur un seul disque: RAID1 divise les demandes d'E / S sur la file d'attente des deux disques, mais elle ne fractionne pas une seule demande sur deux disques (au moins, toute implémentation que j'ai vue se comporter de cette manière). D'un autre côté, si votre file d'attente d'E / S est plus grande (par exemple: vous avez 4/8 demandes en attente), le débit total du disque sera nettement supérieur à celui d'un seul disque.

Un point similaire peut être fait pour RAID0, mais dans ce cas, ce qui détermine les améliorations moyennes est fonction non seulement de la taille de la file d'attente, mais également de la taille des demandes d'E / S : si votre taille d'E / S moyenne est inférieure à la taille des blocs, elle ne sera pas rayée sur deux (ou plus) disques, mais il sera servi par un seul. Vos résultats avec l'augmentation de la taille d'enregistrement Bonnie ++ montrent ce comportement exact: le striping bénéficie grandement d'une taille d'E / S plus grande.

Il devrait maintenant être clair que la combinaison des deux niveaux RAID dans une matrice RAID10 n'entraînera pas une mise à l'échelle linéaire des performances, mais elle définit une limite supérieure pour cela. Je suis à peu près sûr que si vous exécutez plusieurs instances dd / bonnie ++ (ou que vous utilisez fiopour manipuler directement la file d'attente IO), vous obtiendrez des résultats plus conformes à vos attentes d'origine, simplement parce que vous taxerez votre tableau IO de manière plus complète ( plusieurs demandes d'E / S séquentielles / aléatoires) plutôt que de le charger uniquement de demandes d'E / S séquentielles uniques.