Performanceanalyse

18.03.2007 von Martin Kuppinger

Die Messung und Optimierung der Performance ist eines der interessantesten Felder der Systemadministration. Das gängige Werkzeug für die Analyse der Performance von Windows- Systemen ist die Anwendung Leistung, die sich in der Gruppe Verwaltung findet. Für Entwickler stehen zusätzliche Trace-Funktionen zur vertieften Performanceanalyse zur Verfügung.

Mit dem Tool Leistung – früher als Systemmonitor bezeichnet – können viele Analysen durch geführt werden. Der Schwerpunkt des ersten Teils der Artikelserie liegt auf der Nutzung des Tools, nicht auf der Optimierung von Systemen für einzelne Aufgaben.

Die laufende Überwachung

Für einen schnellen Überblick über die Performance und die spätere Analyse von Protokollen ist der Systemmonitor als Teil der Anwendung Leistung die richtige Lösung (Bild 1). Er zeigt den aktuellen Status verschiedener Leistungsindikatoren sowie die Durchschnitts-, Minimal- und Maximalwerte an. Außerdem wird über die Dauer der Leistungsüberwachung informiert.

Bild 1: Die Anwendung Leistung ist das wichtigste Werkzeug für die Performanceanalyse.

Nach dem Start werden drei Leistungsindikatoren angezeigt:

Seiten/s gibt an, wie viele Seiten pro Sekunde in den Speicher geschrieben beziehungsweise gelesen werden. Es wird also darüber informiert, wie oft Daten zwischen dem Datenträger und dem Hauptspeicher transportiert werden müssen. Der Wert ist ein wichtiger Indikator dafür, ob ausreichend Speicher im System vorhanden ist und wie effizient dieser genutzt wird. Grundsätzlich gilt, dass hohe Werte für Seiten/s auf ein Problem im System verweisen, soweit sie über einen längeren Zeitraum auftreten. Kurzzeitige Spitzen sind dagegen völlig normal, weil sie beispielsweise beim Laden von Anwendungen erzeugt werden.

Durchschnittliche Warteschlangelänge des Datenträgers informiert darüber, wie lang die Warteschlange des Prozessors ist und wie viele Anforderungen für den Datenträger ausstehen. Dieser Wert ist ein guter Indikator für die Performance der Datenträger, weil eine lange Warteschlange darauf hindeutet, dass das System mit der Verarbeitung von Anforderungen nicht nachkommt.

Prozessorzeit (%) gibt an, in welchem Umfang die verfügbare Prozessorleistung genutzt wird. Dieser Parameter weist ebenfalls kurzfristige Spitzen auf, sollte im Durchschnitt aber nicht allzu hoch sein.

Für einen ersten Überblick reichen diese Leistungsindikatoren aus, weil man die gravierendsten Engpässe im System damit schnell erkennen kann. Für eine nähere Analyse muss man aber gegebenenfalls noch auf weitere Leistungsindikatoren zugreifen, die über den Befehl Leistungsindikatoren hinzufügen im Kontextmenü aufgenommen werden können. Im angezeigten Dialogfeld (Bild 2) lassen sich vier Parameter einstellen:

Bild 2: Das Dialogfeld für die Auswahl von Leistungsindikatoren.

Im oberen Bereich kann ausgewählt werden, von welchem System die Leistungsindikatoren überwacht werden sollen. Da die Anwendung selbst auch etwas Prozessorzeit benötigt, könnte eine Überwachung über das Netzwerk Sinn machen. In diesem Fall wird aber an anderer Stelle Last erzeugt, so dass man normalerweise lokal arbeitet. Bei längeren Überwachungsvorgängen wird man ohnehin Protokolle verwenden.

Anschließend kann das Objekt gewählt werden. Die Liste der Leistungsobjekte ist unterschiedlich lang, je nachdem, welche Anwendungen installiert sind. So werden beispielsweise für den Microsoft SQL Server sehr viele zusätzliche Leistungsobjekte eingerichtet. Bei Servern mit vielen Anwendungen wird die Liste allerdings schnell etwas unübersichtlich.

Der nächste Schritt ist die Auswahl des Leistungsindikators. Es können zwar auch alle Indikatoren überwacht werden, das ist aber in der Regel wenig sinnvoll und macht die Überwachung nur unübersichtlich.

Schließlich können die Instanzen gewählt werden. Beim Prozessor sind das die Prozessoren, bei Threads die einzelnen Threads, beim physikalischen Datenträger die Festplatten und so weiter. Außerdem lassen sich in der Regel Gesamtwerte ermitteln.

