Migliorare il multipath SAS alle performance JBOD su Linux

Sto cercando di ottimizzare un setup di archiviazione su alcuni hardware Sun con Linux. Qualsiasi pensiero sarebbe stato molto apprezzato.

Abbiamo il seguente hardware:

  • Sun Blade X6270
  • 2 * Controllori LSISAS1068E SAS
  • 2 * Sun J4400 JBODs con dischi da 1 TB (24 dischi per JBOD)
  • Fedora Core 12
  • 2.6.33 kernel di rilascio da FC13 (provato anche con ultimo kernel 2.6.31 da FC12, risultati identici)

Ecco il foglio dati per l'hardware SAS:

http://www.sun.com/storage/storage_networking/hba/sas/PCIe.pdf

Utilizza le tracce PCI Express 1.0a e 8x. Con una width di banda di 250 MB / sec per corsia, dobbiamo essere in grado di eseguire 2000 MB / sec per controller SAS.

Ogni controller può eseguire 3 Gb / sec per port e dispone di due PHY a 4 porte. Ci connettiamo entrambi PHY da un controller a un JBOD. Quindi tra JBOD e controller abbiamo 2 porte SYS * 3 Gb / sec = 24 Gb / sec di width di banda, che è più che la width di banda PCI Express.

Con l'abilitazione della memorizzazione di scrittura e quando si eseguono grandi scritture, ciascun disco può sostenere circa 80 MB / sec (vicino all'avvio del disco). Con 24 dischi, questo significa che dovremmo essere in grado di eseguire 1920 MB / sec per JBOD.

 multipath {
   rr_min_io 100
   uid 0
   path_grouping_policy multibus
   manuale di failback
   path_selector "round-robin 0"
   priorità del peso rr
   alias somealias
   no_path_retry queue
   modalità 0644
   gid 0
   wwid somewwid
 }

Ho provato i valori di 50, 100, 1000 per rr_min_io, ma non sembra fare molta differenza.

Insieme a variazioni di rr_min_io ho provato ad aggiungere un certo ritardo tra l'avvio del dd per impedire a tutti di scrivere contemporaneamente sulla stessa PHY, ma questo non ha alcuna differenza, quindi penso che gli I / O si stanno distribuendo correttamente.

Secondo / proc / interrupts, i controllori SAS stanno utilizzando un interrupt di "IR-IO-APIC-fasteoi". Per qualche motivo solo il nucleo # 0 della macchina sta gestendo questi interruzioni. Posso migliorare le performance leggermente assegnando un nucleo separato per gestire gli interrupt per each controller SAS:

 echo 2> / proc / irq / 24 / smp_affinity
 echo 4> / proc / irq / 26 / smp_affinity

L'utilizzo di dd per scrivere sul disco genera "interrupt di chiamata delle funzioni" (nessuna idea di cosa si tratta), che vengono gestite dal nucleo # 4, in modo da mantenere anche altri processi fuori da questo nucleo.

Ho eseguito 48 dd (uno per each disco), assegnandoli ai core che non si occupano di interrupt così:

 taskset -c somecore dd se = / dev / zero di = / dev / mapper / mpathx oflag = diretto bs = 128M

oflag = diretta impedisce qualsiasi tipo di cache buffer di partecipare.

