Collo di bottiglia di I / O Linux con data mover

Ho una macchina a 24 core con 94,6 GB di RAM con Ubuntu server 10.04. La confezione presenta un'alta percentuale di iowait, a differenza di un altro server che ha (4 core) che eseguono gli stessi tipi e quantità di processi. Entrambe le macchine sono collegate a un file server VNX Raid, la macchina a 24 core tramite 4 schede FC e l'altra tramite 2 schede Ethernet Gigabit. La macchina a 4 core attualmente supera le prestazioni della macchina a 24 core, ha un maggiore utilizzo della CPU e una percentuale inferiore di iowait.

In 9 giorni di operatività,% iowait è in media al 16% ed è abitualmente superiore al 30%. Il più delle volte l'utilizzo della CPU è molto basso, circa il 5% (a causa dell'elevato iowait). Vi è ampia memoria libera.

Una cosa che non capisco è il motivo per cui tutti i dati sembrano attraversare il dispositivo SDC piuttosto che passare direttamente dai motori di spostamento dei dati:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.11    0.39    0.75   16.01    0.00   76.74

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               0.00         0.00         0.00       1232          0
sdb               0.00         0.00         0.00       2960          0
sdc               1.53        43.71        44.54   36726612   37425026
dm-0              0.43        27.69         0.32   23269498     268696
dm-1              1.00         1.86         7.74    1566234    6500432
dm-2              0.96         1.72         5.97    1442482    5014376
dm-3              0.49         9.57         0.18    8040490     153272
dm-4              0.00         0.00         0.00       1794         24
dm-5              0.00         0.00         0.00        296          0

Un altro pezzo del puzzle è che le attività vanno frequentemente in modalità di sonno ininterrotta (in alto), probabilmente anche a causa del blocco di io.

Cosa posso guardare per aiutare a diagnosticare il problema? Perché tutti i dati passano attraverso / dev / sdc? È normale?

AGGIORNARE:

La connessione di rete e la capacità di lettura / scrittura di VNX sono state escluse come strozzature. Siamo in grado di raggiungere una velocità di 800 MB / s con le 4 schede di rete collegate (round-robin). Le schede Fibre Channel non sono ancora in uso. Il VNX è in grado di gestire l'IO (dischi RAID6, 30x2TB 7,2kRPM per pool in due pool (60 dischi in totale), circa il 60% letto).

Ignora sopra su dm e sdc, sono tutti dischi interni e non fanno parte del problema.

Pensiamo che il problema potrebbe riguardare i montaggi nfs o TCP (abbiamo 5 montaggi su 5 partizioni sul VNX), ma non sappiamo esattamente cosa. Qualche consiglio?

Prima di tutto se le tue CPU (e dannatamente! Sono 24) mangiano i dati più velocemente di ciò che può fornire l'archiviazione dei dati, quindi ottieni iowait. Questo è quando il kernel mette in pausa un processo durante un blocco io (una lettura che arriva troppo lentamente o una scrittura di sincronizzazione).
Quindi controlla che l'archiviazione sia in grado di fornire un throughput sufficiente per 24 core.

Ad esempio, supponiamo che il tuo spazio di archiviazione sia in grado di fornire una velocità di trasmissione di 500 MB / s, che tu sia connesso tramite una linea Ethernet (bond) da 2 Gigabit, la rete limiterà già la velocità massima a circa 100-180 MB / s. Se il tuo processo consuma dati alla velocità di 50 MB / se esegui 4 thread sul tuo computer a 4 core: 4 x 50 MB / s = 200 MB / s consumati. Se la rete è in grado di supportare 180 MB / s, la latenza non sarà elevata e le CPU verranno caricate. La rete qui è un piccolo collo di bottiglia.
Ora se ridimensionate fino a 24 core e 24 thread, avreste bisogno di 1200 MB / s, anche se cambiate il cablaggio per consentire tale throughput, il vostro sistema di archiviazione non fornisce più di 500 MB / s, diventa un collo di bottiglia.