In Bild 2 wird die Erklärung mit angezeigt. Da man unmöglich alle Leistungsindikatoren genau kennen kann, ist das auf jeden Fall empfehlenswert. Darüber hinaus ist es auch möglich, die Eigenschaften zu bearbeiten (Bild 3), und zwar auf insgesamt fünf Registern:

Bild 3: Die Eigenschaften des Systemmonitors.

Im Register Allgemein finden sich Festlegungen wie die Form der Darstellung und die anzuzeigenden Elemente. Der wichtigste Parameter ist das Intervall für die Erfassung der Systemindikatoren. Das Standardintervall ist eine Sekunde. Dadurch werden nur die Werte der vergangenen 100 Sekunden angezeigt. Es bietet sich daher an, das Intervall zu verlängern, um einen sinnvollen Zeitraum zu überblicken. Bei einem Intervall von 15 Sekunden werden beispielsweise die Werte der vergangenen 25 Minuten angezeigt, was schon deutlich sinnvollere Analysen ermöglicht.

Bei Quelle kann auf Protokolldateien, Datenbanken oder die aktuelle Aktivität zurückgegriffen werden. Hier ist also auch die Analyse von längeren Aufzeichnungen zur Performance möglich.

Auch im Bereich Daten können die Leistungsindikatoren konfiguriert werden. Für die Einrichtung einer größeren Zahl an Indikatoren ist das etwas effizienter als die Nutzung des oben beschriebenen Kontextmenüs.

Im Register Grafik geht es um die Anzeige. Beispielsweise lassen sich Gitternetzlinien einrichten.

Bei Darstellung werden Farben und Schriftarten definiert.

Solange nur mit der aktuellen Überwachung gearbeitet wird, ist die Nutzung der Anwendung Leistung relativ einfach. Die eigentliche Herausforderung liegt allerdings ohnehin in der richtigen Wahl der Leistungsindikatoren und ihrer Interpretation.

Leistungsprotokolle

Die Ad-hoc-Überwachung in der beschriebenen Form ist allerdings für eine gründliche Analyse oft nicht geeignet. Während man aktuelle Performance-Probleme gut nachvollziehen kann, muss man bei Servern häufig über einen längeren Zeitraum analysieren, wie sich die Performance beispielsweise in bestimmten Nutzungssituationen entwickelt. Dafür sind die Leistungsindikatorenprotokolle ein probates Mittel. Sie zeichnen die Werte in einer Datei auf. Die Aufzeichnungen können zu einem späteren Zeitpunkt wieder geladen und verarbeitet werden.

Ein vordefiniertes Protokoll mit den eingangs beschriebenen drei Leistungsindikatoren steht zur Verfügung, weitere Protokolle können über das Kontextmenü einfach erstellt werden.

Im Register Allgemein (Bild 4) müssen die Leistungsindikatoren ausgewählt werden. Dazu wählt man sowohl Objekte als auch einzelne Indikatoren aus. Bei früheren Windows-Versionen konnten nur die Objekte gewählt werden, so dass alle Indikatoren eines Objekts protokolliert wurden. Das hat dazu geführt, dass die Protokolldateien unnötig groß wurden. Daher empfiehlt sich die Auswahl einzelner Leistungsindikatoren, die für die Analyse tatsächlich benötigt werden.

Bild 4: Längerfristige Analysen können mit Leistungsindikatorenprotokollen durchgeführt werden

Darunter lässt sich noch das Intervall für die Aufzeichnung der Werte festlegen. Der Standardwert von 15 Sekunden ist für eine detaillierte Analyse ausreichend. Längere Intervalle im Bereich von 1 bis 2 Minuten sind durchaus auch noch akzeptabel, wobei mit der Länge des Intervalls das Risiko wächst, dass Lastspitzen nicht korrekt erkannt werden.

Der nächste Schritt ist die Festlegung der Protokolldatei. Hier gibt es mehrere Optionen. Textdateien empfehlen sich nur bei einer Überwachung über einen kürzeren Zeitraum. Die binären Dateien können nur mit der Anwendung Leistung oder Anwendungen, die die dort definierten APIs nutzen, analysiert werden. Interessant ist die neue Option der Speicherung von Protokolldaten in einer Datenbank. Das ist vor allem bei der Speicherung sehr großer Datenmengen empfehlenswert. Diese Informationen lassen sich wie die Protokolle in Textform relativ einfach auch mit anderen Werkzeugen analysieren.

