Ora, 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 invece ne ho guadagnato uno nuovo, ancora peggiore in termini di prestazioni e altrettanto difficile da rintracciare. Le tecniche che ho trovato sono state le seguenti:
Prima di tutto, blktrace /blkparse è uno strumento che ho trovato molto utile. Consente di tracciare lo stato di avanzamento delle singole richieste di I/O con molti dettagli utili, come il processo che ha inviato la richiesta. È utile mettere l'output su tmpfs , in modo che la gestione dell'archiviazione della traccia non avvii la traccia stessa.
Ciò ha aiutato solo finora, quindi ho compilato un kernel con più funzionalità di debug. In particolare, ho trovato ftrace abbastanza utile, poiché mi ha permesso di tracciare il processo con prestazioni scadenti all'interno dello spazio del kernel, per vedere cosa ha fatto e dove si è bloccato. La compilazione di un kernel di debug fornisce anche WCHAN funzionante output per ps anche, 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 pieno di bug, e anche che mostrasse solo motivi di latenza che erano troppo "di alto livello" per essere veramente utili, sfortunatamente.
Inoltre, l'ho trovato più utile di iostat per visualizzare semplicemente il contenuto di /sys/block/$DEVICE/stat a intervalli molto ravvicinati, semplicemente così:
while :; do cat /sys/block/sda/stat; sleep .1; done
Vedi Documentation/iostats.txt nell'albero dei sorgenti del kernel per il formato del stat file. Visualizzarlo a intervalli ravvicinati mi ha permesso di vedere i tempi e le dimensioni esatte dei burst di I/O e cose del genere.
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 lunghi periodi quando sporcava le pagine nel suo mmap'ed file della regione. Sebbene sembri possibile eliminare questa funzionalità e anche che i problemi che causa potrebbero essere risolti in Linux 3.9, ho risolto il peggior problema che ho avuto per ora patchando Berkeley DB per consentirmi di inserire i suoi file di regione 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 puoi installare per tracciare misteriosi problemi di prestazioni del sistema è http://freecode.com/projects/sysstat aka. sar
di sicuro vuoi guardare anche l'output del comando iostat, specialmente quanto è il tuo% iowait dovrebbe essere inferiore al 5-10% sotto il normale carico di sistema (inferiore a 1.0 o giù di lì).
guarda l'output di ps se nella colonna STAT vedi stati D che significa che quei processi sono bloccati e in attesa di IO, molto probabilmente un problema hardware con il controller o il disco, controlla le statistiche S.M.A.R.T così come dmesg e syslog per gli indizi
controlla il registro sar e identifica gli orari di punta se mai ciò accade e cerca di far corrispondere quei tempi con cron job ad uso intensivo del disco, ad esempio backup sulla rete
puoi confrontare le prestazioni del tuo disco con bonnie++
Ho pensato di menzionare strace anche se questa domanda è ormai vecchia di mesi. Può aiutare qualcuno con un problema simile che trova questa pagina.
prova.
strace "application"
puoi anche fare
strace -e read,write "application"
per mostrare solo gli eventi di lettura/scrittura.
L'applicazione verrà caricata normalmente (anche se un po' più lenta da avviare) e potrai utilizzarla normalmente per attivare il problema. L'output apparirà nella shell che hai usato per avviare strace.
La cosa buona di strace è che puoi vedere la funzione/chiamata del kernel più recente nel momento in cui l'applicazione attiva il rallentamento. Potresti scoprire che se il tuo /home gli account sono su NFS, l'applicazione ha qualche difficoltà con l'I/O di file su NFS per qualche motivo.