OProfile

23:50:01 0 42.84 0.03 0.80 56.33

23:50:01 1 45.29 0.01 0.74 53.95

Average: 0 6.00 5.01 2.74 86.25

Average: 1 5.61 4.97 2.99 86.43

Les rapports générés selon la configuration par défaut desarsous Red Hat Enterprise Linux incluent au total dix-sept sections différentes, dont certaines seront examinées dans des chapitres ultérieurs.

Pour de plus amples informations sur les données contenues dans chaque section, reportez-vous à la page de manuel desar(1).

2.5.5. OProfile

OProfile, le profileur de tout le système, est un outil de contrôle fonctionnant avec un temps de gestion court. Il utilise le matériel de contrôle de la performance du processeur⁵.

Le matériel de contrôle de la performance fait partie du processeur lui-même. Il se présente sous la forme d’un compteur spécial incrémenté après chaque événement (comme lorsque le processeur est occupé ou que les données ne sont pas stockées dans un cache). Certains processeurs sont dotés de plusieurs compteurs de ce type et permettent donc de réserver chaque compteur pour un type d’événement particulier.

Les compteurs peuvent être initialisés avec une certaine valeur de départ et une interruption est engen-drée quand un compteur atteint sa limite. En donnant à un compteur des valeurs initiales différentes, il est possible d’obtenir une variation du taux auquel les interruptions sont produites. De cette manière, il est également possible de contrôler la fréquence d’échantillonnage et par conséquent le degré de détail obtenu à partir des données recueillies.

Un choix extrême consistant à initialiser le compteur de sorte qu’il engendre une interruption de dépassement après chaque événement, fournirait des données de performance extrêmement détaillées (mais au prix d’un temps de gestion très long). Un choix extrême mais dans le sens inverse consistant à initialiser le compteur de sorte qu’il engendre aussi peu d’interruption que possible, ne donnerait lui en revanche qu’une vue d’ensemble très générale de la performance du système (mais avec un temps système quasiment inexistant). Le secret d’un contrôle efficace réside dans le choix d’une fréquence d’échantillonnage suffisamment élevée pour saisir les données requises mais sans être trop élevée, au point de surcharger le système avec un temps de gestion excessif nécessaire pour pouvoir effectuer le contrôle de la performance.

5. OProfile peut également utiliser un autre mécanisme (appelé TIMER_INT) pouvant être utilisé pour les architectures de systèmes qui ne disposent pas de matériel pour le contrôle de la performance.

Avertissement

La configuration de OProfile peut être effectuée de telle sorte que le profileur impose un temps de gestion suffisant pour que le système soit inutilisable. Il est par conséquent important de choi-sir les valeurs du compteur avec beaucoup de prudence. C’est la raison pour laquelle la com-mandeopcontrolprend en charge l’option--list-eventsqui permet d’afficher les différents types d’événements disponibles pour le processeur actuellement installé, ainsi que les valeurs du compteur recommandées pour chacun d’eux.

Lors de l’utilisation de OProfile, il est important de garder à l’esprit le compromis nécessaire entre la fréquence d’échantillonnage et le temps de gestion du système.

2.5.5.1. Composants de OProfile Oprofile est constitué des composants suivants :

• Logiciel de recueil de données

• Logiciel d’analyse de données

• Logiciel de l’interface administrative

Le logiciel de recueil de données est composé du module de noyauoprofile.oet du démon opro-filed.

Le logiciel d’analyse des données quant à lui inclut les programmes suivants : op_time

Affiche le nombre et les pourcentages relatifs des échantillons pris pour chaque fichier exécutable oprofpp

Affiche le nombre et les pourcentages relatifs des échantillons pris par fonction, instruction indi-viduelle ou en sortie de typegprof

op_to_source

Affiche des listes de codes sources annotés et/ou d’assemblages op_visualise

Affiche sous forme graphique les données recueillies

Grâce à ces programmes, il est possible d’afficher les données recueillies de plusieurs manières diffé-rentes.

Le logiciel de l’interface administrative contrôle tous les aspects liés au recueil de données, de la spécification des événements à contrôler au commencement et à l’arrêt des opérations de recueil elles-mêmes. La commandeopcontrolpermet de déterminer ces différents aspects.

2.5.5.2. Exemple d’une session de OProfile

Cette section illustre une session de contrôle et d’analyse des données avec OProfile, allant de la configuration initiale à l’analyse finale des données. Cet exemple n’est autre qu’un bref aperçu fourni à titre d’introduction ; pour obtenir des informations plus détaillées, consultez leGuide d’administration système de Red Hat Enterprise Linux.

Ensuite, utilisezopcontrolpour configurer le type de données à recueillir à l’aide de la commande suivante :

opcontrol \

--vmlinux=/boot/vmlinux-‘uname -r‘ \ --ctr0-event=CPU_CLK_UNHALTED \ --ctr0-count=6000

Les options utilisées ici demande àopcontrolde :

• Diriger OProfile vers une copie du noyau actuellement en cours d’exécution (--vmlinux=/boot/vmlinux-‘uname -r‘)

• Spécifier que le compteur 0 du processeur doit être utilisé et que l’événement à contrôler est le moment où le CPU exécute des instructions (--ctr0-event=CPU_CLK_UNHALTED)

• Spécifier que OProfile doit recueillir des échantillons chaque fois que l’évènement spécifié a été effectué 6000 fois (--ctr0-count=6000)

Vérifiez en suite que le module noyau deoprofileest bien chargé à l’aide de la commandelsmod dont la sortie figure ci-dessous :

Module Size Used by Not tainted

oprofile 75616 1

...

Confirmez que le système de fichiers de OProfile (situé dans/dev/oprofile/) est bien monté avec la commandels /dev/oprofile/dont la sortie figure ci-dessous :

