1 votes

Simon Richter avatar

MegaRAID : différence de performance entre les volumes

Demandé el 23 de Février, 2021
Quand la question a-t-elle été
201 affichage
Nombre de visites la question a
1 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

J'ai un MegaRAID SAS 9361-8i avec 2x 240GB SATA 6Gbps SSD en RAID1, 4x 10TB SAS 12Gbps HDD en RAID6 et 4x 480GB SATA 6 Gbps SSD en RAID5 :

-----------------------------------------------------------------------------
DG Arr Row EID:Slot DID Type  State BT       Size PDC  PI SED DS3  FSpace TR 
-----------------------------------------------------------------------------
 0 -   -   -        -   RAID1 Optl  N  223.062 Go dflt N  N   dflt N      N  
 0 0   -   -        -   RAID1 Optl  N  223.062 Go dflt N  N   dflt N      N  
 0 0   0   8:2      13  DRIVE Onln  N  223.062 Go dflt N  N   dflt -      N  
 0 0   1   8:5      16  DRIVE Onln  N  223.062 Go dflt N  N   dflt -      N  
 1 -   -   -        -   RAID6 Optl  N   18.190 To enbl N  N   dflt N      N  
 1 0   -   -        -   RAID6 Optl  N   18.190 To enbl N  N   dflt N      N  
 1 0   0   8:0      9   DRIVE Onln  N    9.094 To enbl N  N   dflt -      N  
 1 0   1   8:1      11  DRIVE Onln  N    9.094 To enbl N  N   dflt -      N  
 1 0   2   8:3      10  DRIVE Onln  N    9.094 To enbl N  N   dflt -      N  
 1 0   3   8:4      12  DRIVE Onln  N    9.094 To enbl N  N   dflt -      N  
 2 -   -   -        -   RAID5 Optl  N    1.307 To dflt N  N   dflt N      N  
 2 0   -   -        -   RAID5 Optl  N    1.307 To dflt N  N   dflt N      N  
 2 0   0   8:6      14  DRIVE Onln  N  446.625 Go dflt N  N   dflt -      N  
 2 0   1   8:7      17  DRIVE Onln  N  446.625 Go dflt N  N   dflt -      N  
 2 0   2   8:9      15  DRIVE Onln  N  446.625 Go dflt N  N   dflt -      N  
 2 0   3   8:10     18  DRIVE Onln  N  446.625 Go dflt N  N   dflt -      N  
-----------------------------------------------------------------------------

---------------------------------------------------------------
DG/VD TYPE  State Access Consist Cache Cac sCC       Size Name 
---------------------------------------------------------------
0/0   RAID1 Optl  RW     Yes     NRWBD -   ON  223.062 Go VD0  
1/1   RAID6 Optl  RW     Yes     RWBD  -   ON   18.190 To VD1  
2/2   RAID5 Optl  RW     Yes     NRWBD -   ON    1.307 To VD2  
---------------------------------------------------------------

---------------------------------------------------------------------------------------
EID:Slt DID State DG       Size Intf Med SED PI SeSz Model                     Sp Type 
---------------------------------------------------------------------------------------
8:0       9 Onln   1   9.094 To SAS  HDD N   N  512B HUH721010AL5200           U  -    
8:1      11 Onln   1   9.094 To SAS  HDD N   N  512B HUH721010AL5200           U  -    
8:2      13 Onln   0 223.062 Go SATA SSD N   N  512B Micron_5100_MTFDDAK240TCC U  -    
8:3      10 Onln   1   9.094 To SAS  HDD N   N  512B HUH721010AL5200           U  -    
8:4      12 Onln   1   9.094 To SAS  HDD N   N  512B HUH721010AL5200           U  -    
8:5      16 Onln   0 223.062 Go SATA SSD N   N  512B Micron_5100_MTFDDAK240TCC U  -    
8:6      14 Onln   2 446.625 Go SATA SSD N   N  512B Micron_5100_MTFDDAK480TCC U  -    
8:7      17 Onln   2 446.625 Go SATA SSD N   N  512B Micron_5100_MTFDDAK480TCC U  -    
8:9      15 Onln   2 446.625 Go SATA SSD N   N  512B Micron_5100_MTFDDAK480TCC U  -    
8:10     18 Onln   2 446.625 Go SATA SSD N   N  512B Micron_5100_MTFDDAK480TCC U  -    
---------------------------------------------------------------------------------------