Quando si tratta di aspettare, i colli di bottiglia possono essere ovunque. Non solo sui livelli fisici, ma anche nei buffer di spazio software e kernel. Dipende molto dai modelli di utilizzo. Ma poiché i colli di bottiglia del software sono molto più difficili da identificare, di solito è preferibile controllare il throughput teorico sull'hardware prima di indagare sugli stack del software.

Come detto, si verifica un errore quando un processo effettua una lettura e i dati impiegano del tempo per arrivare o quando effettua una scrittura di sincronizzazione e il riconoscimento della modifica dei dati impiega il suo tempo. Durante una scrittura di sincronizzazione, il processo entra in modalità di sospensione ininterrotta in modo che i dati non vengano danneggiati. V'è un pratico strumento per vedere quali chiamata fa un processo di appendere: latencytop. Non è l'unico nel suo genere, ma puoi provarlo.

Nota: per tua informazione, dm sta per Device Mapper e non per i data mover.

Prima di tutto, santo inferno che è molto ferro! :)

Sfortunatamente, poiché la tua configurazione sembra molto complessa, non credo che nessuno sarà in grado di fornire immediatamente "C'è il tuo problema!" risposta, a meno che non abbiano fatto qualcosa con una configurazione estremamente simile o identica e abbiano riscontrato lo stesso problema. Quindi, mentre questo testo è etichettato da SU come una "Risposta", dovresti probabilmente considerarlo più come un "Suggerimento". E non posso inserirlo nei commenti perché sono troppe parole. :S

Senza la conoscenza di come l'hardware è mappato ai dispositivi, è difficile dire perché l'I / O sta andando in un posto e non in un altro. Come si montano i dispositivi? I tuoi programmi accedono sd*direttamente ai dispositivi o tutti i tuoi filesystem sono montati sui dmdispositivi e tutti gli accessi ai file avvengono da lì?

Altre cose che devo chiedere:

• Che tipo di RAID è? Se stai calcolando i bit di parità con RAID5 o RAID6, si spera che sia gestito dall'hardware del server raid ... in caso contrario, i server di elaborazione lo stanno facendo ... che è subottimale e può causare latenza I / O se fatto nel software.

• Hai isolato una delle principali differenze tra i due server nel tuo messaggio. Uno sta usando il canale in fibra e uno sta usando Ethernet. Il Fibre Channel dovrebbe fornire una migliore latenza e larghezza di banda, ma forse anche questo è un problema: se fornisce un sacco di throughput, potrebbe rendere il server RAID molto impegnato da solo ... e la congestione porta al riempimento di buffer / cache, che aumenta la latenza, causando maggiori attese di I / O.

E 'quasi come se si potrebbe avere un problema troppo grosso buffer con i tuoi array di dischi - lo sai? I controller RAID hardware normalmente hanno una grande quantità di cache integrata, no? Quindi, mentre l'I / O per i media viene messo in coda e le cache si riempiono di pagine sporche, alla fine l'intera cosa è satura (se la memoria meccanica non riesce a tenere il passo con il carico) e la latenza salpa sul tetto ... sicuramente puoi produrre più carico con 24 core + FC che con 4 core + GbE :) Controlla il server RAID e vedi quanto sono occupati i dischi ... gran parte degli "I / O" potrebbero essere solo pacchetti di controllo, ecc. I non sono sicuro di come funzioni FC, ma se è qualcosa di simile a TCP, vedrai le ritrasmissioni se le latenze sono troppo alte.

Ad esempio, se fai una domanda al telefono e loro non rispondono per qualche secondo, dici "Ciao?" - i protocolli di rete (e FC è solo un protocollo di rete) fanno la stessa cosa, solo in tempi più brevi. Ma ovviamente quel extra "Ciao?" è costoso nel contesto del networking perché aggiunge ancora più dati a una pipe già congestionata.

In chiusura, un consiglio generale:

