Steffen über Cloud, Azure und Datenbanken

Steffen Krause - Cloud Solution Architect

"Was tut der eigentlich die ganze Zeit?" - eine kurze Einführung in die Performanceanalyse in Windows Vista/Server 2008

"Was tut der eigentlich die ganze Zeit?" - eine kurze Einführung in die Performanceanalyse in Windows Vista/Server 2008

  • Comments 1
  • Likes

Es gibt viele Gründe herausfinden zu wollen , was ein Computer eigentlich die ganze Zeit tut. Zu langsam, zu viel Plattenaktivität, zu geringe Laufzeit auf Akku sind nur einige davon. Der Windows Taskmanager und der zugehörige Rssourcenmonitor sind für eine längerfristige Analyse nicht aussagekräftig genug. Der Process Explorer ist schon umfangreicher, aber für die Überwachung über einen längeren Zeitraum auch nicht unbedingt geeignet.

Dann war da noch Event Tracing for Windows (ETW). Das ist das interne Tracing von allen möglichen Ereignissen in Windows Vista und Server 2008. Sehr leistungsfähig, aber ziemlich kryptisch zu bedienen. Man braucht also gute Tools, um aus den Möglichkeiten von ETW etwas halbwegs einfach bedienbares zu machen. Und diese Tools findet man im Windows Performance Toolkit. Dieses Toolkit ist eigentlich für Hardwarehersteller gedacht, um (unter anderem) zum einen eine Performanceanalyse bei der Gerätetreiberentwicklung zu ermöglichen und zum anderen vorgefertigte Betriebssystemimages (mit den installierten Treibern all der mitgelieferten Software) auf ihr Performanceverhalten zu testen. Jeder, der schon mal einen vorkonfigurierten Rechner eines Hardwareherstellers gekauft hat kennt wohl das Problem, dass der Rechner sich allein aufgrund der mitgelieferten Software langsam anfühlt. Und die Deinstallation dieser Software oder gar die komplette Neuinstallation eines jungfräulichen Windows Vista den Rechner schnell machen kann.

Dieses Performance Toolkit kann aber nun jeder experimentierfreudige Windows Vista und Windows Server 2008 Benutzer (und mit Einschränkungen auch XP SP2 und Windows Server 2003) nutzen, um seinen eigenen Rechner oder die selbst gebauten FirmenPC-Images auf geringe Prozessor- und IO-Last zu testen und sehr detaillierte Angaben zu bekommen, was der Rechner denn nun eigentlich macht und wieviel Last er tatsächlich hat.

Normalerweise sollte man dabei die Untersuchungen auf zwei Punkte konzentrieren:

1. Last bei ruhendem Desktop. Das heißt: Rechner starten, einloggen, warten, Trace starten, warten, warten, warten, Trace stoppen, analysieren. Bei Laptops ggf. getrennt nach "Am Netz" und "Auf Akku". Dazu benötigt man aus dem Performance Toolkit die Tools xperf und xperfview

Die Last beim ruhenden Desktop ist deswegen wichtig, weil jede andere Auslastung des Rechners nur noch dazukommen kann. Unter diese Last kann man also nicht kommen. Auch aus Power Management Gesichtspunkten ist das wichtig: Hohe Ruhelast führt dazu, dass der Prozessor nicht oder nicht ausreichend heruntertakten kann und so unnötig Strom verbraucht und insbesondere die Laufzeit auf Akku reduziert

2. Verhalten bei Boot/Standby/Ruhezustand. Dazu in einem späteren Artikel mehr

Wie werden diese Tools nun bedient? Fangen wir mit der Lastanalyse an.

