Maintenant, en temps voulu, j'ai réussi à résoudre ce problème moi-même, donc je peux au moins le suivre moi-même pour la postérité.
Malheureusement, j'ai perdu le problème d'origine lors d'une mise à niveau du noyau, mais j'en ai gagné un nouveau à la place, encore pire en termes de performances et tout aussi difficile à localiser. Les techniques que j'ai trouvées étaient les suivantes :
Tout d'abord, blktrace /blkparse est un outil que j'ai trouvé très utile. Il permet de suivre la progression des demandes d'E/S individuelles avec de nombreux détails utiles, tels que le processus qui a soumis la demande. Il est utile de mettre la sortie sur tmpfs , afin que la gestion du stockage de la trace ne commence pas à se tracer.
Cela n'a aidé que jusqu'à présent, alors j'ai compilé un noyau avec plus de fonctionnalités de débogage. En particulier, j'ai trouvé ftrace très utile, car cela m'a permis de retracer le processus peu performant dans l'espace du noyau, de voir ce qu'il a fait et où il s'est bloqué. La compilation d'un noyau de débogage fournit également WCHAN fonctionnel sortie pour ps également, ce qui peut être un moyen plus simple de voir ce qu'un processus fait à l'intérieur du noyau, du moins pour les cas les plus simples.
J'espérais aussi que LatencyTop soit utile, mais je l'ai trouvé assez bogué, et aussi qu'il n'affichait que des raisons de latence trop "de haut niveau" pour être vraiment utiles, malheureusement.
De plus, je l'ai trouvé plus utile que iostat pour visualiser simplement le contenu de /sys/block/$DEVICE/stat à intervalles très rapprochés, simplement comme ceci :
while :; do cat /sys/block/sda/stat; sleep .1; done
Voir Documentation/iostats.txt dans l'arborescence des sources du noyau pour le format du stat dossier. Le visionner à intervalles rapprochés m'a permis de voir le moment et la taille exacts des rafales d'E/S, etc.
En fin de compte, j'ai découvert que le problème que j'avais après la mise à niveau du noyau était causé par des pages stables, une fonctionnalité introduite dans Linux 3.0, provoquant, dans mon cas, l'arrêt de Berkeley DB pendant de longues périodes lors de la saleté des pages dans son mmap'ed fichiers de région. Bien qu'il semble possible de corriger cette fonctionnalité, et aussi que les problèmes qu'elle cause pourraient être résolus dans Linux 3.9, j'ai résolu le pire problème que j'ai eu pour l'instant en corrigeant Berkeley DB pour me permettre de mettre ses fichiers de région dans un répertoire différent (dans mon cas /dev/shm ), ce qui me permet d'éviter complètement le problème.
D'après mon expérience, l'outil statistique le plus simple et le plus détaillé que vous pouvez installer pour détecter les mystérieux problèmes de performances du système est http://freecode.com/projects/sysstat alias. sar
bien sûr, vous voulez également regarder la sortie de la commande iostat, en particulier combien votre% iowait doit être inférieur à 5-10% sous une charge système normale (inférieure à 1,0 environ).
regardez la sortie ps si dans la colonne STAT vous voyez des statuts D qui signifient que ces processus sont verrouillés et en attente d'E/S, très probablement un problème matériel avec le contrôleur ou le disque, vérifiez les statistiques S.M.A.R.T ainsi que dmesg et syslog pour des indices
vérifiez le journal sar et identifiez les heures de pointe si jamais cela se produit et essayez de faire correspondre ces heures avec des tâches cron gourmandes en disque, par exemple des sauvegardes sur le réseau
vous pouvez comparer les performances de votre disque avec bonnie++
Je pensais mentionner strace même si cette question date maintenant de plusieurs mois. Cela peut aider quelqu'un avec un problème similaire qui trouve cette page.
essayez.
strace "application"
vous pouvez aussi faire
strace -e read,write "application"
pour afficher uniquement les événements de lecture/écriture.
L'application se chargera normalement (bien qu'un peu plus lentement au lancement) et vous pourrez l'utiliser normalement pour déclencher le problème. La sortie apparaîtra dans le shell que vous avez utilisé pour lancer strace.
La bonne chose à propos de strace est que vous pouvez voir l'appel de fonction/noyau le plus récent au moment où l'application déclenche le ralentissement. Vous pouvez constater que si votre /home comptes sont sur NFS, l'application rencontre des difficultés avec les E/S de fichiers sur NFS pour une raison quelconque.