Le fournisseur profile propose des sondes associées à un déclenchement d'interruption basé sur le temps à chaque intervalle de temps défini. Ces sondes non ancrées ne sont pas associées à un point d'exécution particulier, mais plutôt à l'événement d'interruption asynchrone. Ces sondes peuvent être utilisées pour échantillonner un aspect donné de l'état système à chaque unité de temps et les échantillons peuvent alors être utilisés pour inférer le comportement du système. Si la vitesse d'échantillonnage est élevée ou si la durée d'échantillonnage est longue, une inférence précise est possible. À l'aide d'actions DTrace, le fournisseur profile peut être utilisé pour échantillonner n'importe quel élément du système de manière pratique. Par exemple, vous pourriez échantillonner l'état du thread en cours, l'état de la CPU ou l'instruction de la machine en cours.
Les sondes n'ont pas accès aux variables locales de thread à partir du fournisseur profile. L'utilisation de l'identifiant spécial self avec ce type de sonde pour référencer une variable locale de thread ne renverra aucune sortie.
Une sonde profile-n se déclenche à chaque intervalle défini sur chaque CPU à un niveau élevé d'interruption. L'intervalle de déclenchement de la sonde est indiqué par la valeur de n : la source d'interruption se déclenche n fois par seconde. n peut également porter un suffixe de temps facultatif, auquel cas n est dans les unités exprimées par le suffixe. Les suffixes valides et les unités qu'ils expriment sont répertoriés dans le Tableau 19–1.
Tableau 19–1 Suffixes d'heure valides
Suffixe |
Unités de temps |
---|---|
nsec ou ns |
nanosecondes |
usec ou us |
microsecondes |
msec ou ms |
millièmes de seconde |
sec ou s |
secondes |
min ou m |
minutes |
hour ou h |
heures |
day ou d |
jours |
hz |
hertz (fréquence par seconde) |
L'exemple suivant crée une sonde se déclenchant à 97 hertz pour échantillonner le processus en cours d'exécution :
#pragma D option quiet profile-97 /pid != 0/ { @proc[pid, execname] = count(); } END { printf("%-8s %-40s %s\n", "PID", "CMD", "COUNT"); printa("%-8d %-40s %@d\n", @proc); }
L'exécution de l'exemple ci-dessus sur une courte période donne une sortie similaire à l'exemple suivant :
# dtrace -s ./prof.d ^C PID CMD COUNT 223887 sh 1 100360 httpd 1 100409 mibiisa 1 223887 uname 1 218848 sh 2 218984 adeptedit 2 100224 nscd 3 3 fsflush 4 2 pageout 6 100372 java 7 115279 xterm 7 100460 Xsun 7 100475 perfbar 9 223888 prstat 15 |
Vous pouvez également utiliser le fournisseur profile-n pour échantillonner des informations sur le processus en cours d'exécution. L'exemple suivant de script D utilise une sonde profile de 1 001 hertz pour échantillonner la priorité actuelle d'un processus spécifié :
profile-1001 /pid == $1/ { @proc[execname] = lquantize(curlwpsinfo->pr_pri, 0, 100, 10); }
Pour voir cet exemple de script en action, entrez les commandes suivantes dans une fenêtre :
$ echo $$ 12345 $ while true ; do let i=0 ; done |
Dans une autre fenêtre, exécutez le script D sur une courte durée, en remplaçant 12345 par l'ID de processus renvoyé par la commande echo :
# dtrace -s ./profpri.d 12345 dtrace: script './profpri.d' matched 1 probe ^C ksh value ------------- Distribution ------------- count < 0 | 0 0 |@@@@@@@@@@@@@@@@@@@@@ 7443 10 |@@@@@@ 2235 20 |@@@@ 1679 30 |@@@ 1119 40 |@ 560 50 |@ 554 60 | 0 |
Cette sortie illustre la polarisation de la classe de planification du partage de temps. Le processus de shell étant en rotation sur la CPU, sa priorité est sans cesse diminuée par le système. Si le processus de shell était exécuté moins fréquemment, sa priorité serait supérieure. Pour voir ce résultat, appuyez sur Ctrl+C dans le shell en rotation, puis réexécutez le script :
# dtrace -s ./profpri.d 494621 dtrace: script './profpri.d' matched 1 probe |
Dans le shell, entrez maintenant quelques caractères. Une fois le script DTrace terminé, une sortie similaire à l'exemple suivant s'affiche :
ksh value ------------- Distribution ------------- count 40 | 0 50 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 14 60 | 0 |
Le processus de shell étant auparavant au repos dans l'attente d'une saisie utilisateur plutôt qu'en rotation sur la CPU, son exécution s'est faite à une priorité bien plus élevée.
Comme les sondes profile- n, les sondes tick- n se déclenchent à chaque intervalle défini à un niveau d'interruption élevé. Cependant, contrairement aux sondes profile- n, qui se déclenchent sur chaque CPU, les sondes tick- n ne se déclenchent que sur une CPU par intervalle. La CPU concernée peut changer dans le temps. Comme pour les sondes profile- n, n est défini par défaut sur vitesse par seconde mais peut également être accompagné d'un suffixe de temps facultatif. Les sondes tick- n ont plusieurs utilisations, comme la fourniture d'une sortie périodique ou l'exécution d'une action périodique.
Les arguments de sondes profile sont les suivants :
arg0 |
Compteur de programme dans le noyau au moment du déclenchement de la sonde, ou 0 si le processus en cours n'était pas exécuté dans le noyau au moment du déclenchement de la sonde |
arg1 |
Compteur de programme dans le processus au niveau utilisateur au moment du déclenchement de la sonde, ou 0 si le processus en cours était exécuté au niveau du noyau au moment du déclenchement de la sonde |
Comme indiqué dans leurs descriptions, si arg0 n'est pas de zéro, arg1 l'est ; si arg0 est de zéro, arg1 ne l'est pas. Ainsi, vous pouvez utiliser arg0 et arg1 pour différencier le niveau utilisateur du niveau noyau, comme dans l'exemple simple suivant :
profile-1ms { @ticks[arg0 ? "kernel" : "user"] = count(); }
Le fournisseur profile utilise des horloges d'intervalle de résolution arbitraire du système d'exploitation. Dans des architectures ne prenant pas en charge des interruptions basées sur le temps à résolution arbitraire, la fréquence est limitée par la fréquence d'horloge système qui est spécifiée par la variable de noyau hz. Les sondes de fréquence supérieure à hz dans de telles architectures se déclenchent un certain nombre de fois toutes les 1/ hz secondes. Par exemple, une sonde profile 1 000 hertz dans une telle architecture avec hz définie sur 100 se déclenchera dix fois de manière rapprochée toutes les dix millisecondes. Sur des plates-formes prenant en charge une résolution arbitraire, une sonde profile 1 000 hertz se déclencherait chaque milliseconde.
L'exemple suivant teste la résolution d'une architecture :
profile-5000 { /* * We divide by 1,000,000 to convert nanoseconds to milliseconds, and * then we take the value mod 10 to get the current millisecond within * a 10 millisecond window. On platforms that do not support truly * arbitrary resolution profile probes, all of the profile-5000 probes * will fire on roughly the same millisecond. On platforms that * support a truly arbitrary resolution, the probe firings will be * evenly distributed across the milliseconds. */ @ms = lquantize((timestamp / 1000000) % 10, 0, 10, 1); } tick-1sec /i++ >= 10/ { exit(0); }
Dans une architecture prenant en charge des sondes profile à résolution arbitraire, l'exécution de l'exemple de script entraîne une distribution régulière :
# dtrace -s ./restest.d dtrace: script './restest.d' matched 2 probes CPU ID FUNCTION:NAME 0 33631 :tick-1sec value ------------- Distribution ------------- count < 0 | 0 0 |@@@ 10760 1 |@@@@ 10842 2 |@@@@ 10861 3 |@@@ 10820 4 |@@@ 10819 5 |@@@ 10817 6 |@@@@ 10826 7 |@@@@ 10847 8 |@@@@ 10830 9 |@@@@ 10830 |
Dans une architecture ne prenant pas en charge des sondes profile à résolution arbitraire, l'exécution de l'exemple de script entraîne une distribution irrégulière :
# dtrace -s ./restest.d dtrace: script './restest.d' matched 2 probes CPU ID FUNCTION:NAME 0 28321 :tick-1sec value ------------- Distribution ------------- count 4 | 0 5 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 107864 6 | 424 7 | 255 8 | 496 9 | 0 |
Dans ces architectures, hz peut être réglée manuellement dans /etc/system afin d'améliorer la résolution effective.
Toutes les variantes de UltraSPARC (sun4u) prennent actuellement en charge les sondes profile à résolution arbitraire. De nombreuses variantes de l'architecture x86 (i86pc) prennent également en charge les sondes profile à résolution arbitraire, alors que ce n'est pas le cas de certaines variantes antérieures.
Contrairement à d'autres fournisseurs, profile crée des sondes de manière dynamique à la demande. Ainsi, la sonde profile souhaitée peut ne pas apparaître dans une liste de toutes les sondes (via dtrace -l -P profile par exemple), mais la sonde est créée lorsqu'elle est activée.
Dans des architectures prenant en charge les sondes profile à résolution arbitraire, un intervalle de temps trop court entraînerait sans cesse des interruptions basées sur le temps, refusant ainsi le service sur cette machine. Pour éviter cela, le fournisseur profile refuse silencieusement de créer toute sonde qui pourrait entraîner un intervalle de moins de deux cents microsecondes.
Le fournisseur profile utilise un mécanisme de stabilité DTrace pour décrire ses stabilités, comme illustré dans le tableau suivant. Pour plus d'informations sur le mécanisme de stabilité, reportez-vous au Chapitre39Stabilité.
Élément |
Stabilité des noms |
Stabilité des données |
Classe de dépendance |
---|---|---|---|
Fournisseur |
En cours d'évolution |
En cours d'évolution |
Commune |
Module |
Instable |
Instable |
Inconnu |
Fonction |
Privé |
Privé |
Inconnu |
Nom |
En cours d'évolution |
En cours d'évolution |
Commune |
Arguments |
En cours d'évolution |
En cours d'évolution |
Commune |