RAID 1 - md1: 70Mo/s - md2: 220Mo/s - ???
Bonjour à tous, Peut-être d'autres ont rencontré ce phénomène sur des grappes en RAID1 logiciel (mdadm) sous Linux et pourront me conseiller. Deux grappes constituées d'un SSD (/dev/sdb) sur un contrôleur et de deux HDD (/dev/sda et /dev/sdd) sur un autre contrôleur:
/dev/md1: Version : 1.2 Creation Time : Sat Aug 17 20:43:32 2019 Raid Level : raid1 Array Size : 585922560 (558.78 GiB 599.98 GB) Used Dev Size : 585922560 (558.78 GiB 599.98 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Mon Aug 19 11:17:20 2019 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0
Consistency Policy : bitmap
Name : <sanitized>:1 (local to host <sanitized>) UUID : <sanitized> Events : 20538
Number Major Minor RaidDevice State 0 8 2 0 active sync /dev/sda2 1 8 17 1 active sync /dev/sdb1 /dev/md2: Version : 1.2 Creation Time : Sat Aug 17 20:43:50 2019 Raid Level : raid1 Array Size : 585922560 (558.78 GiB 599.98 GB) Used Dev Size : 585922560 (558.78 GiB 599.98 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Mon Aug 19 11:17:20 2019 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0
Consistency Policy : bitmap
Name : <sanitized>:2 (local to host <sanitized>) UUID : <sanitized> Events : 12267
Number Major Minor RaidDevice State 0 8 18 0 active sync /dev/sdb2 1 8 50 1 active sync /dev/sdd2
L'option --write-mostly n'est pas utilisée. Elle permet de prioriser les accès en lecture sur le SSD. Mais les grappes ont été construites sans cette option. hdparm est le seul outil que je connaisse pour faire un test de débit en lecture sur une grappe en particulier, quelque soit le système de fichiers au-dessus. Voilà l'étrange résultat que hdparm renvoie:
# hdparm -t /dev/md1 /dev/md2
/dev/md1: (HDD + SSD) Timing buffered disk reads: 216 MB in 3.03 seconds = 71.38 MB/sec
/dev/md2: (SSD + HDD) Timing buffered disk reads: 672 MB in 3.00 seconds = 223.80 MB/sec
/dev/md2 offre le taux de transfert plus ou moins attendu d'un SSD sur un lien SATA bridé à 300Mo/s. Par contre, le résultat de /dev/md1 semble démontrer que la lecture se fait exclusivement sur le HDD, ignorant totalement le SSD. C'est une situation à la fois curieuse et problématique. Comment expliquer ce phénomène ? Le seul début de piste auquel je peux penser, c'est que l'ordre d'assemblage des grappes n'a pas été le même pour md1 et md2: /dev/md1 est composée de HDD1 + SDD /dev/md2 est composée de SDD + HDD2 Quelqu'un a-t-il jamais entendu dire que l'ordre d'assemblage des disques dans la grappe pourrait-il avoir une conséquence sur la priorité de lecture depuis l'un ou l'autre périphérique ? D'autres outils de benchmark plus sophistiqués (bonnie++, iozone3...) écrivant dans le système de fichiers pour faire leurs tests de performance. Comme des volumes logiques LVM sont intercalés entre le système de fichiers et les grappes RAID, je n'ai pas de moyen de restreindre ces tests à l'une ou l'autre grappe sous-jacente. Évidemment, sans confirmation par un autre outil de bench, on ne peut pas exclure complètement que hdparm renvoie des résultats faussés, pour un raison obscure. Mais les valeurs affichées sont quand même signe d'un truc bizarre. J'espère trouver sur la liste quelques indices permettant de comprendre et corriger ce "dysfonctionnement". Merci. -- Frédéric Dumas f.dumas@ellis.siteparc.fr
réessaie avec un autre outil que hdparm qui est conçu pour du hard et a peut-être une façon particulière d'utiliser les buffer/tailles de blocs. moi j'emploie pipebench (vraiment tout con et dispo en paquet debian) # pipebench </dev/mdX >/dev/null # ##ATTENTION ECRITURE ### pipebench </dev/zero >/dev/mdX Sinon, vérifie en direct les perfs des HDD qui sont en dessous de md Vérifie que tu es bien en sata3. Certains controleurs switchent de mode automatiquement en fonction de la qualité du câble certains HDD ont un cavalier qui force le mode sata2/sata3 Le 20/08/2019 à 12:14, Frederic Dumas a écrit :
st le seul outil que je connaisse pour faire un test de débit en lecture sur une grappe en particulier, quelque soit le système de fichiers au-dessus.
Le 20 août 2019 à 12:14, Frederic Dumas <f.dumas@ellis.siteparc.fr> a écrit :
Bonjour à tous,
Peut-être d'autres ont rencontré ce phénomène sur des grappes en RAID1 logiciel (mdadm) sous Linux et pourront me conseiller.
Deux grappes constituées d'un SSD (/dev/sdb) sur un contrôleur et de deux HDD (/dev/sda et /dev/sdd) sur un autre contrôleur:
/dev/md1: Version : 1.2 Creation Time : Sat Aug 17 20:43:32 2019 Raid Level : raid1 Array Size : 585922560 (558.78 GiB 599.98 GB) Used Dev Size : 585922560 (558.78 GiB 599.98 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Mon Aug 19 11:17:20 2019 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Consistency Policy : bitmap Name : <sanitized>:1 (local to host <sanitized>) UUID : <sanitized> Events : 20538 Number Major Minor RaidDevice State 0 8 2 0 active sync /dev/sda2 1 8 17 1 active sync /dev/sdb1 /dev/md2: Version : 1.2 Creation Time : Sat Aug 17 20:43:50 2019 Raid Level : raid1 Array Size : 585922560 (558.78 GiB 599.98 GB) Used Dev Size : 585922560 (558.78 GiB 599.98 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Mon Aug 19 11:17:20 2019 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Consistency Policy : bitmap Name : <sanitized>:2 (local to host <sanitized>) UUID : <sanitized> Events : 12267 Number Major Minor RaidDevice State 0 8 18 0 active sync /dev/sdb2 1 8 50 1 active sync /dev/sdd2
L'option --write-mostly n'est pas utilisée. Elle permet de prioriser les accès en lecture sur le SSD. Mais les grappes ont été construites sans cette option.
hdparm est le seul outil que je connaisse pour faire un test de débit en lecture sur une grappe en particulier, quelque soit le système de fichiers au-dessus.
Voilà l'étrange résultat que hdparm renvoie:
# hdparm -t /dev/md1 /dev/md2 /dev/md1: (HDD + SSD) Timing buffered disk reads: 216 MB in 3.03 seconds = 71.38 MB/sec
/dev/md2: (SSD + HDD) Timing buffered disk reads: 672 MB in 3.00 seconds = 223.80 MB/sec
/dev/md2 offre le taux de transfert plus ou moins attendu d'un SSD sur un lien SATA bridé à 300Mo/s. Par contre, le résultat de /dev/md1 semble démontrer que la lecture se fait exclusivement sur le HDD, ignorant totalement le SSD. C'est une situation à la fois curieuse et problématique.
Comment expliquer ce phénomène ?
Le seul début de piste auquel je peux penser, c'est que l'ordre d'assemblage des grappes n'a pas été le même pour md1 et md2:
/dev/md1 est composée de HDD1 + SDD /dev/md2 est composée de SDD + HDD2
Quelqu'un a-t-il jamais entendu dire que l'ordre d'assemblage des disques dans la grappe pourrait-il avoir une conséquence sur la priorité de lecture depuis l'un ou l'autre périphérique ?
Regarde si tu es pas dans ce cas: https://serverfault.com/questions/713530/raid1-mdadm-mirror-not-performing-p... <https://serverfault.com/questions/713530/raid1-mdadm-mirror-not-performing-parallel-reads-as-expected>
Bonjour Pierre, Bonjour David, un peu les mêmes que sur FRnOG :-) Merci pour vos réponses. Tu as vu juste David. Sans être dans le même cas de figure que celui décrit, j'ai bien trouvé la réponse dans ton lien:
A single read operation will only read from one drive in a mirror. It will start with the first disk assigned to the mirror, which in this case looks to be /dev/sda.
Quand je lance ma "single read operation" avec hdparm, mdadm la redirige par conséquent sur le premier disque de la grappe, c'est à dire: - le HDD pour /dev/md1, d'où les performances en lecture bridées à ~70Mo/s. - le SSD pour /dev/md2, d'où les performances satisfaisantes en lecture à ~220Mo/s. La solution a consisté à réassembler les grappes en appliquant l'option --write-mostly sur les HDD.
md1 : active raid1 sda2[0](W) sdb1[1] 585922560 blocks super 1.2 [2/2] [UU] bitmap: 0/5 pages [0KB], 65536KB chunk
md2 : active raid1 sdd2[1](W) sdb2[0] 585922560 blocks super 1.2 [2/2] [UU] bitmap: 0/5 pages [0KB], 65536KB chunk
Du coup, md fait attention à ne plus lire depuis le HDD et la règle précédente ne s'applique plus. hdparm affiche maintenant les performances attendues en lecture.
# hdparm -t /dev/md0 /dev/md1 /dev/md2
/dev/md0: Timing buffered disk reads: 224 MB in 3.00 seconds = 74.58 MB/sec
/dev/md1: Timing buffered disk reads: 668 MB in 3.01 seconds = 222.02 MB/sec
/dev/md2: Timing buffered disk reads: 660 MB in 3.01 seconds = 219.42 MB/sec
La grappe /md0 dont je n'avais pas parlé jusqu'ici ne possède pas de SSD; c'est un point de comparaison. Bonne journée à tous. -- Frédéric Dumas f.dumas@ellis.siteparc.fr Le 20/08/2019 à 12:41, David Ponzone a écrit :
Regarde si tu es pas dans ce cas: https://serverfault.com/questions/713530/raid1-mdadm-mirror-not-performing-p...
Le 20/08/2019 à 12:28, Pierre Colombier a écrit :
réessaie avec un autre outil que hdparm qui est conçu pour du hard et a peut-être une façon particulière d'utiliser les buffer/tailles de blocs.
moi j'emploie pipebench (vraiment tout con et dispo en paquet debian)
Tu le couples à time et tu fais une règle de trois quantité/temps pour calculer le débit ?
Vérifie que tu es bien en sata3. Certains controleurs switchent de mode automatiquement en fonction de la qualité du câble certains HDD ont un cavalier qui force le mode sata2/sata3
Je suis en SATA2 par design. 300MB/s nominal, donc ~220MB/s est satisfaisant.
Ok, bien vu. mais les perfs annoncées de 75Mo/s sont quand même très très bof même pour un hdd mécanique en sata2. Du coup je pensais qu'il y avait un autre problème. Le 21/08/2019 à 12:09, Frederic Dumas a écrit :
A single read operation will only read from one drive in a mirror. It will start with the first disk assigned to the mirror, which in this case looks to be /dev/sda.
participants (4)
-
David Ponzone -
Frederic Dumas -
Pierre Colombier -
Pierre DOLIDON