options KDTRACE_HOOKS options DDB_CTF
Chapitre 26. DTrace
This translation may be out of date. To help with the translations please access the FreeBSD translations instance.
Sommaire
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:
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 kernelLe 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 dtraceallLe système devrait maintenant supporter DTrace. Pour afficher toutes les sondes, l’administrateur peut maintenant executer la commande:
# dtrace -l | moreToutes 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 3988049784Comme 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: 9 mars 2024 by Danilo G. Baio