Tester la vitesse d'écriture sur ces VDs :

# lvcreate -ntest1 -L32G vg /dev/sda
# lvcreate -ntest2 -L32G vg /dev/sdb
# lvcreate -ntest3 -L32G vg /dev/sdc
# for i in 1 2 3; do sleep 10; dd if=/dev/zero of=/dev/vg/test$i bs=128M count=256 oflag=direct; done
34359738368 octets (34 Go, 32 GiB) copiés, 120.433 s, 285 Mo/s  (test1/VD 0)
34359738368 octets (34 Go, 32 GiB) copiés, 141.989 s, 242 Mo/s  (test2/VD 1)
34359738368 octets (34 Go, 32 GiB) copiés, 26.4339 s, 1.3 Go/s  (test3/VD 2)

# for i in 1 2 3; do sleep 10; dd if=/dev/vg/test$i of=/dev/zero bs=128M count=256 iflag=direct; done
34359738368 octets (34 Go, 32 GiB) copiés, 35.7277 s, 962 Mo/s  (test1/VD 0)
34359738368 octets (34 Go, 32 GiB) copiés, 147.361 s, 233 Mo/s  (test2/VD 1)
34359738368 octets (34 Go, 32 GiB) copiés, 16.7518 s, 2.1 Go/s  (test3/VD 2)

Exécution de dd en parallèle :

# sleep 10; for i in 1 2 3; do dd if=/dev/zero of=/dev/vg/test$i bs=128M count=256 oflag=direct & done
34359738368 octets (34 Go, 32 GiB) copiés, 28.1198 s, 1.2 Go/s  (test3/VD 2)
34359738368 octets (34 Go, 32 GiB) copiés, 115.826 s, 297 Mo/s  (test1/VD 0)
34359738368 octets (34 Go, 32 GiB) copiés, 143.737 s, 239 Mo/s  (test2/VD 1)

# sleep 10; for i in 1 2 3; do dd if=/dev/vg/test$i of=/dev/zero bs=128M count=256 iflag=direct & done
34359738368 octets (34 Go, 32 GiB) copiés, 16.8986 s, 2.0 Go/s  (test3/VD 2)
34359738368 octets (34 Go, 32 GiB) copiés, 35.7328 s, 962 Mo/s  (test1/VD 0)
34359738368 octets (34 Go, 32 GiB) copiés, 153.147 s, 224 Mo/s  (test2/VD 1)

Les valeurs pour VD 0 et VD 1 sont abyssales, et ce qui est remarquable, VD 2 avait des valeurs similaires aux autres jusqu'à ce que je le supprime et le recrée, ce que je ne peux pas faire avec les autres car ils contiennent des données.

La seule limite que je peux expliquer facilement est la vitesse de lecture de VD 2, qui est environ trois fois la vitesse de liaison SATA - ce qui est logique pour un RAID5 avec quatre disques. La vitesse de lecture de VD0 est un peu en dessous de deux fois la vitesse de liaison SATA, cela pourrait être soit une limitation du support, soit une interrogation non optimale des requêtes dans un RAID1, mais les deux resteraient acceptables.

Les autres chiffres n'ont aucun sens pour moi. Le contrôleur est évidemment capable de traiter les données plus rapidement, et la performance parallèle n'est pas significativement différente de l'examen des volumes de manière isolée, ce qui suggère également qu'il ne choisit pas un chemin de données limité.