Nessuno dei miei nuclei sembra fuoriuscito. I nuclei che interagiscono con gli interrupt sono in gran parte inattivo e tutti gli altri core sono in attesa di I / O come ci si aspetterebbe.

 Cpu0: 0,0% noi, 1,0% occhi, 0,0% ni, 91,2% id, 7,5% wa, 0,0% hi, 0,2% si, 0,0% st
 Cpu1: 0,0% noi, 0,8% sy, 0,0% ni, 93,0% id, 0,2% wa, 0,0% ciao, 6,0% si, 0,0% st
 Cpu2: 0,0% noi, 0,6% occhi, 0,0% ni, 94,4% id, 0,1% wa, 0,0% ciao, 4,8% si, 0,0% st
 Cpu3: 0,0% noi, 7,5% occhi, 0,0% ni, 36,3% id, 56,1% wa, 0,0% ciao, 0,0% si, 0,0% st
 Cpu4: 0,0% noi, 1,3% occhi, 0,0% ni, 85,7% id, 4,9% wa, 0,0% ciao, 8,1% si, 0,0% st
 Cpu5: 0,1% us, 5,5% occhi, 0,0% ni, 36,2% id, 58,3% wa, 0,0% ciao, 0,0% si, 0,0% st
 Cpu6: 0,0% noi, 5,0% occhi, 0,0% ni, 36,3% id, 58,7% wa, 0,0% ciao, 0,0% si, 0,0% st
 Cpu7: 0,0% noi, 5,1% occhi, 0,0% ni, 36,3% id, 58,5% wa, 0,0% ciao, 0,0% si, 0,0% st
 Cpu8: 0,1% us, 8,3% occhi, 0,0% ni, 27,2% id, 64,4% wa, 0,0% hi, 0,0% si, 0,0% st
 Cpu9: 0,1% noi, 7,9% occhi, 0,0% ni, 36,2% id, 55,8% wa, 0,0% ciao, 0,0% si, 0,0% st
 Cpu10: 0,0% ci, 7,8% occhi, 0,0% ni, 36,2% id, 56,0% wa, 0,0% ciao, 0,0% si, 0,0% st
 Cpu11: 0,0% noi, 7,3% occhi, 0,0% ni, 36,3% id, 56,4% wa, 0,0% ciao, 0,0% si, 0,0% st
 Cpu12: 0,0% noi, 5,6% occhi, 0,0% ni, 33,1% id, 61,2% wa, 0,0% ciao, 0,0% si, 0,0% st
 Cpu13: 0,1% us, 5,3% occhi, 0,0% ni, 36,1% id, 58,5% wa, 0,0% ciao, 0,0% si, 0,0% st
 Cpu14: 0,0% noi, 4,9% occhi, 0,0% ni, 36,4% id, 58,7% wa, 0,0% ciao, 0,0% si, 0,0% st
 Cpu15: 0,1% us, 5,4% occhi, 0,0% ni, 36,5% id, 58,1% wa, 0,0% hi, 0,0% si, 0,0% st

Dato tutto questo, il throughput riportto eseguendo "dstat 10" è nell'intervallo 2200-2300 MB / sec.

Data la math sopra mi aspetterei qualcosa nel range di 2 * 1920 ~ = 3600+ MB / sec.

Qualcuno ha idea di where è andata la mia width di banda mancante?

Grazie!

  • Corretto modo per creare un zfs fuori da una directory esistente?
  • Sun Solaris - Scopri il numero di processri e core
  • Rimozione automatica di scorrimento senza attrezzi per il computer porttile per X4150
  • C'è un command Informix per riparare il database?
  • Identificare il disco rigido fallito nel RAID
  • Active Directory memberOf LDAP syntax
  • Risorse individuali di arrays di Sun Grid Engine Array
  • La reimpostazione della password SP utilizzando il ponticello P20 non funziona con Sun Fire x4600 M2
  • One Solution collect form web for “Migliorare il multipath SAS alle performance JBOD su Linux”

    Bella, domanda ben preparata 🙂

    Io sono un uomo di velocità e non credo e penso che tu sia sul denaro per essere onesto. Ho aspettato quasi di vedere il tuo rendimento più basso di quello che è, ma quello che penso che tu abbia là è un accumulo in minori, e le aspettative, inefficienze. Per esempio, è molto difficile per un bus PCIe arrivare al 100% tutto il tempo, meglio assumere un tasso globale del 90% in totale. Dato il jitter questo farà che significherà anche che i PHY non saranno 100% "alimentati" per tutto il tempo in modo da perdere un po 'lì, uguali per la cache, i dischi, gli interrupt non-coalraced, la schedulazione di IO ecc. l'inefficienza minore è tempi minori di inefficienza … e così via, finisce per essere più delle inefficienze previste per il 5-10% da soli. Ho visto questo tipo di cose con i server HP DL che parlano con le loro caselle MSA SAS usando W2K3 e poi essere NLB su più NICs – frustrante ma comprensibile immagino. Questo è il mio 2c comunque, mi dispiace che non sia troppo positivo.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.