# Chapitre 26. DTrace

This translation may be out of date. To help with the translations please access the FreeBSD translations instance.

## 26.1. Synopsis

DTrace, également désigné sous le nom de système de trace dynamique, a été développé par Sun™ comme outil de localisation de problèmes de performance sur des systèmes de production et d’avant-production. Ce n’est, en aucune manière, un outil de débogage, mais un outil pour l’analyse système en temps réel pour localiser les problèmes de performance et autres.

DTrace est un outil de profilage remarquable, avec une impressionnante multitude de fonctions pour diagnostiquer des problèmes système. Il peut également être utilisé avec des scripts pré-écrits pour pouvoir profiter de ses capacités. Les utilisateurs peuvent écrire leurs propres utilitaires en employant le langage de DTrace, D, leur permettant ainsi de personnaliser leur profilage en fonction de leurs besoins.

Après la lecture de ce chapitre, vous connaîtrez:

- Ce qu’est DTrace et quelles fonctionnalités il offre.

- Les différences entre la version DTrace de Solaris™ et celle fournie par FreeBSD.

- Comment activer et utiliser DTrace sur FreeBSD.

Avant de lire ce chapitre, vous devrez:

- Comprendre les fondements d’UNIX® et de FreeBSD (Quelques bases d’UNIX).

- Etre familier avec la configuration/compilation du noyau (Configurer le noyau de FreeBSD).

- Avoir une certaine connaissance concernant la sécurité et ses liens avec FreeBSD (Sécurité).

- Comprendre comment obtenir et recompiler les sources de FreeBSD (Mise à jour de FreeBSD).

| Cette fonction est considérée comme expérimentale. Quelques options peuvent être absentes et d’autres ne fonctionneront peut-être pas du tout. A terme, cette fonction sera prête pour une utilisation en production, et cette documentation sera modifiée pour en tenir compte.

## 26.2. Des différences de mise en oeuvre

Bien que DTrace sous FreeBSD soit très semblable à DTrace sous Solaris™, des différences existent et devraient être expliquées avant de continuer. La différence principale que les utilisateurs remarqueront est que sur FreeBSD, DTrace doit être spécialement activé. Il y a des options de noyau et des modules qui doivent être activés pour que DTrace fonctionne correctement. Ces options seront expliquées plus tard.

Il existe une option de noyau, `DDB_CTF`, qui est employée pour activer la prise en charge du chargement des données CTF depuis les modules de noyau et du noyau lui-même. CTF est le format Compact C de Solaris™, qui encapsule une forme réduite d’information de débogage, semblable à DWARF et ses vénérables tables de symboles. Ces données CTF sont ajoutées aux fichiers binaires par les outils de compilation `ctfconvert` et `ctfmerge`. L’utilitaire `ctfconvert` analyse les sections de débogage ELFDWARF crées par le compilateur et `ctfmerge` fusionne les sections ELFCTF qui sont sous forme objet vers soit des fichiers executables, soit des bibliothèques partagées. Plus d’informations sur comment activer cela pour le noyau et FreeBSD est à venir.

Quelques fournisseurs différents existent pour FreeBSD par rapport à Solaris™. Le plus notable est le fournisseur `dtmalloc`, qui permet le traçage de la fonction `malloc()` par type dans le noyau FreeBSD.

Seul l’utilisateur `root` peut utiliser DTrace sur FreeBSD. Ceci est lié aux différences de sécurité, Solaris™ dispose de quelques contrôles de sécurité de bas niveau qui n’existent pas encore sur FreeBSD. Ainsi /dev/dtrace/dtrace est strictement limité uniquement à l’utilisateur `root`.

Pour terminer, le logiciel DTrace est sous la licence de Sun™, CDDL. La `Common Development and Distribution License` est disponibles sous FreeBSD, voir le fichier /usr/src/cddl/contrib/opensolaris/OPENSOLARIS.LICENSE ou vous pouvez le consulter sur Internet à http://www.opensolaris.org/os/licensing.