0 buffer buffer_watershed cpu_type enable stats 1 buffer_size cpu_buffer_size dump kernel_only (Le nombre exact de fichiers varie selon le type de processeur).

À ce stade, le fichier/root/.oprofile/daemonrccontient les paramétrages dont le logiciel de recueil de données a besoin, comme le montre l’extrait ci-dessous :

CTR_EVENT[0]=CPU_CLK_UNHALTED CTR_COUNT[0]=6000

CTR_KERNEL[0]=1 CTR_USER[0]=1 CTR_UM[0]=0

CTR_EVENT_VAL[0]=121 CTR_EVENT[1]=

CTR_COUNT[1]=

CTR_KERNEL[1]=1 CTR_USER[1]=1 CTR_UM[1]=0 CTR_EVENT_VAL[1]=

one_enabled=1

SEPARATE_LIB_SAMPLES=0 SEPARATE_KERNEL_SAMPLES=0

VMLINUX=/boot/vmlinux-2.4.21-1.1931.2.349.2.2.entsmp

Utilisez ensuiteopcontrolpour effectivement commencer à recueillir des données à l’aide de la commandeopcontrol --startdont la sortie figure ci-dessous :

Using log file /var/lib/oprofile/oprofiled.log Daemon started.

Profiler running.

Vérifiez que le démonoprofiledest bien en cours d’exécution à l’aide de la commandeps x | grep -i oprofileddont la sortie figure ci-dessous :

32019 ? S 0:00 /usr/bin/oprofiled --separate-lib-samples=0 ...

32021 pts/0 S 0:00 grep -i oprofiled

(Le ligne de commandeoprofiledquepsaffiche est en réalité beaucoup plus longue mais elle a dû être tronquée ici pour des raisons de formatage.)

Le système est désormais sous surveillance et des données sont recueillies sur tous les exécutables figurant sur le système. Ces données sont ensuite stockées dans le répertoire /var/lib/oprofile/samples/. Les fichiers contenus dans ce dernier font l’objet d’une convention de nommage quelque peu inhabituelle, comme l’illustre l’exemple ci-dessous :

}usr}bin}less#0

La convention de nommage utilise certes le chemin d’accès absolu pour chaque fichier contenant un code exécutable, mais la barre oblique avant (/) est remplacée par des accolades de fermeture (}) et il se finit avec le symbole dièse (#) suivi d’un nombre (0dans le cas présent). Par conséquent, le fichier utilisé dans notre exemple correspond à des données qui ont été recueillies alors que/usr/bin/less était en cours d’exécution.

Une fois les données recueillies, utilisez un de ces outils d’analyse pour les afficher. En matière de contrôle, OProfile est dotée d’une excellente fonctionnalité à savoir, il n’est pas nécessaire d’interrompre le recueil des données avant de pouvoir effectuer une analyse de données. Toutefois, il faut attendre qu’au moins un groupe d’échantillons soit écrit sur le disque mais il est tout à fait possible de forcer le transfert des échantillons sur disque à l’aide de la commandeopcontrol --dump.

Dans l’exemple suivant, la commandeop_timeest utilisée pour afficher (dans l’ordre inverse — du nombre le plus élevé d’échantillons au nombre le plus bas) les échantillons qui ont été recueillis : 3321080 48.8021 0.0000 /boot/vmlinux-2.4.21-1.1931.2.349.2.2.entsmp

761776 11.1940 0.0000 /usr/bin/oprofiled 368933 5.4213 0.0000 /lib/tls/libc-2.3.2.so

293570 4.3139 0.0000 /usr/lib/libgobject-2.0.so.0.200.2 205231 3.0158 0.0000 /usr/lib/libgdk-x11-2.0.so.0.200.2 167575 2.4625 0.0000 /usr/lib/libglib-2.0.so.0.200.2 123095 1.8088 0.0000 /lib/libcrypto.so.0.9.7a 105677 1.5529 0.0000 /usr/X11R6/bin/XFree86 ...

Étant donné que les rapports peuvent s’étendre sur plusieurs centaines de lignes, il est judicieux d’utiliser l’optionlesslorsqu’un rapport est crée de manière interactive. Le rapport reproduit dans notre exemple a d’ailleurs été tronqué pour cette raison.

Selon le format utilisé pour la création de ce rapport spécifique, une ligne est réservée pour chaque fichier exécutable dont les données en été recueillies. Chaque ligne suit ce format particulier, comme le montre l’extrait suivant :

sample-count sample-percent unused-field executable-name où :

• sample-count correspond au nombre d’échantillons recueillies

• sample-percent correspond au pourcentage de tous les échantillons recueillis pour cet exé-cutable spécifique

• unused-field représente un champ qui n’est pas utilisé

• executable-name correspond au nom du fichier contenant le code de l’exécutable pour lequel les données ont été recueillies.

Ce rapport (créé sur un système essentiellement inoccupé) montre que presque la moitié de tous les échantillons ont été recueillis alors que le CPU exécutait des codes au sein du noyau lui-même. Le démon de recueil de données OProfile était le premier élément mis en attente, suivi par une variété de bibliothèques et le serveur du Système X Window,XFree86. Il est important de noter ici que pour le système exécutant cette session, la valeur de 6000 utilisée pour le compteur correspond à la valeur minimale recommandée paropcontrol --list-events. Dans de telles conditions — au moins pour ce système particulier — le temps de gestion de OProfile à son niveau le plus élevé, consomme environ 11% du CPU.

2.6. Ressources supplémentaires

Cette section inclut un certain nombre de ressources pouvant être utilisées pour développer vos connaissances sur le contrôle des ressources et sur des sujets spécifiques à Red Hat Enterprise Li-nux qui ont été discutés dans ce chapitre.