2.5. Red Hat Enterprise Linux-spezifische Informationen
Red Hat Enterprise Linux wird mit einer Reihe von Ressourcenüberwachungstools ausgeliefert. Während es mehr Tools als die hier aufgeführten gibt, sind diese hier charakteristisch für Funktionalität. Die Tools sind:
free
top (und GNOME System Monitor, eine grafisch orientierte Versionen von top)
vmstat
Die Sysstat-Suite an Ressourcenkontrolletools
Der systemweite OProfile-Profiler
Lassen Sie uns jedes dieser Tools im Detail betrachten.
2.5.1. free
Der free-Befehl zeigt die Speicherausnutzung an. Hier ein Beispiel der Ausgabe:
total used free shared buffers cached Mem: 255508 240268 15240 0 7592 86188 -/+ buffers/cache: 146488 109020 Swap: 530136 26268 503868 |
Die Zeile Mem: zeigt die Nutzung des physikalischen Speichers, während Swap: die Ausnutzung des System-Swap-Platzes zeigt. Die Zeile -/+ buffers/cache: zeigt die Größe des physikalischen Speichers an, welcher derzeit den Systempuffern gehört.
Da free standardmäßig die Informationen zur Speichernutzung nur einmal anzeigt, ist er nur nützlich für kurzzeitiges Überwachen oder zum raschen Feststellen, ob ein Speicher-bezogenes Problem vorliegt. Auch wenn free die Fähigkeit hat, wiederholt die Daten zur Speichernutzung über die Option -s anzuzeigen, läuft die Ausgabe relativ schnell über den Bildschirm, was ein Auffinden von Änderungen in der Speichernutzung schwierig gestaltet.
 | Tipp | ||
|---|---|---|---|
Eine bessere Lösung alsfree -s ist das Ausführen von free mit dem watch-Befehl. Um zum Beispiel die Speichernutzung alle zwei Sekunden anzuzeigen (das Standard-Intervall für watch), verwenden Sie den folgenden Befehl:
Der watch-Befehl gibt den Befehl free alle zwei Sekunden aus und löscht vorher den Bildschirm. Dies macht es wesentlich einfacher festzustellen, wie sich die Speichernutzung über eine gewisse Zeit hinweg ändert, da Sie nicht ständig über den Bildschirm laufenden Output durchsuchen müssen. Sie können die Verzögerung zwischen den Aktualisierungen mit der Option -n kontrollieren und können alle Änderungen zwischen Updates markieren lassen, indem Sie die Option -d wie im folgenden Befehl verwenden:
Weitere Informationen finden Sie auf der watch man-Seite. Der watch-Befehl wird solange ausgeführt, bis dieser mit |
2.5.2. top
Während free nur Speicher-bezogene Informationen anzeigt, bietet der top-Befehl ein wenig von Allem. CPU-Nutzung, Prozess-Statistiken, Speichernutzung — top überwacht all dies. Zusätzlich dazu und im Gegensatz zu free ist das Standardverhalten von top kontinuierlich abzulaufen. Der watch-Befehl wird nicht benötigt. Dazu ein Beispiel:
14:06:32 up 4 days, 21:20, 4 users, load average: 0.00, 0.00, 0.00
77 processes: 76 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: cpu user nice system irq softirq iowait idle
total 19.6% 0.0% 0.0% 0.0% 0.0% 0.0% 180.2%
cpu00 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 100.0%
cpu01 19.6% 0.0% 0.0% 0.0% 0.0% 0.0% 80.3%
Mem: 1028548k av, 716604k used, 311944k free, 0k shrd, 131056k buff
324996k actv, 108692k in_d, 13988k in_c
Swap: 1020116k av, 5276k used, 1014840k free 382228k cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
17578 root 15 0 13456 13M 9020 S 18.5 1.3 26:35 1 rhn-applet-gu
19154 root 20 0 1176 1176 892 R 0.9 0.1 0:00 1 top
1 root 15 0 168 160 108 S 0.0 0.0 0:09 0 init
2 root RT 0 0 0 0 SW 0.0 0.0 0:00 0 migration/0
3 root RT 0 0 0 0 SW 0.0 0.0 0:00 1 migration/1
4 root 15 0 0 0 0 SW 0.0 0.0 0:00 0 keventd
5 root 34 19 0 0 0 SWN 0.0 0.0 0:00 0 ksoftirqd/0
6 root 35 19 0 0 0 SWN 0.0 0.0 0:00 1 ksoftirqd/1
9 root 15 0 0 0 0 SW 0.0 0.0 0:07 1 bdflush
7 root 15 0 0 0 0 SW 0.0 0.0 1:19 0 kswapd
8 root 15 0 0 0 0 SW 0.0 0.0 0:14 1 kscand
10 root 15 0 0 0 0 SW 0.0 0.0 0:03 1 kupdated
11 root 25 0 0 0 0 SW 0.0 0.0 0:00 0 mdrecoveryd |
Die Anzeige ist in zwei Abschnitte unterteilt. Der obere Abschnitt enthält Informationen zum Gesamtstatus des Systems — Laufzeit, Lastdurchschnitt, Prozesszahlen, CPU-Status und Nutzungsstatistiken für Speicher und Swap-Space. Im unteren Abschnitt werden Statistiken auf Prozess-Ebene angezeigt, die gesteuert werden können, wenn top ausgeführt wird. Zum Beispiel zeigt top lediglich Prozesse an, auch wenn ein Prozess multi-threaded ist. Um die einzelnen Threads anzuzeigen, drücken Sie
 | Achtung |