In einem Zeitplan (Bild 5) wird ein Startzeitpunkt und das Ende der Protokollierung festgelegt. Es bietet sich an, Überwachungen beispielsweise für besonders lastintensive Zeiten oder während der turnusmäßigen Ausführung von Batches oder Systemdiensten durchzuführen, um die spezifischen Auswirkungen dieser Situationen zu erkennen. Die Kunst liegt darin, mit möglichst wenigen Aufzeichnungen die erforderlichen Informationen zu gewinnen, mit denen etwaige Engpässe im System gezielt identifiziert werden können.

Bild 5: Die Leistungsüberwa chung kann zeitlich gesteuert werden

Wenn mit einer CSV-Datei gearbeitet wird, ist die Analyse nicht nur über die Anwendung Leistung, sondern beispielsweise auch mit Excel möglich. Bei einer CSV-Datei sollte allerdings zunächst die Dateiendung beispielsweise in .txt geändert werden, bevor sie mit Excel geöffnet wird. Als CSV-Datei wird jeder Eintrag einer Excel-Zelle zugeordnet. Bei einem anderen Dateityp, der von Excel nicht direkt unterstützt wird, wird dagegen ein Assistent gestartet, mit dem die Umsetzung der Daten und die Zuordnung zu Spalten in der Excel-Tabelle erfolgen kann.

Die Struktur der Daten ist sehr einfach (Bild 6). Für jeden Zeitpunkt, an dem im definierten Intervall Daten gesammelt werden, werden für alle Leistungsindikatoren die aktuellen Werte aufgezeichnet. Diese Daten können nun in Excel weiter analysiert oder in Grafiken umgesetzt werden

Bild 6: Die Daten aus einem Protokoll in Excel.

Ablaufverfolgung

Neben den Leistungsindikatorenprotokollen, die einfach zu verstehen sind, gibt es noch eine zweite Gruppe: die Protokolle der Ablaufverfolgung. Diese Protokolle zeichnen beim Auftreten bestimmter Aktivitäten detaillierte Informationen über Abläufe im Betriebssystem auf. Im Gegensatz zu den Leistungsindikatoren wird hier also nicht mit Intervallen, sondern ereignisgesteuert gearbeitet. Die Ergebnisse können allerdings nicht direkt mit der Anwendung Leistung betrachtet werden. Sie müssen zunächst mit dem Tool tracerpt.exe umgewandelt werden. Alternativ dazu können Sie auch von Entwicklern über definierte APIs verarbeitet werden.

Ein Protokoll der Ablaufverfolgung kann im entsprechenden Bereich der Anwendung Leistung erstellt werden. Im Register Allgemein muss der Anbieter definiert werden, dessen Ereignisse verarbeitet werden sollen (Bild 7). Als Anbieter-Gruppen gibt es sowohl die vorkonfigurierten Systemanbieter als auch andere Anbieter. Ein Anbieter ist ein Dienst, der mit der Performance-Überwachung so integriert ist, dass er Ereignisse generieren kann, die einen Eintrag in der Ablaufverfolgung erzeugen. Beim Systemanbieter kann zunächst der Anbieterstatus geprüft werden. Hier wird angezeigt, welche Anbieter es gibt und welche davon aktiviert sind. Die meisten Anbieter sind standardmäßig nicht aktiviert.

Bild 7: Die Auswahl des Anbieters für das Protokoll der Ablaufverfolgung.

Bei den Systemanbietern können Sie steuern, welche Ereignisse protokolliert werden sollen. Wenn Sie einen Kernel-Trace aktivieren, also mit dem aktivierten Systemanbieter Kernel arbeiten und die Ereignisse auf dieser Ebene detailliert ermitteln, werden sehr große Protokolle erzeugt. Das macht allenfalls für Systementwickler Sinn. Die Standardoption ist daher auch die Auswahl eines Nicht-Systemanbieters, den Sie über die Schaltfläche Hinzufügen auswählen. Sie können hier beispielsweise auf verschiedene Active Directory-Ereignisse reagieren. Für Nicht-Systemanbieter lässt sich keine Auswahl der Ereignisse vornehmen, da die protokollierten Ereignisse durch den gewählten Systemanbieter fest vorgegeben sind. Bei verschiedenen Ereignissen müssen Sie bei Ausführen als ein administratives Konto angeben, damit die Ablaufverfolgung durchgeführt werden kann. Falls sich das Protokoll nicht starten lässt, sollten Sie als Erstes überprüfen, ob das Problem eventuell bei nicht ausreichenden Berechtigungen liegt.

