Debug della latenza I / O di Linux

Sto riscontrando alcuni problemi di I / O su un paio di sistemi Linux che gestisco. Si manifestano in quanto i processi spesso si bloccano per alcuni secondi in semplici syscalls come open (), unlink () o close () sui file (il che è un problema perché alcuni dei programmi coinvolti richiedono una latenza I / O piuttosto bassa per funzionare propriamente). È vero che i sistemi in questione subiscono un carico I / O moderato, ma non riesco quasi a pensare che basterebbe giustificare tempi di latenza così enormi. A volte, il completamento delle chiamate può richiedere più di 15 secondi (anche se più spesso potrebbero richiedere 1 o 2 o 3 secondi circa).

La mia domanda è: come posso sapere perché questo accade? Quello che vorrei è uno strumento che potrebbe dirmi quali sono i processi in questione bloccati nel kernel e perché ciò su cui dormono è occupato, cosa sta succedendo con esso e cose del genere. Esiste un tale strumento o esiste un altro modo di provare a eseguire il debug di ciò che accade?

In alternativa, ovviamente, se hai qualche idea su cosa stia realmente accadendo, come può essere evitato?

Per la cronaca, il filesystem che uso è XFS.

A tempo debito, sono riuscito a risolverlo da solo, quindi posso almeno seguirlo da solo per i posteri.

Sfortunatamente, ho perso il problema originale in un aggiornamento del kernel, ma ne ho guadagnato uno nuovo, anche peggio in termini di prestazioni e altrettanto difficile da rintracciare. Le tecniche che ho trovato erano le seguenti:

Prima di tutto, blktrace/ blkparseè uno strumento che ho trovato molto utile. Consente di tracciare l'avanzamento delle singole richieste I / O con molti dettagli utili, come il processo che ha inviato la richiesta. È utile attivare l'output tmpfs, in modo che la gestione dell'archiviazione della traccia non inizi a tracciare se stessa.

Ciò ha aiutato solo finora, quindi ho compilato un kernel con più funzionalità di debug. In particolare, ho trovato ftraceabbastanza utile, dal momento che mi ha permesso di tracciare il processo poco performante all'interno dello spazio del kernel, per vedere cosa faceva e dove si bloccava. Anche la compilazione di un kernel di debug fornisce un WCHANoutput funzionante ps, che può funzionare come un modo più semplice per vedere cosa sta facendo un processo all'interno del kernel, almeno per i casi più semplici.

Speravo anche che LatencyTop fosse utile, ma l'ho trovato abbastanza difettoso, e inoltre mostrava solo motivi di latenza che erano troppo "di alto livello" per essere veramente utili, sfortunatamente.

Inoltre, ho trovato più utile che iostatsemplicemente visualizzare il contenuto di /sys/block/$DEVICE/stata intervalli molto ravvicinati, semplicemente in questo modo:

while :; do cat /sys/block/sda/stat; sleep .1; done

Vedi Documentation/iostats.txtnella struttura dei sorgenti del kernel per il formato del statfile. La visualizzazione ad intervalli ravvicinati mi ha permesso di vedere i tempi e le dimensioni esatte delle esplosioni di I / O e cose simili.

Alla fine, ho scoperto che il problema che avevo dopo l'aggiornamento del kernel era causato da pagine stabili , una funzionalità introdotta in Linux 3.0, che causava, nel mio caso, l'arresto di Berkeley DB per periodi prolungati quando sporcava le pagine nel suo mmap'ed file regionali. Mentre sembra possibile correggere questa funzionalità e anche che i problemi che causa potrebbero essere risolti in Linux 3.9, ho risolto il problema peggiore che ho avuto per ora patch Berkeley DB per permettermi di mettere i suoi file regionali in una directory diversa (nel mio caso /dev/shm), permettendomi di evitare del tutto il problema.

Secondo la mia esperienza, lo strumento statistico più semplice e dettagliato che è possibile installare per tracciare misteriosi problemi di prestazioni del sistema è http://freecode.com/projects/sysstat aka. sar

sicuramente vuoi anche guardare l'output del comando iostat, in particolare quanto% iowait dovrebbe essere inferiore al 5-10% con il normale carico del sistema (inferiore a 1.0 o giù di lì).

guarda l'output ps se nella colonna STAT vedi gli stati D che indicano che quei processi sono bloccati e in attesa di IO, molto probabilmente un problema hardware con il controller o il disco, controlla le statistiche SMART così come dmesg e syslog per indizi

controlla il registro sar e identifica le ore di punta, se mai ciò accade, e cerca di abbinare quelle ore a lavori cron ad uso intensivo del disco, ad esempio backup in rete

puoi confrontare le prestazioni del tuo disco con bonnie ++

Pensavo di menzionare lo strace anche se questa domanda è ormai vecchia di mesi. Può aiutare qualcuno con un problema simile a trovare questa pagina.

provare.

strace "application"

puoi anche fare

strace -e read,write "application"

per mostrare solo gli eventi di lettura / scrittura.

L'applicazione si caricherà normalmente (anche se un po 'più lentamente all'avvio) e puoi usarla normalmente per innescare il problema. L'output verrà visualizzato nella shell utilizzata per avviare la strace.

La cosa buona di strace è che puoi vedere la funzione / chiamata del kernel più recente nel momento in cui l'applicazione avvia il rallentamento. Potresti scoprire che se i tuoi /homeaccount sono su NFS, l'applicazione ha qualche difficoltà con l'I / O dei file su NFS per qualche motivo.