Chapitre 23 Fournisseur sysinfo
Le fournisseur sysinfo permet d'accéder aux sondes correspondant aux statistiques du noyau classées en fonction du nom sys. Grâce à ces statistiques fournies aux utilitaires de surveillance du système comme mpstat(1M), le fournisseur sysinfo permet d'étudier rapidement le comportement anormal observé.
Sondes
Le fournisseur sysinfo permet d'accéder aux sondes correspondant aux champs des statistiques de noyau nommées sys : une sonde fournie par sysinfo se déclenche juste avant que la valeur sys correspondante ne soit incrémentée. L'exemple suivant indique comment afficher les noms et les valeurs courantes des statistiques du noyau nommées sys à l'aide de la commande kstat(1M).
$ kstat -n sys module: cpu instance: 0 name: sys class: misc bawrite 123 bread 2899 bwrite 17995 ... |
Les sondes sysinfo sont décrites dans le Tableau 23–1.
Tableau 23–1 Sondes sysinfo|
bawrite |
Sonde qui se déclenche à chaque écriture asynchrone d'un tampon sur un périphérique. |
|
bread |
Sonde qui se déclenche à chaque lecture physique d'un tampon à partir d'un périphérique. bread se déclenche après la demande du tampon à partir du périphérique mais avant le blocage de son exécution. |
|
bwrite |
Sonde qui se déclenche à chaque écriture d'un tampon sur un périphérique, que ce soit de manière synchrone ou asynchrone. |
|
idlethread |
Sonde qui se déclenche chaque fois qu'une CPU entre dans la boucle inactive. |
|
intrblk |
Sonde qui se déclenche chaque fois qu'un thread d'interruption bloque. |
|
inv_swtch |
Sonde qui se déclenche chaque fois qu'un thread en cours d'exécution est contraint d'abandonner involontairement la CPU. |
|
lread |
Sonde qui se déclenche à chaque lecture logique d'un tampon à partir d'un périphérique. |
|
lwrite |
Sonde qui se déclenche à chaque écriture logique d'un tampon sur un périphérique. |
|
modload |
Sonde qui se déclenche à chaque chargement d'un module du noyau. |
|
modunload |
Sonde qui se déclenche à chaque déchargement d'un module du noyau. |
|
msg |
Sonde qui se déclenche chaque fois qu'un appel système msgsnd(2) ou msgrcv(2) est passé mais avant l'exécution des opérations de file d'attente du message. |
|
mutex_adenters |
Sonde qui se déclenche à chaque tentative d'acquisition d'un verrou adaptatif propriétaire. Si cette sonde se déclenche, l'une des sondes adaptive-block ou adaptive-spin du fournisseur lockstat se déclenche également. Pour plus d'informations, reportez-vous au Chapitre18Fournisseur lockstat. |
|
namei |
Sonde qui se déclenche à chaque tentative de recherche de nom dans le système de fichiers. |
|
nthreads |
Sonde qui se déclenche à chaque création d'un thread. |
|
phread |
Sonde qui se déclenche chaque fois qu'une lecture d'E/S brute va être exécutée. |
|
phwrite |
Sonde qui se déclenche chaque fois qu'une écriture d'E/S brute va être exécutée. |
|
procovf |
Sonde qui se déclenche chaque fois qu'il est impossible de créer un nouveau processus car le système manque d'entrées de tableau de processus. |
|
pswitch |
Sonde qui se déclenche chaque fois qu'une CPU passe de l'exécution d'un thread à l'exécution d'un autre thread. |
|
readch |
Sonde qui se déclenche après chaque lecture réussie mais avant que le contrôle soit retourné au thread exécutant la lecture. Une lecture est possible par l'intermédiaire des appels système read(2), readv(2) ou pread(2). arg0 contient le nombre d'octets qui ont été correctement lus. |
|
rw_rdfails |
Sonde qui se déclenche à chaque exécution d'une tentative de verrouillage de la lecture sur des lecteurs/un graveur lorsque le verrou est détenu ou demandé par un graveur. Si cette sonde se déclenche, la sonde rw-block du fournisseur lockstat se déclenche également. Pour plus d'informations, reportez-vous au Chapitre18Fournisseur lockstat. |
|
rw_wrfails |
Sonde qui se déclenche à chaque tentative de verrouillage de l'écriture d'un verrou de lecteurs/graveur lorsque le verrou est détenu par plusieurs lecteurs ou par un autre graveur. Si cette sonde se déclenche, la sonde rw-block du fournisseur lockstat se déclenche également. Pour plus d'informations, reportez-vous au Chapitre18Fournisseur lockstat. |
|
sema |
Sonde qui se déclenche à chaque appel système semop(2) mais avant l'exécution d'opérations de sémaphore. |
|
sysexec |
Sonde qui se déclenche à chaque appel système exec(2). |
|
sysfork |
Sonde qui se déclenche à chaque appel système fork(2). |
|
sysread |
Sonde qui se déclenche à chaque appel système read(2), readv(2) ou pread(2). |
|
sysvfork |
Sonde qui se déclenche à chaque appel système vfork(2). |
|
syswrite |
Sonde qui se déclenche à chaque appel système write(2), writev(2) ou pwrite(2). |
|
trap |
Sonde qui se déclenche à chaque déroutement du processeur. Notez que certains processeurs, notamment de la gamme UltraSPARC, gèrent certains déroutements légers par l'intermédiaire d'un mécanisme qui n'entraîne pas le déclenchement de cette sonde. |
|
ufsdirblk |
Sonde qui se déclenche à chaque lecture d'un bloc de répertoires depuis le système de fichiers UFS. Pour plus de détails sur l'UFS, reportez-vous à ufs(7FS). |
|
ufsiget |
Sonde qui se déclenche à chaque récupération d'un inode. Pour plus de détails sur l'UFS, reportez-vous à ufs(7FS). |
|
ufsinopage |
Sonde qui se déclenche après la mise à disposition pour réutilisation d'un inode interne sans page de données liée. Pour plus de détails sur l'UFS, reportez-vous à ufs(7FS). |
|
ufsipage |
Sonde qui se déclenche après la mise à disposition pour réutilisation d'un inode interne avec pages de données liées. Cette sonde se déclenche après vidage des pages de données liées sur le disque. Pour plus de détails sur l'UFS, reportez-vous à ufs(7FS). |
|
writech |
Sonde qui se déclenche après chaque écriture réussie mais avant que le contrôle soit retourné au thread exécutant l'écriture. Une écriture est possible par l'intermédiaire des appels système write(2), writev(2) ou pwrite(2). arg0 contient le nombre d'octets qui ont été correctement écrits. |
|
xcalls |
Sonde qui se déclenche à chaque appel croisé sur le point d'être passé. Un appel croisé est un mécanisme du système d'exploitation permettant à une CPU de demander un travail immédiat à une autre CPU. |
Arguments
Les arguments vers les sondes sysinfo se présentent comme suit :
|
arg0 |
Valeur de laquelle les statistiques sont incrémentées. Cet argument est toujours égal à 1 pour la plupart des sondes. Il peut, toutefois, prendre une autre valeur pour certaines sondes. |
|
arg1 |
Pointeur vers la valeur courante des statistiques à incrémenter. Cette valeur, d'une quantité de 64–bits, sera incrémentée de la valeur de arg0. Déréférencer ce pointeur permet aux utilisateurs de déterminer la valeur courante des statistiques correspondant à la sonde. |
|
arg2 |
Pointeur vers la structure cpu_tqui correspond à la CPU sur laquelle les statistiques doivent être incrémentées. Cette structure est définie dans <sys/cpuvar.h>, mais elle fait partie intégrante de l'implémentation du noyau et doit être considérée comme Privée. |
La valeur de arg0 est de 1 pour la plupart des sondes sysinfo. Cependant, les sondes readch et writech définissent arg0 sur le nombre d'octets lus ou écrits, respectivement. Cette fonctionnalité vous permet de déterminer la taille des lectures par nom exécutable, comme illustré dans l'exemple ci-dessous :
# dtrace -n readch'{@[execname] = quantize(arg0)}'
dtrace: description 'readch' matched 4 probes
^C
xclock
value ------------- Distribution ------------- count
16 | 0
32 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1
64 | 0
acroread
value ------------- Distribution ------------- count
16 | 0
32 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 3
64 | 0
FvwmAuto
value ------------- Distribution ------------- count
2 | 0
4 |@@@@@@@@@@@@@ 13
8 |@@@@@@@@@@@@@@@@@@@@@ 21
16 |@@@@@ 5
32 | 0
xterm
value ------------- Distribution ------------- count
16 | 0
32 |@@@@@@@@@@@@@@@@@@@@@@@@ 19
64 |@@@@@@@@@ 7
128 |@@@@@@ 5
256 | 0
fvwm2
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@ 186
1 | 0
2 | 0
4 |@@ 51
8 | 17
16 | 0
32 |@@@@@@@@@@@@@@@@@@@@@@@@@@ 503
64 | 9
128 | 0
Xsun
value ------------- Distribution ------------- count
-1 | 0
0 |@@@@@@@@@@@ 269
1 | 0
2 | 0
4 | 2
8 |@ 31
16 |@@@@@ 128
32 |@@@@@@@ 171
64 |@ 33
128 |@@@ 85
256 |@ 24
512 | 8
1024 | 21
2048 |@ 26
4096 | 21
8192 |@@@@ 94
16384 | 0
|
Le fournisseur sysinfo définit arg2 en tant que pointeur vers une structure cpu_t (une structure interne vers l'implémentation du noyau). Les sondes sysinfo se déclenchent sur la CPU sur laquelle la statistique est incrémentée. Utilisez le membre cpu_id de la structure cpu_t pour déterminer la CPU qui vous intéresse.
Exemple
Examinez la sortie de mpstat(1M) suivante :
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 12 90 22 5760 422 299 435 26 71 116 11 1372 5 19 17 60 13 46 18 4585 193 162 431 25 69 117 12 1039 3 17 14 66 14 33 13 3186 405 381 397 21 58 105 10 770 2 17 11 70 15 34 19 4769 109 78 417 23 57 115 13 962 3 14 14 69 16 74 16 4421 437 406 448 29 77 111 8 1020 4 23 14 59 17 51 15 4493 139 110 378 23 62 109 9 928 4 18 14 65 18 41 14 4204 494 468 360 23 56 102 9 849 4 17 12 68 19 37 14 4229 115 87 363 22 50 106 10 845 3 15 14 67 20 78 17 5170 200 169 456 26 69 108 9 1119 5 21 25 49 21 53 16 4817 78 51 394 22 56 106 9 978 4 17 22 57 22 32 13 3474 486 463 347 22 48 106 9 769 3 17 17 63 23 43 15 4572 59 34 361 21 46 102 10 947 4 15 22 59 |
À partir de la sortie ci-dessus, vous pouvez conclure que le champ xcal semble trop grand, notamment du fait de la relative inactivité du système. mpstat détermine la valeur du champ xcal en examinant le champ xcalls des statistiques du noyau sys. Il est, par conséquent, facile d'étudier cette aberration en activant la sonde xcalls sysinfo, comme illustré dans l'exemple suivant :
# dtrace -n xcalls'{@[execname] = count()}'
dtrace: description 'xcalls' matched 4 probes
^C
dtterm 1
nsrd 1
in.mpathd 2
top 3
lockd 4
java_vm 10
ksh 19
iCald.pl6+RPATH 28
nwadmin 30
fsflush 34
nsrindexd 45
in.rlogind 56
in.routed 100
dtrace 153
rpc.rstatd 246
imapd 377
sched 431
nfsd 1227
find 3767
|
La sortie montre où chercher la source des appels croisés. Un certain nombre de processus find(1) provoquent la majorité des appels croisés. Le script en D suivant peut être utilisé pour comprendre le problème plus en détails :
syscall:::entry
/execname == "find"/
{
self->syscall = probefunc;
self->insys = 1;
}
sysinfo:::xcalls
/execname == "find"/
{
@[self->insys ? self->syscall : "<none>"] = count();
}
syscall:::return
/self->insys/
{
self->insys = 0;
self->syscall = NULL;
}
Ce script utilise le fournisseur syscall pour attribuer des appels croisés à un appel système particulier à partir de find. Certains appels croisés, dont ceux induits par les défauts de page, peuvent ne pas émaner des appels système. Le cas échéant, le script imprime “<none>”. Exécuter le script engendre une sortie similaire à l'exemple suivant :
# dtrace -s ./find.d dtrace: script './find.d' matched 444 probes ^C <none> 2 lstat64 2433 getdents64 14873 |
Cette sortie indique que la majorité des appels croisés induits par find sont en retour induits par les appels système getdents(2). Une étude plus approfondie dépend de ce que vous souhaitez étudier. Si vous souhaitez comprendre pourquoi les processus find appellent getdents, vous pouvez écrire en langage D un script d'agrégation sur ustack() lorsque find induit un appel croisé. Si vous souhaitez comprendre pourquoi les appels vers getdents induisent des appels croisés, vous pouvez écrire en langage D un script d'agrégation sur stack() lorsque find induit un appel croisé. Quelle que soit l'étape suivante, la présence de la sonde xcalls vous a permis de découvrir rapidement la cause première d'une sortie de contrôle inhabituelle.
Stabilité
Le fournisseur sysinfo utilise un mécanisme de stabilité pour présenter sa stabilité, 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 |
ISA |
|
Module |
Privé |
Privé |
Inconnu |
|
Fonction |
Privé |
Privé |
Inconnu |
|
Nom |
En cours d'évolution |
En cours d'évolution |
ISA |
|
Arguments |
Privé |
Privé |
ISA |
- © 2010, Oracle Corporation and/or its affiliates