J'ai une machine équipée d'une puce contrôleur SAS3008 LSI à 8 canaux, et les tests individuels des disques montrent que je peux écrire sur n'importe quel disque ou sur tous les disques à une vitesse comprise entre 174 Mo/sec et 193 Mo/sec avec une vitesse d'écriture soutenue :
Voici le résultat de la commande dd if=/dev/zero of=/dev/mapper/mpath?p1 bs=1G count=100 oflag=direct run in parallèle aux 12 disques :
107374182400 bytes (107 GB) copied, 556.306 s, 193 MB/s
107374182400 bytes (107 GB) copied, 566.816 s, 189 MB/s
107374182400 bytes (107 GB) copied, 568.681 s, 189 MB/s
107374182400 bytes (107 GB) copied, 578.327 s, 186 MB/s
107374182400 bytes (107 GB) copied, 586.444 s, 183 MB/s
107374182400 bytes (107 GB) copied, 590.193 s, 182 MB/s
107374182400 bytes (107 GB) copied, 592.721 s, 181 MB/s
107374182400 bytes (107 GB) copied, 598.646 s, 179 MB/s
107374182400 bytes (107 GB) copied, 602.277 s, 178 MB/s
107374182400 bytes (107 GB) copied, 604.951 s, 177 MB/s
107374182400 bytes (107 GB) copied, 605.44 s, 177 MB/sCependant, lorsque je réunis ces disques en un dispositif Raid 10 logiciel, j'obtiens une vitesse d'écriture d'environ 500 Mo/sec. Je m'attendais à obtenir environ le double, puisqu'il n'y a pas de pénalité pour accéder à ces disques en même temps.
J'ai remarqué que le processus md10_raid10 qui, je suppose, fait le raid logiciel lui-même, est proche de 80%, et qu'un cœur est toujours à 100% de temps d'attente, et 0% d'inactivité. Le noyau en question change cependant.
De plus, les performances baissent encore plus lorsque l'on utilise le cache de la mémoire tampon pour écrire dans le système de fichiers EXT4 monté plutôt que d'utiliser oflag=direct pour contourner le cache. Les disques signalent un taux d'occupation de 25% (selon la surveillance munin), mais les disques ne sont clairement pas en surchauffe, mais je crains que le périphérique md10 lui-même ne le soit.
Des suggestions sur la suite à donner à cette affaire ? Je tente une configuration matérielle de raid 10 pour comparer, bien que je ne puisse construire qu'une unité de 10 disques, semble-t-il - cela dit, j'espère obtenir 900 Mo/sec en écriture soutenue. Je mettrai à jour cette question au fur et à mesure que j'en découvrirai davantage.
Edit 1 :
Si j'utilise un dd dans une boucle serrée écrivant sur une partition ext4 montée sur ce périphérique, et que je n'utilise pas le buffer cache (oflag=direct), je peux obtenir jusqu'à 950 Mo/sec en pointe et 855 Mo/sec en continu avec quelques modifications des drapeaux de montage.
Si je lis également avec iflag=direct au même moment, je peux obtenir 480 Mo/sec en écriture et 750 Mo/sec en lecture maintenant.
Si j'écris sans oflag=direct, donc en utilisant le buffer cache, j'obtiens 230 Mo/sec en écriture et 1,2 Mo/sec en lecture, mais la machine semble très lente.
La question est donc de savoir pourquoi l'utilisation du cache de la mémoire tampon affecte si gravement les performances. J'ai essayé diverses stratégies de mise en file d'attente des disques, y compris l'utilisation de 'noop' au niveau du lecteur et la mise en place de 'deadline' ou 'cfq' sur le périphérique dm multivoie approprié, ou deadline sur tous, ou aucun sur le dm et deadline sur le lecteur de secours. Il semble que le disque de sauvegarde ne devrait pas avoir de date et que le périphérique multivoie devrait être celui que je veux, mais cela n'affecte pas du tout les performances, du moins dans le cas du cache de la mémoire tampon.