Anschließend können Sie im Register Protokolldateien zwischen den Dateitypen sequentielle Datei und zirkuläre Datei unterscheiden. Letztere hat eine feste Länge. Wenn sie voll ist, werden die ältesten Einträge überschrieben.

Neben dem Zeitplan enthält das Register Erweitert noch Puffereinstellungen. Das ist vor allem bei Protokollen, die auf einer Vielzahl von Ereignissen basieren, wichtig. In diesem Fall werden die Daten nicht permanent in die Protokolldatei geschrieben, sondern immer nur in Blöcken von standardmäßig 4 KByte. Es bietet sich an, diesen Wert zu erhöhen, wenn sehr viele Informationen in die Protokolldatei geschrieben werden müssen. Sie können auch ein Intervall konfigurieren, nach dem in jedem Fall eine Übertragung der Protokollinformationen in die Datei erfolgt.

Nach dem Sammeln der Daten kann die Umsetzung der binären Protokolldatei in eine lesbare Datei erfolgen. Dazu wird der bereits erwähnte Befehl tracerpt.exe verwendet:

C:\perflogs>tracerpt test_000002.etl -o protokoll.txt Eingabe ---------------- Datei(en): Test_000002.etl 100.00% Ausgabe ---------------- Text (CSV): protokoll.txt Der Befehl wurde erfolgreich ausgeführt.

Die Datei kann nun mit Excel oder anderen Anwendungen verarbeitet werden. Statt einer CSVDatei lassen sich auch andere Dateiformate wie XML- oder HTML-Dateien erzeugen.

Einen Ausschnitt aus einer Datei, die bei der Beobachtung von Kerberos-Ereignissen erzeugt wird, zeigt Listing 1.

Listing 1: Ein Ausschnitt aus einer Datei zur Ablaufverfolgung Event Name, Type, TID, Clock-Time, Kernel(ms), User(ms), User Data EventTrace, Header, 0x00000B94, 127915049643750000, 30, 0, 4096, 33620485, 3790, 1, 127915345535625000, 156250, 0, 0x00000001, 5, 1, 4, 0, 2993, 0x006D4AC8, 0x006D4AD2, 0, 3579545, 127915049643750000, 0x00000002, 0, 0, 0 TGSRequest, Start, 0x00000E78, 127915055878281250, 0, 0, 0x40830000, 0, 0 TGSRequest, End, 0x00000E78, 127915055878281250, 0, 0, 0x0000000D, "", "host/adfsidpad.adfs.intra", "ADFS.INTRA", 0, 0 TGSRequest, Start, 0x0000061C, 127915064881718750, 15, 0, 0x40830000, 0, 0 TGSRequest, End, 0x0000061C, 127915064881875000, 15, 0, 0x0000000D, "", "host/adfsidpad.adfs.intra", "ADFS.INTRA", 0, 0 TGSRequest, Start, 0x0000065C, 127915068946562500, 1995, 360, 0x40830000, 0, 0 TGSRequest, End, 0x0000065C, 127915068946718750, 1995, 360, 0x0000000D, "", "host/adfsip.adfs.intra", "ADFS.INTRA", 0, 0 TGSRequest, Start, 0x00000EA4, 127915073885000000, 0, 0, 0x40830000, 0, 0 TGSRequest, End, 0x00000EA4, 127915073885000000, 0, 0, 0x0000000D, "", "host/adfsidpad.adfs.intra", "ADFS.INTRA", 0, 0 TGSRequest, Start, 0x00000EA4, 127915082890312500, 0, 0, 0x40830000, 0, 0 TGSRequest, End, 0x00000EA4, 127915082890312500, 0, 0, 0x0000000D, "", "host/adfsidpad.adfs.intra", "ADFS.INTRA", 0, 0 TGSRequest, Start, 0x000005C0, 127915091895312500, 0, 0, 0x40830000, 0, 0 TGSRequest, End, 0x000005C0, 127915091895312500, 0, 0, 0x0000000D, "", "host/adfsidpad.adfs.intra", "ADFS.INTRA", 0, 0

In diesem Fall werden neben den Ereignissen und Informationen zum auslösenden Thread noch Informationen über die für die Bearbeitung des Ereignisses benötigte Prozessorzeit im Kernelund Benutzermodus ermittelt.

Protokolle zur Ablaufverfolgung sind einerseits interessant, um erkennen zu können, wie hoch die von definierten Systemereignissen erzeugte Last ist. Sie sind aber auch für Anwendungsentwickler von Bedeutung, um selbst Anbieter zu schreiben und damit detaillierter analysieren zu können, wie sich bestimmte Funktionen der Anwendung auf die Performance des Systems auswirken.

