Procdump bekommt CPUs in den Griff
30. November 2009Wenn eine zu hohe CPU-Auslastung Probleme verursacht, gibt es für den Administrator eine ganze Reihe von Werkzeugen, die ihm helfen, Lösungen zu finden. Zu dieser Reihe von Tools gesellt sich nun das Werkzeug Procdump (procdump.exe). Wie viele andere von Systemverwaltern geliebte Tools stammt auch diese Entwicklung von den Software-Ingenieuren rund um Mark Russinovich, die früher in der Firma Sysinternals vereint waren und nun bei Microsoft direkt angestellt sind.
Eine hohe oder gar viel zu hohe CPU-Auslastung gehört zu den häufigsten Problemen der Anwender – davon können die Supportteams ein Lied singen. Diese Art von Problemen gehört ganz sicher zu den großen Herausforderungen in ihrer täglichen Praxis. Generell muss der Administrator zunächst feststellen, welcher Prozess oder welche Systemaktivität dafür verantwortlich, dass der Prozessor derart belastet ist.
Anschließend gilt es, den besten Weg zu finden, um die Aktivitäten dieses einen Prozesses genau zu dem Zeitpunkt aufzuzeichnen, zu dem er die entsprechenden Probleme verursacht. Nur so hat der IT-Fachmann dann die Chance, die Vorgänge auf dem System richtig zu analysieren.
Glücklicherweise existieren einige Werkzeuge, die bei Problemen mit hoher CPU-Auslastung wertvolle Informationen liefern können. Neben den traditionell bekannten Software-Werkzeuge gibt es das freie Werkzeug: Procdump. Es spart dem Administrator viel Zeit und Mühe, wenn seine Anwender wieder mal über viel zu hohe Auslastung des Prozessors klagen.
Die CPU ist ausgelastet – und diese Werkzeuge helfen
Die folgenden Werkzeuge werden sicher schon von den meisten Systembetreuern und Supportmitarbeitern in der einen oder anderen Weise eingesetzt, so dass sie hier nur in einem Überblick vorgestellt werden:
Adplus.vbs: Dieses VBScript-Werkzeug wird zusammen mit den Debugging-Tools für Windows ausgeliefert. Für Administratoren ist es eine gute Informationsquelle, wenn es darum geht, den Speicherauszug („Dump“) eines Programms während einer zu hohen Auslastung der CPU zu schreiben. Allerdings ist der Einsatz dieses Programms auch mit einem Nachteil verbunden: Der Administrator muss selbst direkt an der Konsole sitzen, um genau zum Zeitpunkt der hohen Auslastung den Speicherauszug des Prozesses zu schreiben.
Xperf: Diese Software eignet sich hervorragend dazu, hohe Auslastungen zu CPU-Spitzenzeiten zu finden. Dabei ist es beim Einsatz dieser Lösung nicht nötig, dass ein Mitarbeiter direkt an der Konsole sitzt. Das Programm Xperf kann zusammen mit weiteren Informationen auf der MSDN-Seite zum Thema Performance-Analyse gefunden werden. Obwohl die Software nicht vollständig unter Windows Server 2003 unterstützt wird, sind die Erfahrungen des Autors beim Einsammeln der Daten eines Stapeldurchlaufs (Stackwalk Data – dies ist ohne Frage der wichtigste Bereich, wenn es darum geht solche CPU-Probleme zu analysieren) insgesamt immer positiv gewesen. Allerdings ist es dazu notwendig, dass der Server entweder mit diesem Hotfix oder einem neuerem Kernel betrieben wird.
Ein Administrator soll beim Einsatz dieser Software allerdings beachten, dass sie Daten über alle Prozesse und Aktivitäten auf dem System einsammelt. Ihm steht somit keine Möglichkeit zur Verfügung festzulegen, dass er beispielsweise einen Stackwalk für ein bestimmtes Programm durchführen könnte. Dieses Verhalten des Programms kann dann dazu führen, dass die Menge der Daten für ein Problem, das vielleicht nur alle 24 Stunden einmal auftaucht, durch die typische Auslastung der entsprechenden Maschine schier unüberschaubar wird.
Process Explorer (procexp.exe): Der Autor empfiehlt aufgrund seiner langjährigen Erfahrung jedem Systemverwalter den Einsatz dieses Programms, das auf den Technet-Seiten in der Version 11.33 zum Download zur Verfügung steht. Durch den Einsatz dieser Software ist es dann auf jeden Fall möglich, einen Blick auf den Thread zu werfen, der diese Spitzenlast auf der CPU verursacht und so zu entscheiden, welche Komponente daran beteiligt. So kann der Systemadministrator zunächst versuchen, diese Komponenten mittels eines Updates auf den aktuellen Stand zu bringen, bevor er den technischen Support rufen muss. Will dann aber tiefer in das Problem einsteigen, so benötigt er dafür eine Software, die einen Speicherauszug (Dump) des Programms genau zu dem Zeitpunkt erstellen kann, zu dem dieses Programm die hohe Last auf der CPU verursacht. Diese Anforderung kann der Process Explorer dann leider nicht erfüllen.
Die Neuvorstellung – Procdump (procdump.exe): Aus dem Umfeld der Sysinternals-Entwickler rund um Mark Russinovich kommt nun eine neue Software mit dem Namen Procdump. Sie kann ebenfalls von der Microsoft-Webseite heruntergeladen werden.
Die Software entstand aus einer direkten Anforderung des Microsoft Global Escalation Services Teams heraus an die Gruppe der Entwickler aus der Sysinternals-Crew: Die Ingenieure aus den Escalation Service hatten nachgefragt, ob es möglich sei, den Process Explorer so zu erweitern, dass ein Anwender mit seiner Hilfe einen Speicherauszug eines Programms, das die CPU stark belastet, schreiben könnte.
Aufgrund dieser Anfrage kamen die Entwickler dann aber zu dem Schluss, dass es in diesem Fall weitaus besser sei, eine neue Software zu entwickeln und Procdump war geboren.
Der Administrator, der dieses Kommandozeilen-Werkzeug einsetzt, kann bei seinem Einsatz festlegen, welchen Anteil an der CPU ein Prozess zustehen soll und wie lange dieser Anteil erfüllt sein soll, bis die Software dann einen Speicherauszug dieses Prozesses schreibt. Das bedeutet für den Systembetreuer, dass er auf keinen Fall vor der Konsole sitzen muss, um die richtigen Kommandos einzugeben, wenn der fragliche Prozess beginnt den Prozessor extrem zu belasten. Zudem kann er so leicht festlegen, bis zu welchem Schwellenwert der Prozess die CPU belasten darf, bevor Procdump einen Speicherauszug von ihm schreibt.
Im folgenden Beispiel gehen wir davon aus, dass der WMI Host-Provider-Prozess (wmiprsv.exe) einen Prozessor auf einem spezifischen System zu 90 Prozent auslastet. Dabei treten diese Belastungsspitzen zu ganz zufälligen und nicht nachzuvollziehenden Zeiten auf, so dass der Administrator sich unbedingt die entsprechenden Speicherauszüge anschauen will. Der folgende Aufruf des Programms kann diese Aufgabe bewältigen:
c:\procdump.exe -c 80 -s 3 -n 3 wmiprsv.exe c:\tmp\procdumps
Mit der „-c“-Option kann der Anwender dabei den Schwellenwert festlegen. Die nächste Option, mit dem Schalter „-s“ teilt dem Programm mit, wie lang ein Programm die CPU mit dem Schwellenwert belegen soll, bevor ein Speicherauszug angelegt wird.
Der letzte Parameter gibt schließlich an, wie viele derartige Auszüge das Programm schreiben soll, bevor es sich beendet: So wird also bei diesem Aufruf immer dann ein „Dump“ des Spooler-Prozesses WMI-Host-Provider geschrieben, wenn dieser 80 Prozent oder mehr der CPU für mindestens 3 Sekunden belegt.
Dabei werden dann drei dieser Dateien mit dem Speicherauszug im Verzeichnis c:\tmp\procdumps angelegt. Bild 1 zeigt das Programm bei einem Testlauf.
Der Namen der geschriebenen Dateien wird dabei vom Programm nach dem Muster „Name des Prozesse-Datum-Zeit“ erstellt. Diese automatisch erstellten Zeitstempel erleichtern deutlich die Arbeit des Systembetreuers, wenn er beispielsweise Speicherauszüge über mehrere Tage sammeln und dann auswerten möchte. Ein weiterer großer Vorteil des Programm „Procdump“ besteht ohne Zweifel darin, dass der Name des Threads, der den größten Anteil der CPU für sich beansprucht, auch mit in die Datei geschrieben wird, die den Speicherauszug enthält.
Öffnet der Administrator dann die Dump-Datei im Debugger, so wird er ein Bild erhalten, das dem in Bild 2 ähnlich sieht: Dort ist dann der Thread zu erkennen, der den größten Anteil an der CPU-Auslastung hatte.
Will er danach herausfinden, um welchen Thread es sich nun wirklich handelt, so muss er dazu nicht raten. Das Programm hat ihm schon die Adresse des Threads verraten, bei der es sich in unserem Beispiel einmal um den Wert „0x1149“ handeln soll.
Im Debugger kann der Anwendern dann über das Tilde-Kommando (~) einen Aufruf der folgenden Art am Bildschirm erhalten:
0:000> ~
0 Id: 1260.e74 Suspend: 0 Teb: 7ffdf000 Unfrozen
1 Id: 1260.6d0 Suspend: 0 Teb: 7ffde000 Unfrozen
2 Id: 1260.1194 Suspend: 0 Teb: 7ffdd000 Unfrozen
3 Id: 1260.11f8 Suspend: 0 Teb: 7ffdc000 Unfrozen
4 Id: 1260.1780 Suspend: 0 Teb: 7ffdb000 Unfrozen
5 Id: 1260.13d4 Suspend: 0 Teb: 7ffda000 Unfrozen
6 Id: 1260.1544 Suspend: 0 Teb: 7ffd9000 Unfrozen
7 Id: 1260.1164 Suspend: 0 Teb: 7ffd7000 Unfrozen
So wird schnell klar, dass der „Übeltäter“ hier der zweite Thread ist, weil dort der Wert „1194“ zu finden ist.
Hier handelt es natürlich nur um Beispielwerte, die der Autor für diesen Artikel extra so angelegt hat. Wie kann der Administrator nun weiter vorgehen?
Er hat nun die Gelegenheit, mittels des folgenden Kommandos direkt am Prompt des Debuggers in den Kontext dieses Threads zu wechseln:
0:000> ~2s
Die folgende etwas ausführlichere Anzeige des Debuggers bringt dann weitere Aufklärung: Sie zeigt, dass der von uns verfolgte Prozess „wmiprvse.exe“ verschiedene Verzeichnisse durchläuft beziehungsweise „abzählt“. Dies geschah mit Hilfe von „EnumDirNT“, während der Test auf der Maschine des Autors ablief. Das trifft zu, da die WMI-Query, die vom Autor für diesen Test aufgerufen wurde, verlangte, dass alle Verzeichnisse auf dem System durchgezählt werden.
eax=013bd900 ebx=00004021 ecx=00000004 edx=00000044 esi=76fb49f4 edi=00100001
eip=76fb5cb4 esp=013bd548 ebp=013bd840 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202
ntdll!KiFastSystemCallRet:
76fb5cb4 c3 ret
0:002> k
ChildEBP RetAddr
013bd544 76fb4a00 ntdll!KiFastSystemCallRet
013bd548 75810c0a ntdll!ZwOpenFile+0xc
013bd840 75810def kernel32!FindFirstFileExW+0x1c9
013bd860 60c44cbb kernel32!FindFirstFileW+0x16
013bdd5c 60c4585e cimwin32!CImplement_LogicalFile::EnumDirsNT+0x5b2
013be254 60c4585e cimwin32!CImplement_LogicalFile::EnumDirsNT+0x1151
013be74c 60c4585e cimwin32!CImplement_LogicalFile::EnumDirsNT+0x1151
013bec44 60c7b7e9 cimwin32!CImplement_LogicalFile::EnumDirsNT+0x1151
013beec8 666ff3dd cimwin32!CShortcutFile::EnumerateInstances+0x157
013beedc 666ff82f framedynos!Provider::CreateInstanceEnum+0x21
Das Programm „Procdump“ besitzt noch weitere nützliche Einstellungen. So ist es beispielsweise möglich, dass es automatisch einen Speicherauszug eines Prozesses ausgibt, wenn sich eines der Fenster dieses Prozesses aufgehängt hat.
Dieses Verhalten kann durch Angabe der Option „-h“ (für „hung“) eingeschaltet. Auch dadurch kann dann ein ordnungsgemäßer Programmablauf gewährleistet werden, wenn kein Administrator direkt vor der Konsole sitzt.
Eine weitere in der Praxis sehr nützliche Option wird mittels des Schalters „-x“ eingeschaltet. Dadurch wird es dem Systembetreuer möglich, einen Prozess direkt unter dem Debugger zu starten. Diese Option arbeitet in Zusammenhang mit der so genannten „Image File Execution Option“ der Registry, die unter anderem in einem Microsoft Blog zur Windows-Programmierung näher erläutert wird.
Das folgende Beispiel arbeitet zusammen mit dem Prozess „lsass.exe“ und sammelt drei Speicherauszüge des Prozesses, wenn er die CPU mit 90 Prozent für sich beansprucht:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\LSASS.EXE
Debugger = c:\procdump\procdump.exe -c 90 -n 3 -ma -x
Nachdem der Administrator diesen Eintrag abgespeichert hat und der Prozess „lsass.exe“ das nächste Mal startet, wird Procdump diesen mit den entsprechenden Parametern überwachen. Wer sich jetzt fragt, warum es was so etwas Besonderes sein soll, eine Überwachung auf diese Weise zu initiieren, sollte sich das folgende Szenario vorstellen:
Es existieren Prozesse auf Windows-Maschinen, welche die unangenehme Eigenschaft besitzen, sofort nach ihrem Start die gesamte CPU-Leistung für sich zu beanspruchen und damit das System komplett „einfrieren“. Ein Administrator, der dieses System untersuchen will, kann sich erst dann wieder an der Konsole anmelden, wenn diese CPU-Last und damit auch die Ursache des Problems wieder verschwunden sind.
Setzt er hingegen wie beschrieben die Option „-x“ ein, so kann das System diese hohen Systemlasten genau dann aufzeichnen, wenn sie auftreten – ganz gleich ob zu diesem Zeitpunkt niemand auf das System zugreifen kann oder nicht.
