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:
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:
watch free
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:
watch -n 1 -d free
Weitere Informationen finden Sie auf der watch man-Seite.
Der watch-Befehl wird solange ausgef�hrt, bis dieser mit [Strg]-[C] unterbrochen wird. Der watch-Befehl kann in vielen Situationen n�tzlich sein und sollte daher im Ged�chtnis behalten werden.
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:
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 [i]. Um zur Standardanzeige zur�ckzukehren, dr�cken Sie diese Taste nocheinmal.
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 [?] f�r die Anzeige) ist es am sichersten, nur [q] einzugeben (wodurch Sie top verlassen).
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 MonitorProzessliste finden Sie unter Abbildung 2-1.
Abbildung 2-1. Anzeige der GNOME System MonitorProzessliste
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:
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:
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 bringtcronsa1 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:
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:
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:
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:
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> 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.
Major-Nummern von Ger�ten k�nnen mittels ls -lgefunden werden, um die gew�nschte Ger�te-Datei in /dev/ anzuzeigen. Die Major-Nummer erscheint nach der Gruppenspezifikation des Ger�tes.
OProfile kann ebenso einen Fallback-Mechanismus (als TIMER_INT bekannt) benutzen, falls in Systemarchitekturen Performance-Monitoring-Hardware nicht vorhanden ist.