Quando si esegue il debug di latenza / I / O attese / problemi di velocità effettiva, misurare sempre . Misura ovunque. Misura sul filo, misura ciò che i programmi stessi stanno facendo, misura alla fine dell'elaborazione, misura sul server RAID, ecc. Non limitarti a guardarlo da una prospettiva: prova a considerare ogni singolo componente del sistema che è responsabile per l'elaborazione, la lettura o la scrittura di qualsiasi dato nella pipeline. Smonta una transazione o un'unità di lavoro discreta e analizza esattamente il percorso che prende attraverso l'hardware e misura in ciascun componente distinto per vedere se ci sono colli di bottiglia o luoghi in cui vi è un'indebita latenza, ecc. Un mio amico ha chiamato questo "peeling back the onion ", e da allora uso la frase per fare riferimento al compito di debug di un flusso di dati.

Una piccola aggiunta. In questo caso, potresti voler esaminare la sintonizzazione a livello di blocco e gli scheduler I / O. Non ho familiarità con Ubuntu, ma ci sono una buona quantità di manopole per le prestazioni di archiviazione da modificare. Ciò vale sicuramente per l'archiviazione e i database SAN.

• Dai un'occhiata allo scheduler I / O di sistema . CFQ è predefinito, ma noop e scadenza sono scelte comuni per i carichi di lavoro del database.
• Vedi questo link per alcuni altri parametri di ottimizzazione che potrebbero essere d'aiuto.
• Citi NFS e blocca l'archiviazione. Se blocco, quali filesystem sono in uso? L'attesa I / O suona come una situazione di blocco della scrittura da qui. Le barriere di scrittura sono abilitate? Rimonta il tuo filesystem con nobarrier. ( Suggerimento per Ubuntu )

Alcuni collegamenti relativi ai guasti del server ...

Linux - regolazione del controller RAID hardware reale (scsi e cciss)

Grazie a tutti per le idee e il contributo. Il problema era legato a una combinazione di una configurazione di collegamento ethernet non ottimale, combinata con un modulo I / O difettoso sul VNX stesso. La velocità di I / O è ora vicina a dove ci aspettiamo. È interessante notare che i test di scrittura e lettura di file dd e benchmark iozone non sono stati in grado di rilevare questo, e potrebbero leggere e scrivere quasi alla velocità prevista.

Modificherò con ulteriori informazioni abbastanza presto, ma prima vorrei dire che non dovresti lasciare che l'output dm- * di iostat ti confonda. Device-mapper è un dispositivo passthru nel kernel proprio come md * (md0, md1, ecc.), Quindi ti preoccupi solo dei dispositivi sottostanti. Tutti i dati che passano ai tuoi dischi passano attraverso dm / md sulla strada e i totali effettivi (byte, secondi, ecc.) Sono accurati, ma l'utilità è fuorviante.

Inoltre, è una quantità molto grande di memoria. Le cose divertenti iniziano ad accadere così in alto (io stesso eseguo 2x64s e 2x96s), specialmente se hai un processo che occupa più della metà della ram. Leggi questo articolo per ulteriori informazioni . L'articolo cita MySQL, ma si prega di notare che si tratta di nonmysql specifico. Ogni processo software comporterà penalità per l'accesso alla memoria di un altro processore fisico - pensa che 48 GB appartengano a un proc, 48 a un altro. Il processo può appartenere solo a un proc e per raggiungere la memoria dell'altro proc (dopo che sono stati esauriti i 48 GB), deve decidere di salvare alcuni dei suoi 48 in scambio o pagare un prezzo enorme per arrivare da e verso memoria di altri proc. L'articolo suggerisce di eseguire un comando numactl per forzare il software a non scambiarsi e invece a pagare la penalità. Personalmente ho visto enormi miglioramenti da questo. In altre parole, controlla se alcuni dei tuoi I / O cambieranno! Usa free -m (o simile) per questo. Se hai molta memoria libera, ma una quantità di swap non banale (diciamo il 10% in più), questo potrebbe benissimo essere il tuo problema.

Guardando questo dal punto di vista dello storage, hai un modo per misurare la latenza scsi? Il tempo di attesa del sistema operativo include un sacco di cose al di fuori del controllo della memoria, ma quando vado nella mia casella di memoria e vedo la latenza IO a 2 ms, so che indipendentemente da ciò che il server sta ottenendo internamente, i comandi scsi ricevono una risposta rapidamente e posso eliminare l'archiviazione come variabile.