Cette licence signifie qu’un noyau avec les options DTrace est toujours sous licence BSD; cependant, la licence CDDL est appliquée lorsque les modules sont distribués sous format binaire, ou quand les fichiers binaires sont chargés.

## 26.3. Activer la prise en charge de DTrace

Pour activer DTrace, il faut ajouter les lignes suivantes au fichier de configuration du noyau:

    options         KDTRACE_HOOKS
    options         DDB_CTF

| Les utilisateurs de l’architecture AMD64 devraient ajouter la ligne suivante à leur fichier de configuration de noyau:
    options         KDTRACE_FRAME
Cette option active la fonction FBT. DTrace fonctionnera sans cette option, mais il y aura des restrictions sur le traçage des limites des fonctions.

Les sources doivent être recompilées et installées avec les options CTF. Pour faire cela, recompiler les sources de FreeBSD en utilisant:

    # cd /usr/src

    # make WITH_CTF=1 kernel

Le système aura besoin d’être redémarré.

Après avoir redémarré et avoir laissé charger en mémoire le noyau, le support de l’interpréteur de commandes Korn devra être ajouté. Ceci est necessaire car la boîte à outils DTrace possède quelques utilitaires écrits en `ksh`. Il faut installer shells/ksh93. Il est également possible de faire fonctionner ces outils avec shells/pdksh ou shells/mksh.

Finalement, récupérer la boîte à outils DTrace la plus récente. La version actuelle est disponible à l’adresse http://www.opensolaris.org/os/community/dtrace/. Un système d’installation est inclu dans l’archive; cependant, cette installation n’est pas obligatoire pour utiliser les outils fournis.

## 26.4. Utiliser DTrace

Avant d’utiliser DTrace, il faut que le périphérique DTrace existe. Pour charger le périphérique, exécutez la commande suivante:

    # kldload dtraceall

Le système devrait maintenant supporter DTrace. Pour afficher toutes les sondes, l’administrateur peut maintenant executer la commande:

    # dtrace -l | more

Toutes les données sortantes de cette commande sont passées à l’utilitaire `more`, pour empêcher qu’elles saturent l’écran. A ce niveau, DTrace peut être considéré comme fonctionnel. On est maintenant prêt à passer en revue l’ensemble des outils disponibles.

La boîte à outils est une collection de scripts prêts à fonctionner avec DTrace pour rassembler des informations systèmes. Il y a des scripts pour vérifier les fichiers ouvertes, la mémoire, l’usage du CPU et beaucoup plus. Il faut extraire les scripts avec la commande suivante:

    # gunzip -c DTracetoolkit* | tar xvf -

Aller dans ce répértoire en utilisant `cd` et changer les permissions de tous les fichiers, les fichiers avec les noms en miniscules, à `755`.

Chacun de ces scripts devra avoir son contenu modifié. Ceux qui font référence à /usr/bin/ksh devront pointer sur /usr/local/bin/ksh, les autres qui utilisent /usr/bin/sh devront être modifiés pour qu’ils utilisent /bin/sh, et finalement ceux qui utilisent /usr/bin/perl, devront pointer sur /usr/local/bin/perl.

| A ce point il est prudent de rappeler au lecteur que le support de DTrace sous FreeBSD n’est pas complet et est encore expérimental. Un bon nombre de ces scripts ne fonctionneront pas, soit parce qu’ils sont trop spécifiques à Solaris™, soit parce qu’ils utilisent des sondes qui ne sont pas encore supportées.

Au moment de l’écriture de ces lignes, seuls deux des scripts de la boîte à outils DTrace sont totalement supportés sous FreeBSD: les outils hotkernel et procsystime. Ce sont ces deux outils que nous détaillerons dans la suite de cette section.

L’outil hotkernel est censé identifier quel fonction utilise le plus de temps noyau. Fonctionnant normalement, il affichera une liste comparable à la suivante:

    # ./hotkernel
    Sampling... Hit Ctrl-C to end.