Mon interprétation de la situation est que la création des volumes à partir du BIOS au lieu du StorCLI leur a donné une configuration sous-optimale. Comparer la sortie de storcli /c0/v0 show all et storcli /c0/v2 show all ne montre aucune différence inexpliquée, donc ma crainte est que l'erreur se trouve quelque part plus profondément dans la pile.

  • Y a-t-il un piège de configuration ou un bug connu qui expliquerait ce comportement ?
  • Y a-t-il un outil pour analyser les configurations en cas de goulot d'étranglement, ou, à défaut,
  • Puis-je somehow export des valeurs de configuration internes pour me permettre de les comparer entre les volumes ?
Demandé el 23 de Février, 2021 par Simon Richter

Réponse

Trop de publicités?

2voto

Andrew Henle avatar
Andrew Henle Points 1212

Premièrement, dd n'est pas vraiment un bon outil de test des performances des disques. Tout ce que vous faites, c'est tester le streaming, les lectures et écritures séquentielles. De plus, dd alterne entre des opérations de lecture et d'écriture synchrones, donc il y a des "périodes mortes" entre les opérations vers le périphérique que vous testez.

Oui, les multiples lecteurs dans le tableau RAID5 et RAID6 permettront même aux disques rotatifs de suivre les performances effectives d'un miroir RAID1 SSD ou, dans le cas de plusieurs SSD dans un tableau RAID5, de battre réellement les performances d'un miroir RAID1 SSD.

Tant que vous streamer de grandes quantités de données séquentiellement.

Mais essayez d'écrire des blocs aléatoires de petite taille sur ces tableaux RAID5 et RAID6 et regardez la performance chuter (surtout sur le DD des disques rotatifs...) alors que le RAID1 sur SSD ne verra pas une baisse de performance aussi importante.

Si vous essayez d'écrire des blocs de 512 octets de manière aléatoire sur ce tableau RAID6 de disques rotatifs, vos performances seraient probablement de quelques dizaines de ko/s, si c'est possible.