|---|---|
Auch wenn top wie ein einfaches, reines Anzeige-Programm erscheint, ist dies nicht der Fall. Dies liegt daran, dass top sog. Einzelzeichen-Befehle für die verschiedenen Aufgaben verwendet. Wenn Sie zum Beispiel als root angemeldet sind, können Sie die Priorität eines Prozesses ändern oder diesen stoppen. Solange Sie nicht die Hilfe zu top gelesen haben (drücken Sie |
2.5.2.1. Der GNOME System Monitor — Ein grafischer top-Befehl
Wenn Sie grafische Oberflächen vorziehen, ist vielleicht der GNOME System Monitor eher für Sie geeignet. Wie top zeigt der GNOME System Monitor Informationen in Bezug auf den Gesatmstatus des Systems, Prozesszahlen, Speicher- und Swap-Nutzung sowie Statistiken auf Prozessebene an.
Der GNOME System Monitor geht noch einen Schritt weiter, indem er eine grafische Darstellung von CPU, Speicher und Swap-Nutzung sowie eine tabellenförmige Nutzungsliste zum Festplattenplatz anzeigt. Ein Beispiel der GNOME System Monitor Prozessliste finden Sie unter Abbildung 2-1.
Zusätzliche Informationen können für einen bestimmten Prozess angezeigt werden, indem Sie den gewünschten Prozess auswählen und dann auf Mehr Info klicken.
Um Statistiken zu CPU, Speicher und Festplattennutzung anzuzeigen, klicken Sie auf System Monitor.
2.5.3. vmstat
Für ein präziseres Verständnis der Systemleistung versuchen Sie es doch einfach mit vmstat. Mit vmstat erhalten Sie einen Überblick über Prozesse, Speicher, Swap, I/O, System und CPU-Aktivität in einer einzigen Zahlenreihe:
procs memory swap io system cpu
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 5276 315000 130744 380184 1 1 2 24 14 50 1 1 47 0
|
Die erste Zeile unterteilt das Feld in sechs Kategorien, inklusive Prozesse, Speicher, Swap, I/O, System und CPU Statistiken. Die zweite Zeile identifiziert den Inhalt jeden Feldes, was das rasche und einfache Suchen nach bestimmten Statistiken innerhalb der Daten ermöglicht.
Die Prozess-bezogenen Felder sind:
r — Die Anzahl ausführbarer Prozesse, die auf Zugriff zur CPU warten
b — Die Anzahl der Prozesse in einem nicht-unterbrechbaren Sleep-State (Throttel-State)
Die Speicher-bezogenen Felder sind:
swpd — Die Größe des verwendeten virtuellen Speichers
free — Freier Speicher
buff — Größe des für Puffer verwendeten Speichers
cache — Speicher, der als Page-Cache verwendet wird
Die Swap-bezogenen Felder sind:
si — Der Speicher, der von der Festplatte geswappt wurde
so — Der Speicher, der auf die Festplatte geswappt wurde
Die I/O-bezogenen Felder sind:
bi — An ein Blockgerät gesendete Blöcke
bo — Von einem Blockgerät empfangene Blöcke
Die system-bezogenen Felder sind:
in — Die Anzahl der Interrupts pro Sekunde
cs — Die Anzahl der Context-Switches pro Sekunde
Die CPU-bezogenen Felder sind:
us — der Prozentsatz der Zeit, in der die CPU Benutzer-Level Code ausführt
sy — der Prozentsatz der Zeit, in der die CPU System-Level Code ausführt
id — der Prozentsatz der Zeit, in der die CPU im Leerlauf war
wa — Eingang/Ausgang warten
Wird vmstat ohne Optionen ausgeführt, wird nur eine Zeile angezeigt. Diese Zeile enthält Durchschnitte, die von der Zeit an berechnet wurden, zu der das System das letzte Mal gebootet wurde.
Die meisten Administratoren verlassen sich jedoch nicht auf die Daten in dieser Zeile, da die Zeit, in der diese gesammelt werden, variiert. Stattdessen nutzen sie den Vorteil von vmstats Fähigkeit, Ressourcendaten zu bestimmten Intervallen wiederholt anzuzeigen. So zeigt zum Beispiel der Befehl vmstat 1 eine neue Ressourcenzeile jede Sekunde an, während der Befehl vmstat 1 10 eine neue Zeile pro Sekunde anzeigt; jedoch nur für die nächsten zehn Sekunden.
In den Händen eines erfahrenen Administrators kann vmstat zum idealen Werkzeug werden, um rasch Ressourcen-Nutzung und Leistungsprobleme feststellen zu können. Für einen tieferen Einblick wird eine andere Art von Tool benötigt — ein Tool, das eine tiefgreifendere Datenerfassung und -analyse ermöglicht.
2.5.4. Die Sysstat-Suite von Ressourcenüberwachungstools
Während die oben genannten Tools dabei hilfreich sein können, mehr Einblick in die Leistungsfähigkeit eines Systems über sehr kurze Zeiträume hinweg zu bekommen, sind diese nicht von großem Nutzen, wenn mehr als nur ein Schnappschuß der Systemressourcenauslastung benötigt wird. Zusätzlich gibt es einige Aspekte der Leistungsfähigkeit eines Systems, die nicht einfach mittels solcher simplistischen Tools überwacht werden können.
Deshalb ist ein anspruchsvolleres Tool notwendig. Sysstat ist ein solches Tool.
Sysstat beinhaltet die folgenden Tools in Bezug auf das Sammeln von Eingabe/Ausgabe- und CPU-Statistiken:
- iostat
Gibt einen Überblick über die CPU-Auslastung, gemeinsam mit I/O-Statistiken für eines oder für mehrere Laufwerke.
- mpstat
Zeigt detaillgenauere CPU-Statistiken an.
Sysstat beinhaltet ebenso Tools, die Daten zur Systemressourcenauslastung sammeln und tägliche, auf diesen Daten basierende Reporte erstellen. Diese Tools sind:
- sadc
Bekannt als System Activity Data Collector, sammelt der Befehl sadc Systemressourcen-Informationen und schreibt diese in eine Datei.
- sar
sar-Reporte, die aus den von sadc erstellten Dateien erzeugt werden, können entweder interaktiv generiert werden oder für eine intensivere Analyse in eine Datei geschrieben werden.
Die folgenden Abschnitte erforschen jedes einzelne dieser Tools in allen Einzelheiten.
2.5.4.1. Der iostat-Befehl
Der iostat-Befehl vermittelt grundsätzlich einen Überblick über CPU- und Eingang/Ausgang-Statistiken:
Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07/11/2003
avg-cpu: %user %nice %sys %idle
6.11 2.56 2.15 89.18
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
dev3-0 1.68 15.69 22.42 31175836 44543290
|
Unter der ersten Zeile (welche die Kernelversion des Systems und den Hostnamen gemeinsam mit dem aktuellen Datum beinhaltet), zeigt iostat einen Überblick über die durchschnittliche CPU-Auslastung des Systems seit dem letzten Reboot-Vorgang an. Der CPU-Auslastungs-Report beinhaltet folgende Prozentsätze:
Prozentualer Anteil der Zeit, die im Benutzermodus verbracht wurde (laufende Applikationen, usw.)
Prozentualer Anteil der Zeit, die im Benutzermodus verbracht wurde (für Prozesse, deren Planungsprioritäten mittels nice(2) geändert wurden)
Prozentualer Anteil der Zeit, die im Kernelmodus verbracht wurde
Prozentualer Anteil der Zeit, die im Leerlauf verbracht wurde
Unter dem Report zur CPU-Auslastung ist der Geräte-Auslastungs-Report anzufinden. Dieser Report beinhaltet eine Zeile für jedes einzelne aktive Platten-Device auf dem System und beinhaltet die folgenden Informationen:
Die Gerätespezifikation, dargestellt als dev<major-number>-sequence-number, wobei <major-number> die Major-Nummer des Gerätes darstellt[1] und <sequence-number> eine aufeinanderfolgende Nummer ist, welche mit Null beginnt.
Die Transferhäufigkeit (oder Eingabe/Ausgabe-Operationen) pro Sekunde.
Die Anzahl von 512-Byte-Blöcken, die pro Sekunde gelesen wurden.
Die Anzahl von 512-Byte-Blöcken, die pro Sekunde beschrieben wurden.
Die Gesamtanzahl von 512-Byte-Blöcken, die gelesen wurden.
Die Gesamtanzahl von 512-Byte-Blöcken, die beschrieben wurden.
Dies ist nur ein Beispiel der Information, welche mittels dem iostat-Befehl erlangt werden können. Für weitere Informationen siehe die iostat(1) man-Seite.
2.5.4.2. Der mpstat-Befehl
Der mpstat-Befehl erscheint zunächst keine Unterschiede zum CPU-Auslastungs-Report aufzuweisen, welcher mittels dem iostat-Befehl erstellt wurde:
Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07/11/2003
07:09:26 PM CPU %user %nice %system %idle intr/s
07:09:26 PM all 6.40 5.84 3.29 84.47 542.47
|
Mit der Ausnahme einer zusätzlichen Spalte, welche die CPU-bezogenen Interrupts pro Sekunde anzeigt, gibt es keinen wirklichen Unterschied. Jedoch ändert sich dies, wenn die mpstats -P ALL-Option verwendet wird:
Linux 2.4.20-1.1931.2.231.2.10.ent (pigdog.example.com) 07/11/2003
07:13:03 PM CPU %user %nice %system %idle intr/s
07:13:03 PM all 6.40 5.84 3.29 84.47 542.47
07:13:03 PM 0 6.36 5.80 3.29 84.54 542.47
07:13:03 PM 1 6.43 5.87 3.29 84.40 542.47
|
Auf Multiprozessor-Systemen ermöglicht mpstat die Auslastung für jede CPU individuell anzuzeigen, um feststellen zu können, wie effektiv jede CPU genutzt wird.
2.5.4.3. Der sadc-Befehl
Wie bereits zuvor beschrieben, werden durch den sadc-Befehl Systemauslastungsdaten gesammelt, die zur Analyse zu einem späteren Zeitpunkt in eine Datei geschrieben werden. Standardmäßig werden die Daten in Dateien geschrieben, die sich im Verzeichnis /var/log/sa/ befinden. Die Dateien werden sa<dd> genannt, wobei <dd> das aktuelle zweistellige Datum ist.
sadc wird normalerweise vom sa1-Script durchgeführt. Dieses Script wird periodisch durch cron über die Datei sysstat aufgerufen, welche sich in /etc/cron.d/ befindet. Das sa1-Script ruft sadc zu einem einzelnen einsekündigen Messintervall auf. Standardmäßig bringtcron sa1 alle 10 Minuten zum ablaufen, wobei die gesammelten Daten während jedem Intervall zur aktuellen /var/log/sa/sa<dd>-Datei hinzugefügt werden.
2.5.4.4. Der sar-Befehl
Der sar-Befehl erzeugt System-Nutzungs-Reporte basierend auf Daten, die vonsadc gesammelt wurden. Die Red Hat Enterprise Linux-Konfigurierung lässt sar automatisch ablaufen, um die Dateien zu verarbeiten, welche ebenso automatisch von sadc gesammelt werden. Die Report-Dateien werden in /var/log/sa/ geschrieben undsar<dd>genannt, wobei<dd> das Datum des vorhergehenden Tages zweistellig darstellt.
sar wird normalerweise mittels sa2-Script durchgeführt. Dieses Script wird periodisch durch cron über die Dateisysstat aufgerufen, welche sich in /etc/cron.d/ befindet. Standardmäßig lässt cron den Befehl sa2 einmalt täglich um 23:53 ablaufen, wobei ein Report über die sämtlichen Daten des jeweiligen Tages erstellt wird.
2.5.4.4.1. Das Lesen von sar-Reporten
Das Format eines sar-Reportes, der durch die standardmäßige Konfiguration von Red Hat Enterprise Linux erstellt worden ist, besteht aus verschiedenen Sektionen, wobei jede Sektion eine spezifische Art von Daten enthält; gegliedert nach dem Zeitpunkt, zu dem diese gesammelt wurden. Da sadc dahingehend konfiguriert ist, alle zehn Minuten einen ein-sekündigen Messintervall auszuführen, beinhalten die standardmäßigen sar-Reporte Daten in zehn-minütigen Abschnitten von 00:00 bis 23:50 Uhr[2].
Jeder Abschnitt des Reports beginnt mit einem Titel, welcher die in diesem Abschnitt enthaltenen Daten beschreibt. Der Titel wird in regelmäßigen Abständen im gesamten Abschnitt wiederholt. Dies vereinfacht die Auswertung der Daten, während man durch den Report blättert. Jeder Abschnitt endet mit einer Zeile, die den Durchschnitt der im jeweiligen Abschnitt behandelten Daten angibt.
Hier ist ein Beispielabschnitt zu einem sar-Report ohne den Daten von 00:30 bis 23:40 Uhr, um Platz zu sparen:
00:00:01 CPU %user %nice %system %idle
00:10:00 all 6.39 1.96 0.66 90.98
00:20:01 all 1.61 3.16 1.09 94.14
…
23:50:01 all 44.07 0.02 0.77 55.14
Average: all 5.80 4.99 2.87 86.34
|
In diesem Abschnitt wird die CPU-Auslastungsinformation angezeigt. Diese sind den durch iostat angezeigten Daten sehr ähnlich.
Andere Abschnitte können auch mehr als eine Daten-Zeile zu einem bestimmten Zeitpunkt aufweisen, wie in diesem Abschnitt über CPU-Nutzungsdaten ersichtlich ist, welche auf einem Dual-Prozessorsystem gesammelt wurden:
00:00:01 CPU %user %nice %system %idle
00:10:00 0 4.19 1.75 0.70 93.37
00:10:00 1 8.59 2.18 0.63 88.60
00:20:01 0 1.87 3.21 1.14 93.78
00:20:01 1 1.35 3.12 1.04 94.49
…
23:50:01 0 42.84 0.03 0.80 56.33
23:50:01 1 45.29 0.01 0.74 53.95
Average: 0 6.00 5.01 2.74 86.25
Average: 1 5.61 4.97 2.99 86.43
|
Es gibt eine Gesamtanzahl von siebzehn verschiedenen Abschnitten in Reporten, die mittels der standardmäßigen Red Hat Enterprise Linux sar-Konfiguration erstellt werden. Einige werden in den folgenden Kapiteln näher behandelt. Für nähere Informationen über die Daten in den einzelnen Abschnitten siehe die sar(1) man-Seite.
2.5.5. OProfile
Der systemweite Profiler OProfile ist ein Low-Overhead Überwachungstool. OProfile benutzt dazu die Leistungskontrolle-Hardware des Prozessors[3], um die Natur leistungsbezogener Probleme genau festzustellen.
Leistungskontrolle-Hardware ist ein Teil des Prozessors selbst. In Form eines speziellen Counters, dessen Wert sich jedes mal erhöht, wenn ein bestimmter Vorgang (z.B. wenn der Prozessor sich nicht im Leerlauf befindet (nicht idle ist) oder die angeforderten Daten nicht im Cache aufzufinden sind) stattfindet. Einige Prozessoren besitzen mehr als einen solchen Counter und erlauben dadurch die Selektion unterschiedlicher Arten von Vorgängen für jeden einzelnen Counter.
Die Counter können mit einem anfänglichen Wert geladen werden und erzeugen jedes mal ein Interrupt im Falle eines Counter-Overflows. Durch das Laden eines Counters mit verschiedenen anfänglichen Werten, ist es möglich die Rate zu variieren, zu der Interrupts erzeugt werden. Auf diese Art ist es möglich, die Sample-Rate zu kontrollieren und somit auch den Grad an Detailgenauigkeit in Hinsicht auf die gesammelten Daten zu bestimmen.
In einem Extremfall würde die Einstellung des Counters, sodass dieser einen Overflow-Interrupt bei jedem Vorgang erzeugt, den Erhalt extrem detaillierter Leistungsdaten (jedoch mit massivem Overhead) bedeuten. Im entgegengesetzten Extremfall würde die Einstellung des Counters, sodass dieser so wenige Interrupts als möglich erzeugt, lediglich den Erhalt eines höchst allgemeinen System-Überblicks bedeuten (mit praktisch keinem Overhead). Das Geheimnis einer effektiven Überwachung ist die Auswahl einer Sample-Rate, welche ausreichend hoch ist, um die erforderlichen Daten zu erfassen, wobei das System jedoch gleichzeitig nicht mit Leistungskontrolle-Overhead überlastet wird.
| Achtung |
|---|---|
Sie können OProfile derart konfigurieren, sodass es ausreichend Overhead produziert, um das System unbenutzbar zu machen. Deshalb müssen Sie Vorsicht walten lassen, wenn Sie Counter-Werte auswählen. Aus diesem Grund unterstützt der opcontrol-Befehl die --list-events-Option, welche die vorhandenen Event-Typen für den gegenwärtig installierten Prozessor gemeinsam mit den jeweils empfohlenen Minimal-Counter-Werten anzeigt. |
Es ist wichtig einen Kompromiss zwischen Sample-Rate und Overhead einzugehen, wenn Sie OProfile benutzen.
2.5.5.1. OProfile-Komponenten
OProfile besteht aus folgenden Komponenten:
Datenerfassungssoftware
Datenanalysesoftware
Administrative Schnittstellen-Software
Die Datenerfassungssoftware besteht aus dem oprofile.o Kernel-Modul und dem oprofiled-Daemon.
Die Datenanalysesoftware beinhaltet folgende Programme:
- op_time
Zeigt die Anzahl und den relativen Prozentsatz von Samples (Proben) für jede einzelne ausführbare Datei an.
- oprofpp
Zeigt die Anzahl und den relativen Prozentsatz von Samples an, die entweder durch eine Funktion, individuelle Befehle oder in Form einer gprof-stil Ausgabe erstellt worden sind
- op_to_source
Zeigt kommentierten Sourcecode und/oder Assemblerprotokolle an
- op_visualise
Zeigt gesammelte Daten graphisch an
Diese Programme machen es möglich, gesammelte Daten in einer Vielzahl von Arten anzuzeigen.
Die administrative Schnittstellen-Software kontrolliert alle Aspekte der Datensammlung, von der genauen Bestimmung, welche Art von Daten kontrolliert werden müssen bis hin zum Start- und Anhaltevorgang des eigentlichen Sammelvorganges. Dies kann mittels opcontrol-Befehl durchgeführt werden.
2.5.5.2. Beispiel für eine OProfile-Sitzung
Dieser Abschnitt zeigt eine OProfile Kontroll- und Datenanalyse-Sitzung von der ursprünglichen Konfiguration bis hin zur schlussendlichen Datenanalyse. Dies ist lediglich ein einleitender Überblick. Für detailliertere Informationen, verweisen wir auf das Red Hat Enterprise Linux Handbuch zur System-Administration.
Benutzen Sie opcontrol, um den Datentyp zu konfigurieren, welcher mittels folgendem Befehl gesammelt werden soll:
opcontrol \
--vmlinux=/boot/vmlinux-`uname -r` \
--ctr0-event=CPU_CLK_UNHALTED \
--ctr0-count=6000 |
Die hierbei benutzten Optionen dienen zur Ausrichtung von opcontrol:
Richten Sie OProfile auf eine Kopie des derzeit laufenden Kernels aus (--vmlinux=/boot/vmlinux-`uname -r`)
Legen Sie fest, dass der Prozessor-Counter 0 benutzt wird und dass das Event, welches kontrolliert werden soll, der Zeitpunkt ist, an dem von der CPU Instruktionen ausgeführt werden (--ctr0-event=CPU_CLK_UNHALTED)
Legen Sie fest, dass OProfile jedes 6000ste mal Samples nimmt, wenn das spezifizierte Event erfolgt (--ctr0-count=6000)
Als nächstes überprüfen Sie, dass das oprofile-Kernelmodul mittels dem Befehl lsmod geladen ist:
Module Size Used by Not tainted oprofile 75616 1 … |
Gehen Sie sicher, dass das OProfile Dateisystem (befindlich in /dev/oprofile/) mit dem Befehl ls /dev/oprofile/ gemountet wird:
0 buffer buffer_watershed cpu_type enable stats 1 buffer_size cpu_buffer_size dump kernel_only |
(Die genaue Anzahl von Dateien variiert mit dem Prozessortyp.)
An dieser Stelle beinhaltet die /root/.oprofile/daemonrc-Datei die Einstellungen, die für die Datenerfassungs-Software erforderlich sind:
CTR_EVENT[0]=CPU_CLK_UNHALTED CTR_COUNT[0]=6000 CTR_KERNEL[0]=1 CTR_USER[0]=1 CTR_UM[0]=0 CTR_EVENT_VAL[0]=121 CTR_EVENT[1]= CTR_COUNT[1]= CTR_KERNEL[1]=1 CTR_USER[1]=1 CTR_UM[1]=0 CTR_EVENT_VAL[1]= one_enabled=1 SEPARATE_LIB_SAMPLES=0 SEPARATE_KERNEL_SAMPLES=0 VMLINUX=/boot/vmlinux-2.4.21-1.1931.2.349.2.2.entsmp |
Als nächstes benutzen Sie opcontrol, um die Datenerfassung mittels opcontrol --start-Befehl zu starten:
Using log file /var/lib/oprofile/oprofiled.log Daemon started. Profiler running. |
Gehen Sie sicher, dass der oprofiled-Daemon mittels dem Befehl ps x | grep -i oprofiled läuft:
32019 ? S 0:00 /usr/bin/oprofiled --separate-lib-samples=0 … 32021 pts/0 S 0:00 grep -i oprofiled |
(Die eigentliche durch ps angezeigte oprofiled-Befehlszeile ist viel länger, wurde hier jedoch zu Formatierzwecken abgeschnitten.)
Das System wird nunmehr kontrolliert, wobei die Daten für alle auf dem System befindlichen, ausführbaren Events gesammelt werden. Die Daten werden in dem /var/lib/oprofile/samples/-Verzeichnis gespeichert. Die Dateien in diesem Verzeichnis unterliegen einer eher ungewöhnlichen Namenskonvention. Hier ist ein Beispiel:
}usr}bin}less#0 |
Die Namenskonvention benutzt den absoluten Pfad jeder einzelnen Datei, die ausführbaren Code enthält, wobei die Schrägstriche (/) durch rechte geschweifte Klammern (}) ersetzt werden und mit einem Rautenzeichen (#) enden, gefolgt von einer Nummer (in diesem Fall 0.) Deshalb verkörpert die in diesem Beispiel verwendete Datei diejenigen Daten, welche während /usr/bin/less gesammelt worden sind.
Sobald Daten gesammelt worden sind, benutzen Sie eines der Analysetools, um diese anzuzeigen. Ein gutes Leistungsmerkmal von OProfile ist der Umstand, dass es nicht notwendig ist die Datenerfassung zu stoppen, bevor man eine Datenanalyse durchführt. Jedoch müssen Sie zuwarten, bis zumindest ein Satz von Samples auf die Platte geschrieben wird oder Sie zwingen diese Samples mittels opcontrol --dump auf die Platte.
Im folgendem Beispiel wird der Befehl op_time dazu benutzt, um die erfassten Daten (in umgekehrter Reihenfolge —beginnend mit der höchsten Anzahl von Samples, danach absteigend) anzuzeigen:
3321080 48.8021 0.0000 /boot/vmlinux-2.4.21-1.1931.2.349.2.2.entsmp 761776 11.1940 0.0000 /usr/bin/oprofiled 368933 5.4213 0.0000 /lib/tls/libc-2.3.2.so 293570 4.3139 0.0000 /usr/lib/libgobject-2.0.so.0.200.2 205231 3.0158 0.0000 /usr/lib/libgdk-x11-2.0.so.0.200.2 167575 2.4625 0.0000 /usr/lib/libglib-2.0.so.0.200.2 123095 1.8088 0.0000 /lib/libcrypto.so.0.9.7a 105677 1.5529 0.0000 /usr/X11R6/bin/XFree86 … |
Es ist sicherlich eine gute Idee less zu benutzen, wenn ein Report interaktiv erzeugt wird, da dieser Hunderte von Zeilen lang sein kann. Das hier gezeigte Beispiel ist aus diesem Grund abgeschnitten worden.
Das Format für diesen speziellen Report setzt sich aus jeweils einer Zeile für jede einzelne ausführbare Datei zusammen, für die Samples erzeugt wurden. Jede Zeile entspricht dem selben Format:
<sample-count> <sample-percent> <unused-field> <executable-name> |
Wo:
<sample-count> steht für die Anzahl von erfassten Abfragen.
<sample-percent> steht für den Prozentsatz aller Abfragen, welche für diese spezifische, ausführbare Datei gesammelt worden sind
<unused-field> steht für ein unbenutztes Feld
<executable-name> steht für den Namen der Datei, die ausführbaren Code besitzt und wofür Anfragen getätigt worden sind.
Dieser Report (auf einem zumeist im Leerlauf befindlichen System) zeigt, dass beinahe die Hälfte aller Samples genommen wurden, während die CPU Kernel-Code ausführt. Als nächstes finden Sie den OProfile Datenerfassungs-Daemon, gefolgt von einer Vielzahl von Dokumentationen und dem X Window System Server, XFree86. Bitte beachten Sie, dass für das hierbei verwendete System ein Counter-Wert von 6000 verwendet wurde, was gleichzeitig der von opcontrol --list-events empfohlene Minimumwert ist. Dies bedeutet, dass — zumindest für dieses spezielle System — OProfile-Overhead zu keinem Zeitpunkt mehr als rund 11% der CPU-Leistung verbraucht.