L’administrateur système doit utiliser la combinaison de touches `Ctrl`+`C` pour arrêter le processus. Le script affichera une liste de fonctions du noyau et des informations de temps, et les triera dans l’ordre croissant du temps consommé:

    kernel`_thread_lock_flags                                   2   0.0%
    0xc1097063                                                  2   0.0%
    kernel`sched_userret                                        2   0.0%
    kernel`kern_select                                          2   0.0%
    kernel`generic_copyin                                       3   0.0%
    kernel`_mtx_assert                                          3   0.0%
    kernel`vm_fault                                             3   0.0%
    kernel`sopoll_generic                                       3   0.0%
    kernel`fixup_filename                                       4   0.0%
    kernel`_isitmyx                                             4   0.0%
    kernel`find_instance                                        4   0.0%
    kernel`_mtx_unlock_flags                                    5   0.0%
    kernel`syscall                                              5   0.0%
    kernel`DELAY                                                5   0.0%
    0xc108a253                                                  6   0.0%
    kernel`witness_lock                                         7   0.0%
    kernel`read_aux_data_no_wait                                7   0.0%
    kernel`Xint0x80_syscall                                     7   0.0%
    kernel`witness_checkorder                                   7   0.0%
    kernel`sse2_pagezero                                        8   0.0%
    kernel`strncmp                                              9   0.0%
    kernel`spinlock_exit                                       10   0.0%
    kernel`_mtx_lock_flags                                     11   0.0%
    kernel`witness_unlock                                      15   0.0%
    kernel`sched_idletd                                       137   0.3%
    0xc10981a5                                              42139  99.3%

Ce script fonctionnera aussi avec des modules de noyau. Pour utiliser ce fonction, exécutez le script avec l’option `-m`:

    # ./hotkernel -m
    Sampling... Hit Ctrl-C to end.
    ^C
    MODULE                                                  COUNT   PCNT
    0xc107882e                                                  1   0.0%
    0xc10e6aa4                                                  1   0.0%
    0xc1076983                                                  1   0.0%
    0xc109708a                                                  1   0.0%
    0xc1075a5d                                                  1   0.0%
    0xc1077325                                                  1   0.0%
    0xc108a245                                                  1   0.0%
    0xc107730d                                                  1   0.0%
    0xc1097063                                                  2   0.0%
    0xc108a253                                                 73   0.0%
    kernel                                                    874   0.4%
    0xc10981a5                                             213781  99.6%

Le script procsystime capture et affiche le temps consommé en appels système pour un PID ou un processus donné. Dans l’exemple suivant, un nouvel exemplaire de /bin/csh a été lancé. L’outil procsystime a été exécuté et laissé en attente pendant que quelques commandes été tapées sur les autres incarnations de `csh`. Voici le résultat de ce test:

    # ./procsystime -n csh
    Tracing... Hit Ctrl-C to end...
    ^C

    Elapsed Times for processes csh,

             SYSCALL          TIME (ns)
              getpid               6131
           sigreturn               8121
               close              19127
               fcntl              19959
                 dup              26955
             setpgid              28070
                stat              31899
           setitimer              40938
               wait4              62717
           sigaction              67372
         sigprocmask             119091
        gettimeofday             183710
               write             263242
              execve             492547
               ioctl             770073
               vfork            3258923
          sigsuspend            6985124
                read         3988049784

Comme indiqué, l’appel système `read()` semble prendre le plus de temps en nanosecondes, alors que l’appel système `getpid()` prend très peu de temps.

## 26.5. Le langage D

La boîte à outils DTrace comprend plusieurs scripts écrits dans le langage spécifique de DTrace. Ce langage est appelé le "langage D" dans la documentation de Sun™, et est très proche du C++. Une étude en profondeur de ce langage sort du cadre de ce document. Il est abordé de manière très détaillée à l’adresse http://wikis.sun.com/display/DTrace/Documentation.

Last modified on: 18 février 2025 by Fernando Apesteguía

Prev
Home
Next