23.6. Analyser les données
Les mêmes outils post-traitement d'OProfile sont utilisés lors de la collection du profil avec
operf
ou opcontrol
en mode hérité.
Par défaut,
operf
stocke les données de profilage dans le répertoire current_dir/oprofile_data/
. Vous pouvez modifier l'emplacement avec l'option --session-dir
. Les outil d'analyse post-profilage, tels qu'opreport
et opannotate
, peuvent être utilisés pour générer des rapports de profil. Ces outils recherchent des échantillons dans le répertoire current_dir/oprofile_data/
en premier. Si ce répertoire n'existe pas, les outils d'analyse utilisent le répertoire de la session standard de /var/lib/oprofile/
. Des statistiques, comme le total des échantillons reçus et le total des échantillons perdus, sont écrites sur le fichier session_dir/samples/operf.log
.
Pendant l'utilisation du mode hérité, le démon OProfile,
oprofiled
collecte périodiquement les échantillons et les écrits dans le répertoire /var/lib/oprofile/samples/
. Avant de lire les données, assurez-vous que toutes les données ont bien été écrites sur ce répertoire, en exécutant la commande suivante en tant qu'utilisateur root :
opcontrol --dump
Chaque nom de fichier d'échantillon est basé sur le nom de l'exécutable. Par exemple, les échantillons de l'événement par défaut sur un processeur Pentium III de
/bin/bash
devient :
\{root\}/bin/bash/\{dep\}/\{root\}/bin/bash/CPU_CLK_UNHALTED.100000
Les outils suivants sont disponibles pour profiler les données d'échantillons une fois qu'elles ont été collectées :
opreport
opannotate
Veuillez utiliser ces outils, ainsi que les binaires profilés, pour générer des rapports qui pourront être analysés davantage en profondeur.
Avertissement
L'exécutable en cours de profilage doit être utilisé avec ces outils pour analyser les données. S'il doit changer après la collection des données, veuillez effectuez une copie de sauvegarder de l'exécutable utilisé pour créer les échantillons ainsi que les fichiers d'échantillons. Remarquez que les noms du fichier d'échantillon et du binaire doivent s'accorder. Vous ne pourrez pas faire de sauvegarde si ces noms ne correspondent pas. De manière alternative,
oparchive
peut être utilisé pour répondre à ce problème.
Les échantillons de chaque exécutable sont écrits sur un seul fichier d'échantillons. Les échantillons de chaque bibliothèque dynamiquement liée sont également écrits sur un seul fichier d'échantillons. Pendant l'exécution d'OProfile, si l'exécutable en cours de surveillance change et qu'un fichier d'échantillons pour l'exécutable existe, le fichier d'échantillons existant sera automatiquement supprimé. Ainsi, si le fichier d'échantillons est nécessaire, il devra être sauvegardé avec l'exécutable utilisé pour le créer avant de remplacer l'exécutable par une nouvelle version. Les outils d'analyse OProfile utilisent le fichier exécutable qui a créé les échantillons pendant l'analyse. Si l'exécutable change, les outils d'analyse seront incapables d'analyser les échantillons associés. Veuillez consulter la Section 23.5, « Enregistrer des données en mode hérité » pour obtenir des détails sur la manière de sauvegarder le fichier d'échantillons.
23.6.1. Utiliser opreport
L'outil
opreport
offre une vue d'ensemble sur tous les exécutables en cours de profilage. Voici un extrait d'échantillon de la commande opreport
:
~]$ opreport
Profiling through timer interrupt
TIMER:0|
samples| %|
------------------
25926 97.5212 no-vmlinux
359 1.3504 pi
65 0.2445 Xorg
62 0.2332 libvte.so.4.4.0
56 0.2106 libc-2.3.4.so
34 0.1279 libglib-2.0.so.0.400.7
19 0.0715 libXft.so.2.1.2
17 0.0639 bash
8 0.0301 ld-2.3.4.so
8 0.0301 libgdk-x11-2.0.so.0.400.13
6 0.0226 libgobject-2.0.so.0.400.7
5 0.0188 oprofiled
4 0.0150 libpthread-2.3.4.so
4 0.0150 libgtk-x11-2.0.so.0.400.13
3 0.0113 libXrender.so.1.2.2
3 0.0113 du
1 0.0038 libcrypto.so.0.9.7a
1 0.0038 libpam.so.0.77
1 0.0038 libtermcap.so.2.0.8
1 0.0038 libX11.so.6.2
1 0.0038 libgthread-2.0.so.0.400.7
1 0.0038 libwnck-1.so.4.9.0
Chaque exécutable est répertorié sur sa propre ligne. La première colonne est le nombre d'échantillons enregistrés pour l'exécutable. La seconde colonne est le pourcentage d'échantillons relatif au nombre total d'échantillons. La troisième colonne est le nom de l'exécutable.
Veuillez consulter la page du manuel
opreport(1)
pour afficher une liste des options de ligne de commande disponibles, comme l'option -r
utilisée pour trier la sortie de l'exécutable avec le plus petit nombre d'échantillons vers celui en ayant le plus grand nombre. Vous pouvez également utiliser l'option -t
ou --threshold
pour réduire la sortie de opcontrol
.
23.6.2. Utiliser opreport sur un seul exécutable
Pour récupérer des informations de profilage plus détaillée sur un exécutable spécifique, veuillez utiliser :
opreport mode executable
Veuillez remplacer executable par le chemin complet de l'exécutable devant être analysé. mode correspond à l'une des options suivantes :
-l
- Cette option est utilisée pour répertorier les données d'échantillon par symbole. Par exemple, l'exécution de cette commande :
~]#
opreport -l /usr/lib/tls/libc-version.so
produit la sortie suivante :samples % symbol name 12 21.4286 __gconv_transform_utf8_internal 5 8.9286 _int_malloc 4 7.1429 malloc 3 5.3571 __i686.get_pc_thunk.bx 3 5.3571 _dl_mcount_wrapper_check 3 5.3571 mbrtowc 3 5.3571 memcpy 2 3.5714 _int_realloc 2 3.5714 _nl_intern_locale_data 2 3.5714 free 2 3.5714 strcmp 1 1.7857 __ctype_get_mb_cur_max 1 1.7857 __unregister_atfork 1 1.7857 __write_nocancel 1 1.7857 _dl_addr 1 1.7857 _int_free 1 1.7857 _itoa_word 1 1.7857 calc_eclosure_iter 1 1.7857 fopen@@GLIBC_2.1 1 1.7857 getpid 1 1.7857 memmove 1 1.7857 msort_with_tmp 1 1.7857 strcpy 1 1.7857 strlen 1 1.7857 vfprintf 1 1.7857 write
La première colonne correspond au nombre d'échantillons pour le symbole, la seconde colonne est le pourcentage d'échantillons de ce symbole relatif au nombre total d'échantillons de l'exécutable, et la troisième colonne est le nom du symbole.Pour trier la sortie depuis le plus grand nombre d'échantillons au plus petit (l'ordre contraire), veuillez utiliser-r
en conjonction à l'option-l
. -i
symbol-name- Lister les données d'échantillons spécifiques à un nom de symbole. Par exemple, en exécutant :
~]#
opreport -l -i __gconv_transform_utf8_internal /usr/lib/tls/libc-version.so
retournera la sortie suivante :samples % symbol name 12 100.000 __gconv_transform_utf8_internal
La première ligne est un résumé de la combinaison symbole/exécutable.La première colonne correspond au nombre d'échantillons pour le symbole de mémoire, la seconde colonne est le pourcentage d'échantillons de l'adresse mémoire relatif au nombre total d'échantillons du symbole, et la troisième colonne est le nom du symbole. -d
- Cette option répertorie les données d'échantillons par symboles avec plus de détails que l'option
-l
. Par exemple, avec la commande suivante :~]#
opreport -d -i __gconv_transform_utf8_internal /usr/lib/tls/libc-version.so
la sortie suivante est retournée :vma samples % symbol name 00a98640 12 100.000 __gconv_transform_utf8_internal 00a98640 1 8.3333 00a9868c 2 16.6667 00a9869a 1 8.3333 00a986c1 1 8.3333 00a98720 1 8.3333 00a98749 1 8.3333 00a98753 1 8.3333 00a98789 1 8.3333 00a98864 1 8.3333 00a98869 1 8.3333 00a98b08 1 8.3333
Les données sont les mêmes qu'avec l'option-l
sauf que pour chaque symbole, chaque adresse de mémoire virtuelle est affichée. Pour chaque adresse de mémoire virtuelle, le nombre d'échantillons et le pourcentage d'échantillons relatif au nombre d'échantillons du symbole est affiché. -e
symbol-name…- Avec cette option, vous pouvez exclure certains symboles de la sortie. Remplacez symbol-name par une liste des symboles que vous souhaitez exclure, séparés par des virgules.
session
:name- Ici, vous pouvez spécifier le chemin complet de la session, un répertoire relatif au répertoire
/var/lib/oprofile/samples/
, ou si vous utilisezoperf
, un répertoire relatif à./oprofile_data/samples/
.
23.6.3. Obtenir une sortie plus détaillée sur les modules
OProfile collecte des données sur une base globale pour le code de l'espace utilisateur et de l'espace du noyau exécuté sur la machine. Cependant, une fois qu'un module est chargé dans le noyau, les informations sur l'origine du module du noyau seront perdues. Le module peut provenir du fichier
initrd
pendant le démarrage système, du répertoire avec les divers modules de noyau, ou d'un module de noyau créé localement. Par conséquent, lorsqu'OProfile enregistre des échantillons pour un module, il répertorie les échantillons des modules d'un exécutable dans le répertoire root, mais il est improbable que ce soit l'emplacement où se trouve le code du module. Vous devrez prendre certaines précautions pour vous assurer que les outils d'analyse puissent obtenir le bon exécutable.
Pour obtenir un affichage plus détaillé des actions du module, vous aurez besoin que le module soit « unstripped » (c'est-à-dire installé à partir d'une version personnalisée) ou que le paquet debuginfo soit installé pour le noyau.
Découvez quel noyau est en cours d'exécution avec la commande
uname -a
, obtenez le paquet debuginfo approprié et installez-le sur la machine.
Puis, veuillez procéder en supprimant les échantillons des exécutions précédentes avec la commande suivante :
opcontrol --reset
Par exemple, pour lancer le processus de surveillance sur une machine avec un processeur Westmere, veuillez exécuter la commande suivante :
~]# opcontrol --setup --vmlinux=/usr/lib/debug/lib/modules/`uname -r`/vmlinux --event=CPU_CLK_UNHALTED:500000
Puis, les informations détaillées pour, par exemple, le module ext, peuvent être obtenues avec :
~]# opreport /ext4 -l --image-path /usr/lib/modules/`uname -r`/kernel
CPU: Intel Westmere microarchitecture, speed 2.667e+06 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 500000
warning: could not check that the binary file /lib/modules/2.6.32-191.el6.x86_64/kernel/fs/ext4/ext4.ko has not been modified since the profile was taken. Results may be inaccurate.
samples % symbol name
1622 9.8381 ext4_iget
1591 9.6500 ext4_find_entry
1231 7.4665 __ext4_get_inode_loc
783 4.7492 ext4_ext_get_blocks
752 4.5612 ext4_check_dir_entry
644 3.9061 ext4_mark_iloc_dirty
583 3.5361 ext4_get_blocks
583 3.5361 ext4_xattr_get
479 2.9053 ext4_htree_store_dirent
469 2.8447 ext4_get_group_desc
414 2.5111 ext4_dx_find_entry
23.6.4. Utiliser opannotate
L'outil
opannotate
tente de faire correspondre les échantillons de certaines instructions avec les lignes correspondantes du code source. Les fichiers générés en résultant devraient avoir les échantillons des lignes sur le côté gauche. Cet outil met également un commentaire au début de chaque fonction qui répertorie la totalité des échantillons de cette fonction.
Pour que cet utilitaire fonctionne, le paquet debuginfo approprié de l'exécutable doit être installé sur le système. Sur Red Hat Enterprise Linux, les paquets debuginfo ne sont pas automatiquement installés avec les paquets correspondants qui contiennent l'exécutable. Vous devez les obtenir et les installer séparément.
La syntaxe générale de
opannotate
est comme suit :
opannotate --search-dirs src-dir --source executable
Ces options de ligne de commande sont obligatoires. Remplacez src-dir par un chemin vers le répertoire contenant le code source et spécifiez l'exécutable devant être analysé. Veuillez consulter la page du manuel
opannotate(1)
pour voir une liste des options de ligne de commande supplémentaires.