J'essaie d'optimiser une configuration de stockage sur du matériel Sun avec Linux. Toute réflexion serait grandement appréciée.
Nous avons le matériel suivant:
- Sun Blade X6270
- 2 * contrôleurs SAS LSISAS1068E
- 2 * JBOD Sun J4400 avec disques de 1 To (24 disques par JBOD)
- Fedora Core 12
- 2.6.33 noyau de version de FC13 (également essayé avec le dernier noyau 2.6.31 de FC12, mêmes résultats)
Voici la fiche technique du matériel SAS:
http://www.sun.com/storage/storage_networking/hba/sas/PCIe.pdf
Il utilise PCI Express 1.0a, 8x voies. Avec une bande passante de 250 Mo / sec par voie, nous devrions être capables de faire 2000 Mo / sec par contrôleur SAS.
Chaque contrôleur peut faire 3 Gbit / s par port et possède deux PHY à 4 ports. Nous connectons les deux PHY d'un contrôleur à un JBOD. Ainsi, entre le JBOD et le contrôleur, nous avons 2 PHY * 4 ports SAS * 3 Gb / sec = 24 Gb / sec de bande passante, ce qui est plus que la bande passante PCI Express.
Avec la mise en cache d'écriture activée et lorsque vous effectuez des écritures importantes, chaque disque peut supporter environ 80 Mo / s (près du début du disque). Avec 24 disques, cela signifie que nous devrions être capables de faire 1920 Mo / sec par JBOD.
trajets multiples {
rr_min_io 100
uid 0
path_grouping_policy multibus
manuel de rétablissement
path_selector "round-robin 0"
priorités rr_weight
alias somealias
file d'attente no_path_retry
mode 0644
gid 0
wwid somewwid
}
J'ai essayé des valeurs de 50, 100, 1000 pour rr_min_io, mais cela ne semble pas faire beaucoup de différence.
Parallèlement à la variation de rr_min_io, j'ai essayé d'ajouter un certain délai entre le démarrage des dd pour éviter qu'ils n'écrivent tous sur le même PHY en même temps, mais cela ne fait aucune différence, donc je pense que les E / S se répartissent correctement.
Selon / proc / interrupts, les contrôleurs SAS utilisent un schéma d'interruption "IR-IO-APIC-fasteoi". Pour une raison quelconque, seul le noyau # 0 de la machine gère ces interruptions. Je peux améliorer légèrement les performances en attribuant un noyau distinct pour gérer les interruptions pour chaque contrôleur SAS:
echo 2> / proc / irq / 24 / smp_affinity écho 4> / proc / irq / 26 / smp_affinity
L'utilisation de dd pour écrire sur le disque génère des «interruptions d'appel de fonction» (aucune idée de ce qu'elles sont), qui sont gérées par le noyau # 4, donc je garde également les autres processus hors de ce noyau.
Je lance 48 dd (un pour chaque disque), en les affectant à des cœurs ne traitant pas d'interruptions comme ceci:
jeu de tâches -c somecore dd if = / dev / zero of = / dev / mapper / mpathx oflag = direct bs = 128M
oflag = direct empêche tout type de cache tampon de s'impliquer.
Aucun de mes noyaux ne semble épuisé. Les cœurs traitant les interruptions sont pour la plupart inactifs et tous les autres cœurs attendent les E / S comme on pourrait s'y attendre.
CPU0: 0,0% us, 1,0% sy, 0,0% ni, 91,2% id, 7,5% wa, 0,0% hi, 0,2% si, 0,0% st Cpu1: 0,0% us, 0,8% sy, 0,0% ni, 93,0% id, 0,2% wa, 0,0% hi, 6,0% si, 0,0% st Cpu2: 0,0% us, 0,6% sy, 0,0% ni, 94,4% id, 0,1% wa, 0,0% hi, 4,8% si, 0,0% st CPU3: 0,0% us, 7,5% sy, 0,0% ni, 36,3% id, 56,1% wa, 0,0% hi, 0,0% si, 0,0% st CPU4: 0,0% us, 1,3% sy, 0,0% ni, 85,7% id, 4,9% wa, 0,0% hi, 8,1% si, 0,0% st CPU5: 0,1% us, 5,5% sy, 0,0% ni, 36,2% id, 58,3% wa, 0,0% hi, 0,0% si, 0,0% st CPU6: 0,0% us, 5,0% sy, 0,0% ni, 36,3% id, 58,7% wa, 0,0% hi, 0,0% si, 0,0% st CPU7: 0,0% us, 5,1% sy, 0,0% ni, 36,3% id, 58,5% wa, 0,0% hi, 0,0% si, 0,0% st CPU8: 0,1% us, 8,3% sy, 0,0% ni, 27,2% id, 64,4% wa, 0,0% hi, 0,0% si, 0,0% st CPU9: 0,1% us, 7,9% sy, 0,0% ni, 36,2% id, 55,8% wa, 0,0% hi, 0,0% si, 0,0% st CPU10: 0,0% us, 7,8% sy, 0,0% ni, 36,2% id, 56,0% wa, 0,0% hi, 0,0% si, 0,0% st CPU11: 0,0% us, 7,3% sy, 0,0% ni, 36,3% id, 56,4% wa, 0,0% hi, 0,0% si, 0,0% st CPU12: 0,0% us, 5,6% sy, 0,0% ni, 33,1% id, 61,2% wa, 0,0% hi, 0,0% si, 0,0% st CPU13: 0,1% us, 5,3% sy, 0,0% ni, 36,1% id, 58,5% wa, 0,0% hi, 0,0% si, 0,0% st CPU14: 0,0% us, 4,9% sy, 0,0% ni, 36,4% id, 58,7% wa, 0,0% hi, 0,0% si, 0,0% st CPU15: 0,1% us, 5,4% sy, 0,0% ni, 36,5% id, 58,1% wa, 0,0% hi, 0,0% si, 0,0% st
Compte tenu de tout cela, le débit signalé en exécutant «dstat 10» se situe dans la plage de 2 200 à 2 300 Mo / s.
Compte tenu des calculs ci-dessus, je m'attendrais à quelque chose dans la plage de 2 * 1920 ~ = 3600+ Mo / sec.
Quelqu'un at-il une idée de l'endroit où ma bande passante manquante est allée?
Merci!
Réponses:
Belle question bien préparée :)
Je suis un homme de speed'n'feeds moi-même et je pense que vous êtes sur l'argent pour être honnête. Je m'attendais à moitié à voir votre débit inférieur à ce qu'il est, mais ce que je pense que vous avez là est une accumulation en inefficacités mineures et attendues. Par exemple, il est très difficile pour un bus PCIe d'atteindre 100% tout le temps, mieux vaut assumer un faible taux global de 90%. Compte tenu de la gigue que cela provoquera, cela signifiera également que les PHY ne seront pas 100% `` alimentés '' tout le temps, donc vous perdez un peu là-bas, de même pour le cache, les disques, les interruptions non charbon, la planification des E / S, etc. Fondamentalement il y a des périodes d'inefficacité mineures des périodes d'inefficacité mineures ... et ainsi de suite, cela finit par être plus que les 5 à 10% d'inefficacités attendues en soi. J'ai vu ce genre de chose avec les serveurs HP DL parler à leurs boîtiers MSA SAS en utilisant W2K3 et en étant NLB ' sur plusieurs cartes réseau - frustrant mais compréhensible je suppose. C'est mon 2c de toute façon, désolé ce n'est pas trop positif.
la source