Ce qui se passe sur RAID5 et RAID6 lorsque vous écrivez de petits blocs à des emplacements aléatoires est "lire-modifier-écrire". Vous souvenez-vous lorsque vous avez choisi une "taille de bande" ou "taille de segment" lorsque vous avez créé le tableau RAID5 ou RAID6? En fonction du contrôleur, c'est la quantité de données dans un bloc utilisée pour calculer la parité, ou c'est la quantité de données par disque de données qui est utilisée pour calculer la parité. Qu'avez-vous choisi? 64K? 128K? 2 Mo parce que "plus grand doit être plus rapide"?(Non, ce n'est pas le cas...) La quantité de données utilisée pour calculer la parité sur un tableau RAID5 ou RAID6 est couramment appelée "taille de bande". Donc, si vous avez choisi une taille de segment de 2 Mo sur un tableau RAID5 de 4 disques (3 données, une parité), et que votre contrôleur traite ce 2 Mo comme une valeur par disque, cela signifie que la taille de la bande est de 6 Mo. (Non, il n'y a pas vraiment de "disque de parité" - les données de parité sont réparties sur tous les disques. Mais c'est une façon pratique de penser à la plus grande quantité d'espace nécessaire pour contenir les données et la parité.)

Et 6 Mo devient effectivement le plus petit bloc de données sur le tableau RAID sur lequel vous pouvez opérer.

Alors, que se passe-t-il si vous écrivez 512 octets au milieu de l'une de ces bandes de 6 mégaoctets?

Le contrôleur doit lire toute la bande de tous les lecteurs, mettre à jour la partie correcte de ce bloc avec les nouveaux 512 octets, recalculer la parité de toute la bande, puis écrire la bande et la parité de nouveau sur tous les disques.

Il y a beaucoup d'optimisations que les bons contrôleurs RAID peuvent et font pour cette opération "lire-modifier-écrire" afin que vous ne voyiez que rarement l'impact complet, mais logiquement c'est ce qui doit se produire. Et à la fin, vous pouvez lancer suffisamment de petites écritures aléatoires sur n'importe quel contrôleur pour que sa capacité à optimiser l'E/S et à cacher les performances abysmales sous-jacentes soit dépassée.

De plus, sur les disques durs rotatifs, le contrôleur doit attendre que les têtes de lecture se déplacent vers la piste appropriée - quelque chose que les SSD n'ont pas à faire.

Donc les performances d'écriture de gros blocs séquentiels sur les tableaux RAID5 et RAID6 peuvent être très bonnes. Mais la performance d'écriture de petits blocs aléatoires est horrible, et cette horreur est souvent exacerbée en utilisant de grandes tailles de segment/bande. Et c'est encore pire sur les disques rotatifs.

L'alignement des opérations d'E/S compte aussi. Si les blocs de votre système de fichiers ne s'alignent pas avec les bandes RAID5/RAID6, vous finirez par effectuer des opérations de lecture-modification-écriture excessives. Connaissez-vous beaucoup de systèmes de fichiers avec une taille de bloc de 6 Mo? Cela ne serait probablement "aucun". Et c'est une autre raison pour laquelle les grandes tailles de segment/bande sur les tableaux RAID5/6 sont mauvaises, en plus de la raison pour laquelle vous voyez souvent des tableaux RAID5/6 avec un nombre de disques de données puissance de deux - pour que la taille de bande RAID puisse être assortie à (ou être plus petite que) la taille de bloc du système de fichiers.

Performances de lecture? Vous avez la lecture anticipée désactivée sur les VD 0 et VD 2:

---------------------------------------------------------------
DG/VD TYPE  State Access Consist Cache Cac sCC       Size Name 
---------------------------------------------------------------
0/0   RAID1 Optl  RW     Yes     NRWBD -   ON  223.062 GB VD0  
1/1   RAID6 Optl  RW     Yes     RWBD  -   ON   18.190 TB VD1  
2/2   RAID5 Optl  RW     Yes     NRWBD -   ON    1.307 TB VD2  
---------------------------------------------------------------

C'est ce que signifie NR dans la colonne Cache - aucune lecture anticipée. Il n'est pas surprenant que VD 1 surpasse à la fois VD 0 et VD 2 en termes de performances de lecture séquentielle et en streaming - le contrôleur peut lire à l'avance sur VD 1 et mettre en cache les données en attente de la prochaine demande de lecture (rappelez-vous ce que j'ai dit plus tôt sur dd laissant du "temps mort" pendant qu'il effectue l'autre moitié de ses déplacements de données?), mais il ne lit pas à l'avance sur VD 0 ou VD 2.

Répondu el 24 de Février, 2021 par Andrew Henle (1212 Points )

0 votes

Avatar de Simon Richter

Oui, c'est bien mon point: "Donc, les performances d'écriture en blocs larges séquentielles en streaming pour les grappes RAID5 et RAID6 peuvent être très bonnes." -- mais ce n'est pas le cas. VD 0 se compose de deux SSD, lit à 1 Go/s (sans prélecture) et écrit à 285 Mo/s. VD 1 se compose de quatre HDD, a la prélecture activée et est en dessous de 240 Mo/s pour la lecture et l'écriture. VD 2, que j'ai recréé après la configuration initiale, a la prélecture désactivée (car SSD) et fonctionne de manière adéquate.

Commenté el 24 de Février, 2021 par Simon Richter

0 votes

Avatar de Simon Richter

Ainsi, le VD avec readahead activé est le plus lent en termes de performances de lecture séquentielle - ce qui est un peu attendu, car il est basé sur des disques durs, mais même ceux-ci devraient fournir davantage, et le fait que ceux-ci soient liés en termes de performances d'écriture avec deux SSD en RAID1 suggère quelque chose de vraiment louche se passe.

Commenté el 24 de Février, 2021 par Simon Richter

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X