Débogage de la latence des E / S Linux

J'ai des problèmes d'E / S sur quelques systèmes Linux que j'administre. Ils se manifestent en ce que les processus bloquent souvent pendant plusieurs secondes dans des systèmes aussi simples que open (), unlink () ou close () sur des fichiers (ce qui pose un problème car certains programmes impliqués nécessitent une latence d'E / S assez faible pour fonctionner correctement). Il est vrai que les systèmes en question subissent une charge d’E / S modérée, mais j’ai peine à penser que cela suffirait à justifier des temps de latence aussi énormes. Parfois, les appels peuvent durer plus de 15 secondes (bien que plus souvent, ils durent 1, 2 ou 3 secondes environ).

Ma question est la suivante: comment puis-je savoir pourquoi cela se produit? Ce que j'aimerais, c'est un outil qui pourrait me dire en quoi les processus en question sont bloqués dans le noyau, et pourquoi ce sur quoi ils dorment est occupé, ce qui se passe, et ce genre de choses. Existe-t-il un tel outil ou existe-t-il un autre moyen de déboguer ce qui se passe?

Alternativement, bien sûr, si vous avez une idée de ce qui réellement est passe, comment peut-il être évité?

Pour mémoire, le système de fichiers que j'utilise est XFS.

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.

D'après mon expérience, l'outil statistique le plus simple et le plus détaillé que vous pouvez installer pour identifier des problèmes de performances système mystérieux est: http://freecode.com/projects/sysstat alias. sar

bien sûr, vous souhaitez également consulter la sortie de la commande iostat, en particulier combien votre% iowait devrait être inférieur à 5-10% sous la charge normale du système (inférieure à 1,0 ou plus).

examinez la sortie ps si, dans la colonne STAT, vous voyez des statuts D signifiant que ces processus sont verrouillés et attendent IO, très probablement un problème matériel avec le contrôleur ou le disque, vérifiez les statistiques de S.M.A.R.T ainsi que dmesg et syslog pour obtenir des indices.

Consultez le journal sar et identifiez les heures de pointe, le cas échéant, et essayez de faire correspondre ces heures aux travaux intensifs sur disque, par exemple les sauvegardes sur réseau

vous pouvez évaluer les performances de votre disque avec Bonnie ++

Je pensais mentionner strace même si cette question a maintenant plusieurs mois. Cela peut aider quelqu'un avec un problème similaire qui trouve cette page.

essayer.

strace "application"

tu peux aussi faire

strace -e read,write "application"

afficher uniquement les événements en lecture / écriture.

L'application se chargera normalement (bien qu'un peu plus lentement à démarrer) 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 le dernier appel de fonction / noyau au moment où l'application déclenche le ralentissement. Vous constaterez peut-être que si votre /home les comptes sont sur NFS, l’application rencontre des difficultés avec les entrées / sorties sur NFS pour une raison quelconque.