Warnungen

Während die Protokolle zur Ablaufverfolgung doch ein eher komplexes Thema sind, lassen sich die Warnungen in der Anwendung Leistung wieder deutlich einfacher nutzen. In diesem Fall geht es darum, beim Über- oder Unterschreiten bestimmter Werte automatisiert Aktionen auszulösen.

In einer Warnung werden daher zunächst Leistungsindikatoren mit Schwellwerten konfiguriert. Dabei ist darauf zu achten, dass sinnvolle Werte definiert werden. So kann die Prozessorleistung durchaus kurzfristig auf 100% steigen. Ebenso kann der Wert für Seiten/s in den Spitzen sehr hoch sein, wenn beispielsweise eine neue Anwendung gestartet wird. Es sollte also mit Leistungsindikatoren gearbeitet werden, die sich eher kontinuierlich entwickeln und mit denen nicht unnötig Warnungen generiert werden. Beispiele sind die Zusagegrenze oder die verfügbaren MBytes beim Hauptspeicher.

Nach der Festlegung der Schwellwerte ist im Register Aktion anzugeben, was passieren soll. Der einfachste Ansatz ist die Erstellung eines Eintrags im Ereignisprotokoll. Es können auch die allerdings unzuverlässigen – Meldungen über das Netzwerk an die Administratoren gesandt werden. Interessant ist die Option, ein Leistungsdatenprotokoll zu starten, um den weiteren Verlauf der Systemnutzung detailliert zu protokollieren und damit erkennen zu können, ob es sich nur um ein kurzzeitiges oder ein dauerhaftes Problem gehandelt hat, und auch schon den Ursachen für dieses Problem auf den Grund gehen zu können. Das Leistungsdatenprotokoll muss vor der Erstellung der Warnung erzeugt werden und sollte sowohl die Leistungsindikatoren aufzeichnen, die die Warnung ausgelöst haben, als auch alle anderen Leistungsindikatoren, die für eine spätere Analyse der Problemsituation erforderlich sein könnten. Eine weitere mögliche Aktion ist die Ausführung eines Programms, etwa eines Skripts, das Systemparameter anpasst oder andere Aktivitäten wie den Neustart von Diensten durchführt.

Bild 8: Die Konfiguration von Warnungen

Auch für Warnungen kann ein Zeitplan konfiguriert werden. Wenn man beispielsweise nur vermutete Performance-Probleme durch nächtliche Batch-Jobs analysieren möchte, aber keine Warnungen im Regel-Betrieb erzeugen möchte, eignet sich dieser Zeitplan sehr gut. Die Funktionen für die Verarbeitung von Warnungen in der Anwendung Leistung ist relativ primitiv realisiert. Tools wie der Microsoft Operations Manager stellen eine deutlich leistungsfähigere Funktionalität für die Verarbeitung von Überschreitungen definierter Schwellwerte bereit. Andererseits lassen sich gerade in der Kombination von Warnungen mit zusätzlichen Leistungsdatenprotokollen oder Skripts viele Aufgaben lösen.

Der Task-Manager

Neben der Anwendung Leistung bietet der Task-Manager noch ein zweites Werkzeug für den schnellen Überblick über die Auslastung des Systems (Bild 9). Es zeigt Informationen zu den laufenden Prozessen, der Systemleistung und der Netzlast an. Für jeden Prozess werden die aktuell verursachte Prozessorlast und die Speichernutzung angegeben.

Bild 9: Der Task- Manager ist vor allem für Basisanalysen der Systemleistung ein hilfreiches Werkzeug.

In vielen Fällen reicht dieses Tool bereits aus, um eine erste Analyse durchzuführen, ohne dass man die Anwendung Leistung nutzt. Das gilt vor allem auch deshalb, weil in der Liste der Prozesse weitere Spalten wie die CPU-Zeit, die bisher konsumiert wurde, aufgenommen werden können. Daher kann der Task-Manager auch genutzt werden, um zunächst die Prozesse, die eine hohe Systemlast verursachen, zu identifizieren und sie dann über einen längeren Zeitraum mit einem Protokoll in der Anwendung Leistung zu beobachten.

Wie geht es weiter?

Im zweiten Teil der Serie werden ergänzende Tools für die Performanceanalyse aus dem Resource Kit und bei den Support Tools vorgestellt, die in Verbindung mit der Anwendung Leistung oder ergänzend dazu genutzt werden können. Frei verfügbare Werkzeuge für das Benchmarking und ihre Nutzung mit dem Windows Server 2003 lernen Sie im dritten Teil der Serie kennen.