Performances Linux vs LVM

J'essaie de régler mon NAS, d'exécuter openfiler et je me demande pourquoi les performances de lecture de 4 disques WD RE3 en RAID 5 sont relativement médiocres.

EDIT: Veuillez noter que je parle de la vitesse de lecture du disque tamponné et non des vitesses mises en cache

EDIT: mise en forme modifiée pour indiquer clairement qu'il existe deux ensembles de sortie.

Lorsque je lance hdparm sur le méta-périphérique, j'obtiens les niveaux de performance auxquels je m'attendais, je baisse le volume et c'est un tiers de la vitesse!

Quelqu'un a une idée pourquoi? LVM est-il si mauvais?

doyen

Résultats du méta-périphérique / dev / md0

[root @ nas2 etc] # hdparm -tT / dev / md0
/ dev / md0:
 Chronométrage des lectures en cache: 4636 Mo en 2,00 secondes = 2318,96 Mo / sec
 Lectures du disque en mémoire tampon: 524 Mo en 3,01 secondes = 174,04 Mo / sec

Résultats du groupe Vol / dev / mapper / vg1-vol1

[root @ nas2 etc] # hdparm -tT / dev / mapper / vg1-vol1
/ dev / mapper / vg1-vol1:
 Chronométrage des lectures en cache: 4640 Mo en 2,00 secondes = 2320,28 Mo / s
 Lectures du disque en mémoire tampon: 200 Mo en 3,01 secondes = 66,43 Mo / s

Modifier: voir la section de la page de manuel hdparm qui suggère que c'est un test parfaitement valide pour les performances de lecture séquentielle, c'est le problème que j'essaie de résoudre.

-t Effectuer des minutages de lectures de périphérique à des fins de référence et de comparaison. Pour des résultats significatifs, cette opération doit être répétée 2-3 fois sur un autre
              système inactif (aucun autre processus actif) avec au moins quelques mégaoctets de mémoire libre. Cela affiche la vitesse de lecture à travers le tampon
              cache sur le disque sans mise en cache préalable des données. Cette mesure est une indication de la vitesse à laquelle le disque peut supporter des lectures de données séquentielles sous
              Linux, sans surcharge de système de fichiers. Pour garantir des mesures précises, le cache de tampon est vidé lors du traitement de -t à l'aide de BLKFLSBUF
              ioctl. Si l'indicateur -T est également spécifié, un facteur de correction basé sur le résultat de -T sera incorporé dans le résultat rapporté pour -t
              opération.

Les paramètres de lecture anticipée par défaut pour LVM sont vraiment pessimistes. Essayez de blockdev --setra 8192 /dev/vg1/vol1voir ce qui augmente vos performances LVM. Vous prendrez toujours un coup de performance en utilisant LVM; nous le mesurons sur des systèmes correctement configurés à environ 10% des performances des blocs sous-jacents.

Je n'ai pas de bonne explication, mais je peux confirmer les résultats.

Test de RAID (disques raid5, 4x1,5 To)

root@enterprise:# hdparm -tT /dev/md2
/dev/md2:
 Timing cached reads:   2130 MB in  2.00 seconds = 1065.81 MB/sec
 Timing buffered disk reads:  358 MB in  3.00 seconds = 119.15 MB/sec
root@enterprise:# hdparm -tT /dev/md2
/dev/md2:
 Timing cached reads:   2168 MB in  2.00 seconds = 1084.54 MB/sec
 Timing buffered disk reads:  358 MB in  3.01 seconds = 119.10 MB/sec

test de volume qui utilise md2 comme périphérique physique.

root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2078 MB in  2.00 seconds = 1039.29 MB/sec
 Timing buffered disk reads:  176 MB in  3.03 seconds =  58.04 MB/sec
root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2056 MB in  2.00 seconds = 1028.06 MB/sec
 Timing buffered disk reads:  154 MB in  3.03 seconds =  50.81 MB/sec

J'ai fait le changement proposé par womble et j'ai vu des résultats comme celui-ci.

root@enterprise:# blockdev --setra 8192 /dev/mapper/vg2-data

root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2106 MB in  2.00 seconds = 1053.82 MB/sec
 Timing buffered disk reads:  298 MB in  3.00 seconds =  99.26 MB/sec
root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2044 MB in  2.00 seconds = 1022.25 MB/sec
 Timing buffered disk reads:  280 MB in  3.03 seconds =  92.45 MB/sec

Assurez-vous de comparer les pommes aux pommes.

hdparm -t lit depuis le début de l'appareil qui est également la partie la plus rapide de votre disque si vous lui donnez un disque entier (et il tourne sur des plateaux).

Assurez-vous de le comparer avec un LV depuis le début du disque.

Pour voir l'utilisation de la cartographie pvdisplay -m.

(d'accord, d'accord, la différence de nombre peut être négligeable. Mais au moins pensez-y :)

La charge de travail créée par hdparm -T n'est pas représentative pour presque tous les cas d'utilisation, à l'exception des lectures en continu à partir d'un seul gros fichier. De plus, si les performances sont un problème, n'utilisez pas raid5.

Vous pouvez déterminer où hdparm passe son temps avec blktrace (s'il est en E / S) ou oprofile (s'il est sur CPU). Connaître la configuration LVM serait également utile (pvdisplay, vgdisplay, lvdisplay).