Zuerst (optional) sollte man für weitergehende Analysen den Pfad zu den Windows Debugsymbolen setzen. Das ermöglicht es später, tief in die Aufrufstacks der Programme hineinzuschauen. Dazu legt man einfach in c:\ ein Verzeichnis "Symbols" an und setzt dann eine Umgebungsvariable (unter Computereigenschaften-> Erweiterte Systemeinstellungen->Umgebungsvariablen->Systemvariablen

Name der Umgebungsvariable: _NT_SYMBOL_PATH

Wert:  srv*c:\Symbols*http://msdl.microsoft.com/download/symbols

Das weist jedes Programm, das Debugsymbole nutzen will an, sich die Windows-eigenen Debuginformationen vom Microsoft Symbolserver zu holen und sie in c:\Symbols zu cachen.

Als nächstes können wir dann einen Trace starten. Es gibt User Mode Traces (z.B. für Performance Counter) und Kernel Mode Traces. Für die Ruhezustandsanalyse brauchen wir erst mal nur einen Kernel Trace. Die Traces werden mit Hilfe von Providern im Kernel gesammelt und in eine Datei geschrieben. Die Liste der Kernel-Provider kann man sich von einer administrativen Kommandozeile (cmd "Als Administrator ausführen") mit

xperf -Providers K

anzeigen lassen. Für erste Untersuchungen bietet die Gruppe Base einen guten Anfang.

Ein Trace wird dann einfach mit

xperf -on Base

gestartet und die Daten in eine Datei gespeichert - standardmäßig in c:\, sonst den Pfad auf der Kommandozeile mit dem Parameter -f angeben.

Jetzt lässt man den Rechner ohne weitere laufende Programme in Ruhe, so circa ne halbe Stunde.

Dann stoppt man den Trace und schreibt das Ergebnis in eine .etl-Datei:

xperf -d c:\temp\ErstesErgebnis.etl

Das dauert eine Weile. Man darf übrigens auf keinen Fall vergessen, Traces auch wieder zu stoppen, sonst läuft die Platte mit den Tracefiles voll. Und auch den  originalen Trace in c:\sollte man löschen, wenn man ihn nicht mehr benötigt.

Das Ergebnis kann man sich dann mit xperfview (Eintrag "Performance Analyzer" in der Programmgruppe "Microsoft Windows Performance Toolkit") anschauen.

Als erstes lädt man den Trace mit Trace->Open. Links kann man ein Menü für die Graph-Auswahl einblenden. Ich habe mal während ich all dies hier schrieb einen Trace mitlaufen lassen (dies ist also KEIN Ruhe-Trace):

image

Die Graphen sind ja ganz nett, aber die eigentlichen Informationen liegen dahinter verborgen. Dazu selektiert man im Graph einen Bereich oder auch alles und wählt dann "Simple Summary Table" oder auch "Summary Table" Jetzt bekommt man eine Liste, welche Programme in welche Modulen wie viel CPU verbraucht haben. Das kann bei Auswahl großer Zeiträume auch schon mal einige Minuten dauern, insbesondere wenn man "Load Symbols" ausgewählt hat und die Symbole erst aus dem Internet geladen werden müssen.

image

Wie man hier schön sehen kann hat mein Rechner (der R500 hat nur eine 1,2 GHz Dual Core CPU) im Durchschnitt 17% Prozessorlast gehabt und davon die meiste Zeit an den Live Writer, mit dem ich diesen Text schreibe. Aber auch ein Dienst-Host (Prozess 1388), der Office Communicator und der WMI Provider haben gut CPU verbraucht. Wenn man hier feststellt, dass ein nicht benötigtes Hintergrundprogramm viel (>0,2%) CPU verbraucht kann man es gut deaktivieren. Um herauszufinden, welches Programm zu welchem Prozess gehört eignet sich übrigens der Process Explorer ganz hervorragend. Dazu lässt man sich einfach die Eigenschaften (Rechtsklick->Properties) eines Prozesses anzeigen und erfährt den Pfad zur Datei. Und mit Autoruns kann man Hintergrundprogramme dann deaktiveren

Ähnlich detailliert kann man die Festplattenaktivität untersuchen. Hier sieht man zum Beispiel, dass der Communicator vor allem auf die Outlook Offlinestore-Datei zugreift:

image

Insbesondere aber ist es wieder der Dienst-Host 1388, der viel viel IO produziert, und zwar insbesondere im Windows Update Store:

image

Ich glaube, ich werde den mal defragmentieren Das geht so: Windows Update Dienst stoppen, dann

esentutl /d %windir%\SoftwareDistribution\Datastore\datastore.edb

von einer administrative Kommandozeile ausführen und Windows Update Dienst wieder starten.

Das soll als erster Überblick mal reichen. In nächster Zeit werde ich dem Thema Boot/Standbyanalyse mal einen kurzen Artikel widmen.

Viele weitergehende Informationen gibt es hier:

Gruß,
Steffen

Comments
  • Hallo Steffen,

    xperf läßt sich (bei mir) unter XP SP2 gar nicht installieren. Es bricht mit einem entsprechenden Hinweis auf Vista bzw 2008 Server ab.

    Gruß Joachim

    Antwort: Das ist richtig. Daher habe ich diesen Artikel verlinkt.

    Gruß,
    Steffen

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment