Kapitel 23 Der Provider sysinfo
Der Provider sysinfo stellt Prüfpunkte für Kernelstatistiken zur Verfügung, die mit der Bezeichnung sys klassifiziert sind. Da auf diesen statistischen Daten Dienstprogramme zur Systemüberwachung wie etwa mpstat(1M) beruhen, ermöglicht der Provider sysinfo eine schnelle Untersuchung beobachteten Fehlverhaltens.
Prüfpunkte
Der Provider sysinfo stellt Prüfpunkte für die Felder unter der Bezeichnung sys in der Kernelstatistik bereit: Ein Prüfpunkt von sysinfo wird ausgelöst, unmittelbar bevor der entsprechende sys-Wert erhöht wird. Das folgende Beispiel zeigt, wie mithilfe des Befehls kstat(1M) sowohl die Namen als auch die aktuellen Werte der mit sys bezeichneten Kernelstatistiken angezeigt werden können.
$ kstat -n sys module: cpu instance: 0 name: sys class: misc bawrite 123 bread 2899 bwrite 17995 ... |
Die sysinfo-Prüfpunkte sind in Tabelle 23–1 beschrieben.
Tabelle 23–1 sysinfo-Prüfpunkte|
bawrite |
Prüfpunkt, der immer kurz vor der asynchronen Ausgabe eines Puffers an ein Gerät ausgelöst wird. |
|
bread |
Prüfpunkt, der immer dann ausgelöst wird, wenn ein Gerät einen Puffer physisch ausliest. bread wird ausgelöst, nachdem der Puffer vom Gerät angefordert wurde, aber noch vor der Blockierung in Erwartung der Durchführung. |
|
bwrite |
Prüfpunkt, der immer kurz vor der synchronen oder asynchronen Ausgabe eines Puffers an ein Gerät ausgelöst wird. |
|
idlethread |
Prüfpunkt der ausgelöst wird, wenn eine CPU die Leerlaufschleife betritt. |
|
intrblk |
Prüfpunkt der ausgelöst wird, wenn ein Interrupt-Thread blockiert wird. |
|
inv_swtch |
Prüfpunkt, der ausgelöst wird, wenn ein laufender Thread gezwungen ist, die CPU aufzugeben. |
|
lread |
Prüfpunkt, der immer dann ausgelöst wird, wenn ein Gerät einen Puffer logisch ausliest. |
|
lwrite |
Prüfpunkt, der immer dann ausgelöst wird, wenn ein Puffer logisch auf ein Gerät geschrieben wird. |
|
modload |
Prüfpunkt der bei jedem Laden eines Kernelmoduls ausgelöst wird. |
|
modunload |
Prüfpunkt der bei jedem Entfernen eines Kernelmoduls aus dem Speicher ausgelöst wird. |
|
msg |
Prüfpunkt, der bei jedem msgsnd(2)- oder msgrcv(2)-Systemaufruf, aber noch vor der Durchführung der Message-Queue-Operationen ausgelöst wird. |
|
mutex_adenters |
Prüfpunkt, der bei jedem Versuch ausgelöst wird, eine belegte adaptive Sperre zu erlangen. Wenn dieser Prüfpunkt ausgelöst wird, wird auch einer der Prüfpunkte adaptive-block oder adaptive-spin des Providers lockstat ausgelöst. Ausführliche Informationen finden Sie in Kapitel 18Der Provider lockstat. |
|
namei |
Prüfpunkt, der ausgelöst wird, wenn ein Name im Dateisystem gesucht (lookup) wird. |
|
nthreads |
Prüfpunkt, der bei jeder Erzeugung eines Threads ausgelöst wird. |
|
phread |
Prüfpunkt, der ausgelöst wird, wenn ein Raw-E/A-Lesezugriff ansteht. |
|
phwrite |
Prüfpunkt, der ausgelöst wird, wenn ein Raw-E/A-Schreibzugriff ansteht. |
|
procovf |
Prüfpunkt, der ausgelöst wird, wenn ein neuer Prozess nicht erzeugt werden kann, da dem System keine Prozesstabelleneinträge mehr zur Verfügung stehen. |
|
pswitch |
Prüfpunkt, der ausgelöst wird, wenn eine CPU von der Ausführung des einen zur Ausführung eines anderen Threads wechselt. |
|
readch |
Prüfpunkt, der nach jedem erfolgreichen Lesezugriff ausgelöst wird, aber noch bevor die Kontrolle wieder an den den Lesezugriff durchführenden Thread übergeben wird. Ein Lesezugriff kann über die Systemaufrufe read(2), readv(2) oder pread(2) erfolgen. arg0 enthält die Anzahl der Byte, die erfolgreich gelesen wurden. |
|
rw_rdfails |
Prüfpunkt, der immer dann ausgelöst wird, wenn ein Versuch stattfindet, eine Lesesperre auf eine Leser/Schreiber-Sperre zu legen, wenn die Sperre entweder von einem Schreiber belegt ist oder gefordert wird. Wenn dieser Prüfpunkt ausgelöst wird, wird auch der Prüfpunkt rw-block des Providers lockstat ausgelöst. Ausführliche Informationen finden Sie in Kapitel 18Der Provider lockstat. |
|
rw_wrfails |
Prüfpunkt, der immer dann ausgelöst wird, wenn ein Versuch stattfindet, eine Schreibsperre auf eine Leser/Schreiber-Sperre zu legen, wenn die Sperre entweder von Lesern oder einem anderen Schreiber belegt ist. Wenn dieser Prüfpunkt ausgelöst wird, wird auch der Prüfpunkt rw-block des Providers lockstat ausgelöst. Ausführliche Informationen finden Sie in Kapitel 18Der Provider lockstat. |
|
sema |
Prüfpunkt, der bei jedem semop(2)-Systemaufruf, aber noch vor der Durchführung etwaiger Semaphor-Operationen ausgelöst wird. |
|
sysexec |
Prüfpunkt, der bei jedem exec(2)-Systemaufruf ausgelöst wird. |
|
sysfork |
Prüfpunkt, der bei jedem fork(2)-Systemaufruf ausgelöst wird. |
|
sysread |
Prüfpunkt, der bei jedem Systemaufruf von read(2), readv(2) oder pread(2) ausgelöst wird. |
|
sysvfork |
Prüfpunkt, der bei jedem vfork(2)-Systemaufruf ausgelöst wird. |
|
syswrite |
Prüfpunkt, der bei jedem Systemaufruf von write(2), writev(2) oder pwrite(2) ausgelöst wird. |
|
trap |
Prüfpunkt, der bei jedem Prozessor-Trap ausgelöst wird. Beachten Sie, dass einige Prozessoren, insbesondere Varianten von UltraSPARC, bestimmte leichtgewichtige Traps über einen Mechanismus behandeln, der diesen Prüfpunkt nicht auslöst. |
|
ufsdirblk |
Prüfpunkt, der ausgelöst wird, wenn ein Verzeichnisblock aus dem UFS-Dateisystem ausgelesen wird. Ausführliche Informationen zu UFS finden Sie unter ufs(7FS). |
|
ufsiget |
Prüfpunkt, der bei jedem Abruf eines Inodes aufgerufen wird. Ausführliche Informationen zu UFS finden Sie unter ufs(7FS). |
|
ufsinopage |
Prüfpunkt, der ausgelöst wird, nachdem ein Incore-Inode ohne zugehörige Datenseiten zur Wiederverwendung freigegeben wurde. Ausführliche Informationen zu UFS finden Sie unter ufs(7FS). |
|
ufsipage |
Prüfpunkt, der ausgelöst wird, nachdem ein Incore-Inode mit zugehörigen Datenseiten zur Wiederverwendung freigegeben wurde. Dieser Prüfpunkt wird ausgelöst, nachdem die zugehörigen Datenseiten auf die Festplatte entleert wurden. Ausführliche Informationen zu UFS finden Sie unter ufs(7FS). |
|
writech |
Prüfpunkt, der nach jedem erfolgreichen Schreibzugriff ausgelöst wird, aber noch bevor die Kontrolle wieder an den den Schreibzugriff durchführenden Thread übergeben wird. Ein Schreibzugriff kann über die Systemaufrufe write(2), writev(2) oder pwrite(2) erfolgen. arg0 enthält die Anzahl der Byte, die erfolgreich geschrieben wurden. |
|
xcalls |
Prüfpunkt, der immer kurz vor einem gegenseitigen Aufruf ausgelöst wird. Ein gegenseitiger Aufruf ist der Mechanismus des Betriebssystems, über den eine CPU den sofortigen Einsatz einer anderen CPU fordert. |
Argumente
Die Argumente für sysinfo-Prüfpunkte lauten:
|
arg0 |
Der Wert, um den die statistische Angabe zu erhöhen ist. Bei den meisten Prüfpunkten beträgt der Wert dieses Arguments stets 1, bei einigen kann das Argument andere Werte annehmen. |
|
arg1 |
Ein Zeiger auf den aktuellen Wert der zu erhöhenden statistischen Angabe. Dieser Wert ist eine 64-Bit-Größe, die um den Wert in arg0 erhöht wird. Durch Dereferenzierung dieses Zeigers können die Verbraucher die aktuelle Gesamtzahl der zum Prüfpunkt gehörigen statistischen Angabe ermitteln. |
|
arg2 |
Ein Zeiger auf die Struktur cpu_t, die für die CPU steht, auf der die statistische Angabe erhöht werden soll. Diese Struktur ist in <sys/cpuvar.h> definiert, ist aber Bestandteil der Kernel-Implementierung und sollte als „Private“ betrachtet werden. |
Der Wert von arg0 beträgt bei den meisten sysinfo-Prüfpunkten 1. Die Prüfpunkte readch und writech setzen arg0 jedoch auf die Anzahl der gelesenen bzw. geschriebenen Byte. Mit diesem Leistungsmerkmal lässt sich, wie das folgende Beispiel zeigt, die Größe von Lesezugriffen nach Namen der ausführbaren Datei ermitteln:
# 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
|
Der Provider sysinfo setzt arg2 als einen Zeiger auf cpu_t, eine interne Struktur der Kernel-Implementierung. Die sysinfo-Prüfpunkte werden auf der CPU ausgelöst, auf der die Statistik inkrementiert wird. Mit der Komponente cpu_id der Struktur cpu_t bestimmen Sie die relevante CPU.
Beispiel
Betrachten Sie die folgende Ausgabe von mpstat(1M):
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 |
Aus dieser Ausgabe könnte man schließen, dass das Feld xcal, insbesondere angesichts des relativen Leerlaufs des Systems, zu hoch ausfällt. mpstat bestimmt den Wert im Feld xcal über das Feld xcalls in der sys-Kernelstatistik. Diese Abweichung lässt sich deshalb problemlos durch Aktivierung des Prüfpunkts xcalls sysinfo untersuchen, wie das nächste Beispiel zeigt:
# 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
|
Die Ausgabe zeigt, wo nach der Quelle der gegenseitigen Aufrufe zu suchen ist. Einige find(1)-Prozesse verursachen den Großteil der gegenseitigen Aufrufe. Das nächste D-Skript hilft, dem Problem weiter auf den Grund zu gehen:
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;
}
In diesem Skript wird der Provider syscall dazu verwendet, gegenseitige Aufrufe aus find einem bestimmten Systemaufruf zuzuordnen. Einige gegenseitige Aufrufe, wie solche, die aus Seitenfehlern entstehen, gehen nicht von Systemaufrufen aus. In diesen Fällen gibt das Skript „<none>” aus. Die Ausführung dieses Skripts erzeugt eine Ausgabe wie in folgendem Beispiel:
# dtrace -s ./find.d dtrace: script './find.d' matched 444 probes ^C <none> 2 lstat64 2433 getdents64 14873 |
Diese Ausgabe deutet darauf hin, dass die Mehrheit der von find bewirkten gegenseitigen Aufrufe ihrerseits durch getdents(2)-Systemaufrufe verursacht wurden. Für eine weitere Untersuchung wäre die gewünschte Richtung ausschlaggebend. Wenn Sie verstehen möchten, weshalb find-Prozesse getdents-Aufrufe tätigen, könnten Sie ein D-Skript schreiben, das ustack() aggregiert, wenn find einen gegenseitigen Aufruf verursacht. Wenn es Sie interessiert, weshalb getdents-Aufrufe gegenseitige Aufrufe verursachen, bietet sich ein D-Skript an, das ustack() aggregiert, wenn find einen gegenseitigen Aufruf verursacht. Welche Richtung Sie auch immer einschlagen, hat Ihnen der Prüfpunkt xcalls die Möglichkeit gegeben, die Ursache der ungewöhnlichen Überwachungsausgabe aufzudecken.
Stabilität
Der Provider sysinfo beschreibt die verschiedenen Stabilitäten anhand des DTrace-Stabilitätsmechanismus gemäß der folgenden Tabelle. Weitere Informationen zum Stabilitätsmechanismus finden Sie in Kapitel 39Stabilität.
|
Element |
Namensstabilität |
Datenstabilität |
Abhängigkeitsklasse |
|---|---|---|---|
|
Provider |
Evolving |
Evolving |
ISA |
|
Modul |
Private |
Private |
Unknown |
|
Funktion |
Private |
Private |
Unknown |
|
Name |
Evolving |
Evolving |
ISA |
|
Argumente |
Private |
Private |
ISA |
- © 2010, Oracle Corporation and/or its affiliates