De bons outils de dépannage du système sont tout. Les bons outils, cependant, sont plus difficiles à trouver. Heureusement, Linux est livré avec une multitude d'excellents programmes et utilitaires qui vous permettent de profiler, d'analyser et de résoudre les problèmes de comportement du système, des goulots d'étranglement des applications aux mauvaises configurations et même aux bogues. Tout commence par un outil capable de saisir les métriques nécessaires et de vous fournir les données dont vous avez besoin.
Health-check est un programme soigné qui peut surveiller et profiler les processus, afin que vous puissiez identifier et résoudre l'utilisation excessive des ressources - ou les problèmes associés. Là où il se démarque par rapport au reste de la foule, il vise à offrir simultanément de nombreuses facettes utiles des données système, afin que vous puissiez plus facilement rechercher des composants de vos systèmes, résoudre les problèmes de performances et résoudre les problèmes de configuration dans votre environnement. Plutôt que d'avoir à exécuter cinq outils en même temps, ou à faire cinq exécutions pour obtenir toutes les informations dont vous avez besoin, vous utilisez simplement le bilan de santé, et Bob est votre parent éloigné. Bon. D'accord, prêt ? Continuez.
Vérification de l'état en action
Avant de lancer l'utilitaire en colère, quelques petites notes. Premièrement, vous avez besoin des privilèges sudo pour exécuter cet outil, bien que vous puissiez exécuter l'application réelle dans le contexte d'autres utilisateurs du système (avec l'indicateur -u). Deuxièmement, vous avez besoin de comprendre comment Linux fonctionne pour utiliser les résultats - j'ai tout un tas d'articles sur ce sujet, liés plus loin ci-dessous.
Essentiellement, comme je l'ai souligné il y a un instant, le bilan de santé associe les fonctionnalités de divers programmes sous un même parapluie. Il mélange joliment les éléments que vous obtiendriez si vous exécutiez netstat, lsof, vmstat, iostat et examiniez diverses structures sous /proc et /sys. C'est un peu comme dstat, qui combine la puissance de vmstat, iostat et ifstat. Vous pouvez commencer par l'exécution simple (drapeau -b) :
sudo ./health-check -u "utilisateur" -b "binaire"
Il y aura beaucoup de sortie, même dans ce mode "brièvement", quelque chose comme :
Utilisation du processeur (en termes de 1 processeur) :
Utilisateur :34,24 %, Système :13,30 %, Total :47,54 % (charge élevée)
Tout d'abord, vous obtenez des chiffres CPU de base, normalisés par cœur (100 % =1 cœur complet). Le bilan de santé a des seuils internes par lesquels il indiquera s'il s'agit d'une charge faible, modérée ou élevée. C'est juste pour vous donner une idée de ce à quoi vous devez vous attendre. Les détails dépendront du type d'application et de la charge de travail que vous profilez. Il y aura des différences entre l'interface graphique et les outils de ligne de commande, les logiciels qui lisent d'une base de données à une autre qui ne le fait pas, les logiciels avec un grand nombre de bibliothèques partagées, l'utilisation de matériel, etc.
Défauts de page :
Processus PID Mineur/sec Majeur/sec Total/sec
1043 google-chrome 16156.46 0.25 16156.71
Nous avons longuement parlé des défauts de page dans le passé (liens dans la section plus de lecture ci-dessous). Si vous ne savez pas ce que votre application est censée faire, les chiffres ne vous diront pas grand-chose par eux-mêmes. Mais ils peuvent être très utiles pour des études comparatives, comme deux programmes différents du même type, ou deux versions différentes du même programme, ou le même programme s'exécutant sur deux plates-formes différentes.
Changements de contexte :
13 687,53 changements de contexte/s (très élevé)
La valeur de changement de contexte indique la fréquence à laquelle le noyau abandonne la file d'attente et bascule entre les tâches. Pour les processus interactifs (comme le navigateur), qui ont un composant interactif pour l'utilisateur, vous voulez en fait autant de changements de contexte que possible (les tâches s'exécutent le moins possible), car vous ne voulez pas que ces tâches monopolisent le processeur. En fait, un calcul long est un signe de travaux par lots. Ici, avoir peu de changement de contexte pourrait être une indication d'un problème avec une application interactive (GUI) comme le navigateur.
Opérations d'E/S de fichiers :
Opérations d'E/S par seconde :312,80 ouvertures, 283,49 fermetures, 768,71 lectures,
410,83 écritures
Les valeurs d'E/S sont utiles si vous disposez d'une ligne de base, et elles dépendent également de la pile d'E/S sous-jacente, y compris le matériel, le bus, le pilote, le choix du système de fichiers et toute autre opération de disque exécutée en même temps.
Analyse des appels du système d'interrogation :
google-chrome (1 043), interrogation :
1 555 appels expirés immédiats avec un délai d'attente nul (coups d'œil non bloquants)
1 appels interrogés expirés répétés avec une valeur non nulle délais d'attente
(interrogation légère)
1 125 appels interrogés répétés avec délai d'attente immédiat sans délai d'attente
(interrogations intensives)
Cette section est un autre indicateur de l'interactivité possible avec l'utilisateur du binaire profilé. Les appels système d'interrogation sont des appels système qui attendent que les descriptions de fichiers soient prêtes à effectuer des opérations d'E/S. En règle générale, cela indiquera les connexions réseau. Nous examinerons cela plus en détail lorsque nous effectuerons une analyse complète.
Mémoire :
Modification de la mémoire (K/seconde) :
PID Process Type Size RSS PSS
1043 google-chrome Stack 32.51 27.59 27.59 (croissance
modérément rapide)
1043 google-chrome Heap 67550.94 9092.51 9112.70 (croissance
très rapide)
1043 google-chrome Mapped 102764.33 27296.24 18781.80 (croissance très
rapide)
Pour la plupart des gens et la plupart des types d'applications, les opérations de mémoire ne seront pas si intéressantes. Les charges de travail gourmandes en mémoire ne sont pas habituelles dans les logiciels de bureau. Ils peuvent être assez importants pour les bases de données et les calculs complexes, ce que vous feriez normalement sur un système de classe serveur. Mais cet ensemble de chiffres peut être utilisé pour examiner les différences entre les plates-formes, les noyaux et les versions logicielles.
Connexions réseau ouvertes :
PID Process Proto Send Receive Address
1043 google-chrome UNIX 531.52 K 35.16 K /run/user/1000/bus
1043 google-chrome UNIX 0.00 B 88.56 K /run /systemd/journal/...
1043 douille google-chrome 64,51 K 0,00 B :[2737924]
1043 douille google-chrome 30,55 K 0,00 B :[2746558]
1043 douille google-chrome Douille 3.98K 0.00B :[2742865]
L'ensemble de nombres de connexions réseau vous donne des résultats similaires à ce que font netstat et lsof, mais vous obtenez également les valeurs d'envoi/réception, ce qui peut être très utile. Si vous savez ce que le programme est censé faire au niveau du réseau, vous pouvez profiler son exécution et rechercher d'éventuelles erreurs de configuration dans la pile réseau.
Exécution plus longue (détaillée)
Vous pouvez également opter pour plus de statistiques (par exemple, avec les drapeaux -c -f, pas de drapeau -b). Vous obtiendrez des résultats étendus pour chacune des sections dont nous avons parlé précédemment, ce qui peut vous donner un aperçu supplémentaire du comportement de votre logiciel. Si vous tracez des processus enfants et des fourches, vous pouvez voir la séquence d'exécution. Les statistiques du processeur seront répertoriées en fonction de l'utilisation, avec les plus gros contrevenants en haut.
Utilisation du processeur (en termes de 1 processeur) :
Processus PID USR% SYS% TOTAL% Durée
1715 vlc 47,04 8,17 55,21 14,71 (charge élevée)
1720 vlc 46,91 7,96 54,87 14,43 (charge élevée )
1723 vlc 46,77 7,96 54,74 14,35 (charge élevée)
...
1721 vlc 1,69 1,08 2,77 1,21 (charge légère)
1722 vlc 0,20 0,07 0,27 0,16 (charge très légère )
1726 vlc 0,07 0,00 0,07 0,02 (charge très légère)
1742 vlc 0,00 0,00 0,00 0,07 (inactif)
1732 vlc 0,00 0,00 0,00 0,02 (inactif)
1728 vlc 0,0 0,00 0,06 (inactif)
1719 vlc 0,00 0,00 0,00 0,06 (inactif)
Total 971,80 161,72 1133,52 (CPU entièrement chargé)
Dans l'exemple ci-dessus, en exécutant VLC (avec une lecture de clip HD d'environ 14 secondes), nous avons utilisé 1 133 % du temps CPU, ce qui se traduit par 11,33 cœurs CPU. Cela semble beaucoup, mais comme le système dispose de huit cœurs (threads), cela signifie en fait que seuls 1,5 cœurs ont été réellement utilisés pour la vidéo. Il serait également intéressant de savoir quels cœurs ont été utilisés.
Changements de contexte :
Processus PID Volontaire Involontaire Total
Ctxt Sw/Sec Ctxt Sw/Sec Ctxt Sw/Sec
1744 vlc 2500.09 1.15 2501.24 (high)
1723 vlc 1493.47 1.82 1495.29 ( élevé)
1740 vlc 1224.03 3.31 1227.33 (élevé)
1717 vlc 947.43 0.40 947.84 (assez élevé)
1731 vlc 736.37 0.81 737.18 (assez élevé)
Pour les défauts de page, il n'y a rien de nouveau. Avec les changements de contexte, nous obtenons également une liste de CS volontaires et involontaires. Ce dernier groupe peut être une indication de tâches dépassant leur tranche allouée, ce qui leur donnerait alors une priorité dynamique inférieure lors de leur prochaine exécution (ce qui n'est pas bon pour les processus interactifs).
Opérations d'E/S de fichier :
PID Process Count Op Filename
1715 vlc 176 R /home/roger/developers.webm
1715 vlc 48 C /etc/ld.so.cache
1715 vlc 48 O /etc/ld.so.cache
1715 vlc 34 R /usr/share/X11/locale/locale.alias
L'E/S de fichier affiche désormais également le nombre d'opérations par processus, le type d'opération ainsi que le nom du fichier. Cela ne doit pas nécessairement être un fichier réel sur le disque, cela peut aussi être un bus. Les opérations disponibles sont imprimées au bas de cette section. La manière exacte dont les opérations de lecture et d'écriture sont effectuées dépend de nombreux facteurs.
...
1715 vlc 1 C /lib/x86_64-linux-gnu/libnss_systemd.so.2
1715 vlc 1 OR /usr/bin/vlc
Total 4352
Op :O=Ouvrir, R=Lire, W=Ecrire, C=Fermer
Vous obtenez également la fréquence de ces opérations d'E/S :
Opérations d'E/S de fichier par seconde :
Processus PID Ouvrir Fermer Lire Écrire
1715 vlc 100,57 96,72 89,77 1,75
1719 vlc 3,24 4,99 3,04 0,00
La prochaine section concerne les appels système, et elle est très détaillée. La sortie est similaire à strace. Vous aurez l'ID de processus, le nom du processus, l'appel système, le nombre, le taux, le temps total (en nous) et le pourcentage que chaque appel système a pris sur le temps d'exécution total. Vous ne pouvez pas interpréter ces chiffres à moins de savoir ce que l'application est censée faire, ou vous pouvez comparer à une référence.
Appels système suivis :
PID Process Syscall Count Rate/Sec Total uSecs % Call Time
1715 vlc stat 429 28.9555 3004 0.0011
1715 vlc mmap 240 16.1989 4912 0.0017
1715 vlc mprotect 203 13.7015 4739 0.0017
Les informations sont plus utiles lorsque vous examinez les appels système d'interrogation. Par souci de concision, j'ai légèrement modifié la sortie ci-dessous. Les quatre derniers champs indiquent tous des délais d'attente, par exemple :Zero Timeout, Minimum Timeout, etc. Essentiellement, ils vous donnent un indicateur du temps qu'il a fallu pour que ces appels système se terminent. Le champ Nombre infini fait référence aux appels système qui ont eu une attente infinie (pour la durée de l'exécution de l'application). Les informations sont également présentées sous la forme d'un histogramme par processus, de zéro à l'infini, regroupé de manière logarithmique, jusqu'à 10 us, 10-99 us, 100-99 us, etc.
Principaux appels système d'interrogation :
PID Process Syscall Rate/Sec Inf Zero Min Max Avg
1715 vlc poll 3,2398 45 1 0,0 s 25,0 s 1,0 s
1715 vlc rt_sigtimed 0,1350 2 0 0,0 s 0,0 s 0.0 s
1717 vlc poll 124.7312 5 1 0.0 s 30.0 s 958.4 ms
Le journal de sortie plus détaillé contiendra également les données de synchronisation du système de fichiers.
Synchronisations du système de fichiers :
PID fdatasync fsync sync syncfs total total (taux)
1723 0 2 0 0 2 0,13
Fichiers synchronisés :
PID syscall # sync's filename
1723 fdatasync 1 /home/roger/.../vlc-qt-interface.conf.lock
1723 fdatasync 1 /home/roger/.../vlc-qt-interface.conf.XM1715
Enfin, la sortie détaillée contiendra également des informations sur la mémoire et la connexion réseau, mais la principale différence sera les résultats affichés par processus. Comme nous en avons discuté précédemment, le premier ne sera généralement pas utile pour la plupart des charges de travail de bureau (sauf si vous êtes le développeur du programme), tandis que le second peut être utile pour trouver des problèmes dans la pile réseau.
Health-check crée un ensemble assez large de résultats, mais il fournit beaucoup d'informations sur le comportement de vos applications. Vous pouvez combiner son utilisation avec d'autres logiciels pour obtenir une analyse complète de votre logiciel et résoudre les problèmes de performances. Health-check peut également profiler les tâches en cours d'exécution (indicateur -p), ce qui le rend très pratique en tant que complément à votre boîte à outils de résolution de problèmes.
Configuration manuelle
Si vous n'êtes pas satisfait de la version disponible dans les dépôts, vous pouvez compiler manuellement. Une autre raison de le faire est de contourner les éventuels problèmes que les versions plus anciennes peuvent rencontrer, comme par exemple l'erreur timer_stats, par laquelle les outils tentent d'accéder à /proc/timer_stats, mais cette structure n'est plus exposée dans les noyaux récents :
Impossible d'ouvrir /proc/timer_stats.
En effet, si vous cochez, vous obtenez :
cat /proc/timer_stats
cat :/proc/timer_stats :aucun fichier ou répertoire de ce type
Pour compiler, exécutez :
git clone https://kernel.ubuntu.com/git/cking/health-check.git/
cd health-check
make
L'erreur suivante peut s'afficher :
json.h:25:10 :erreur fatale :json-c/json.h :aucun fichier ou répertoire de ce type
#include
Cela signifie qu'il vous manque le package de développement pour JSON, dont l'outil a besoin pour compiler avec succès. Le nom réel du paquet variera d'une distribution à l'autre, mais lors de mon test sur Kubuntu, ce qui suit a résolu l'erreur de compilation :
sudo apt-get install libjson-c-dev
Plus de lecture
Si vous êtes intéressé par des outils supplémentaires sur le dépannage du système, alors :
Outils d'administration Linux super-duper :strace
Outils d'administration Linux super-duper :lsof
Outils d'administration Linux super-duper :gdb
Système lent ? Perf à la rescousse !
Super tutoriel de débogage du système LinuxHacks sympas Linux - parties un à quatre - ne liant que le dernier.
Dernier point mais non le moindre, mon livre de résolution de problèmes !
Conclusion
Le bilan de santé est un outil très utile et pratique. Il ne remplace pas strace ou netstat ou perf, mais il peut certainement vous aider à obtenir un instantané multidimensionnel très précis de tout ce que vous profilez. C'est une très bonne première étape qui peut vous orienter dans la bonne direction. Vous pouvez ensuite sélectionner un utilitaire qui examine spécifiquement la facette pertinente de l'exécution du logiciel (peut-être Wireshark pour le réseau ou Valgrind pour la mémoire). D'une certaine manière, cela transforme le bilan de santé en un touche-à-tout.
Vous avez besoin d'une certaine compréhension du fonctionnement des systèmes Linux - et de l'application que vous exécutez. Mais même si vous n'avez pas ces connaissances, la vérification de l'état peut être utilisée pour des études comparatives et le dépannage des goulots d'étranglement des performances. Si vous savez que quelque chose ne fonctionne pas aussi bien qu'il le devrait, vous pouvez le tracer une fois sur un bon système, une fois sur un mauvais système (affecté), puis comparer les deux. Les nombreux types de données fournis par le bilan de santé aideront grandement à résoudre le problème. Et cela nous amène à la fin de ce tutoriel. Avec un peu de chance, vous avez appris quelque chose de nouveau, et ce fut également une balade agréable. Prenez soin de vous.