Maintenant, avec le temps, j'ai réussi à résoudre ce problème moi-même, donc je peux au moins faire le suivi moi-même pour la postérité.
Malheureusement, j’ai perdu le problème initial lors d’une mise à niveau du noyau, mais j’en ai gagné un nouveau, encore pire en termes de performances et tout aussi difficile à détecter. Les techniques que j'ai trouvées sont les suivantes:
Tout d'abord, blktrace / blkparse est un outil que j'ai trouvé très utile. Il permet de suivre l'avancement 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, de sorte que la gestion du stockage de la trace ne commence pas à se tracer elle-même.
Cela n’a aidé que jusqu’à présent, alors j’ai donc 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 suivre le processus peu performant dans l'espace du noyau, de voir ce qu'il faisait et où il était bloqué Compiler un noyau de débogage permet également de travailler WCHAN sortie pour ps De plus, cela peut fonctionner comme un moyen plus facile de voir ce qu’un processus fait dans le noyau, au moins pour les cas plus simples.
J'espérais aussi LatenceHaut pour être utile, mais je l’ai trouvé assez bogué, et aussi qu’il ne affichait que des raisons de latence trop "élevées" pour être vraiment utiles, malheureusement.
De plus, je l’ai trouvé plus utile que iostat simplement afficher 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’arbre source du noyau pour le format du stat fichier. Le regarder à intervalles rapprochés m'a permis de voir le timing et la taille exacts des rafales d'E / S et autres.
En fin de compte, j’ai découvert que le problème que j’ai eu après la mise à niveau du noyau a été causé par pages stables , une fonctionnalité introduite dans Linux 3.0, entraînant, dans mon cas, la base de données Berkeley à s’arrêter pendant de longues périodes lorsqu’elle salit des pages dans ses fichiers de région mmap'ed. Bien qu’il semble possible de corriger cette fonctionnalité et que les problèmes qu’elle pose soient résolus dans Linux 3.9, j’ai résolu le pire problème que j’avais eu pour le moment en patcher Berkeley DB me permettre de mettre ses fichiers de région dans un répertoire différent (dans mon cas /dev/shm ), me permettant d’éviter complètement le problème.
