06.06.2013 Aufrufe

70-685 Windows 7 Support in Unternehmen.pdf - Gattner

70-685 Windows 7 Support in Unternehmen.pdf - Gattner

70-685 Windows 7 Support in Unternehmen.pdf - Gattner

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

300 Kapitel 8: Leistung<br />

Bevor Sie beg<strong>in</strong>nen<br />

Um die Übungen <strong>in</strong> diesem Kapitel durcharbeiten zu können, sollten Sie mit <strong>W<strong>in</strong>dows</strong> 7<br />

vertraut se<strong>in</strong> und folgende Aufgaben beherrschen:<br />

Installieren von <strong>W<strong>in</strong>dows</strong> 7<br />

E<strong>in</strong>en Computer hardwaremäßig an das Netzwerk anschließen<br />

Durchführen e<strong>in</strong>facher Verwaltungsaufgaben auf e<strong>in</strong>em <strong>W<strong>in</strong>dows</strong> Server 2008 R2-<br />

Domänencontroller<br />

Praxistipp<br />

Tony Northrup<br />

Vor Kurzem untersuchte ich sporadisch auftretende Leistungsprobleme auf e<strong>in</strong>em Webserver.<br />

In sche<strong>in</strong>bar zufälligen Abständen wurde der Webserver so langsam, dass die<br />

Benutzer die Site überhaupt nicht mehr besuchen konnten. In dem Moment, als sich e<strong>in</strong><br />

Benutzer bei mir beschwerte, war die Site aber schon wieder verfügbar.<br />

Um das Problem e<strong>in</strong>zukreisen, führte ich die Leistungsüberwachung im Protokollierungsmodus<br />

aus. Dabei fand ich heraus, dass die gesamte Prozessorauslastung während der<br />

10-m<strong>in</strong>ütigen Phase, <strong>in</strong> der die Probleme auftraten, auf 100 Prozent stieg (während sie<br />

normalerweise rund 10 Prozent betrug). Bis der Server Webanforderungen bediente,<br />

verg<strong>in</strong>gen <strong>in</strong> diesen Phasen durchaus 30 Sekunden (im Normalbetrieb 0,02 Sekunden).<br />

Während ich die Leistung der e<strong>in</strong>zelnen Prozesse überwachte, verbrauchte ke<strong>in</strong>er dieser<br />

Prozesse die zusätzliche Prozessorzeit. Der schuldige Prozess war also zu dem Zeitpunkt,<br />

als ich die Leistungsüberwachung konfigurierte, nicht gelaufen. Die Leistungsüberwachung<br />

half mir, weitere Symptome des Problems zu f<strong>in</strong>den, aber die tatsächliche<br />

Ursache kannte ich noch nicht.<br />

Ich notierte, wann das Problem auftrat, und untersuchte diese Zeitabschnitte <strong>in</strong> der Ereignisanzeige.<br />

Dabei stellte sich heraus, dass Fehlermeldungen des Webservers aufgezeichnet<br />

wurden, weil die Webanforderungen nicht schnell genug verarbeitet wurden. Das<br />

war natürlich nicht die Ursache, sondern e<strong>in</strong>e Folge der hohen Prozessorauslastung.<br />

Diese Ereignisse brachten mich aber auf die richtige Spur für die Problembehandlung,<br />

weil sie konsistent immer dann auftraten, wenn das Problem begann. Ich richtete e<strong>in</strong>en<br />

Ereignistrigger e<strong>in</strong>, der e<strong>in</strong>e Nachricht an me<strong>in</strong> Telefon schickte, sobald das Ereignis<br />

auftrat. Als es das nächste Mal so weit war, rannte ich zur Webserverkonsole, öffnete den<br />

Task-Manager und fand den Prozess, der die gesamte Prozessorzeit verbrauchte.<br />

Dieser Prozess war e<strong>in</strong> Skript, das die Datenbank aufräumte. Es war so geschrieben, dass<br />

es 100 Prozent der Prozessorzeit mit Beschlag belegte und den gesamten Server ausbremste.<br />

Der Webserver startete das Skript automatisch nach e<strong>in</strong>er bestimmten Zahl von<br />

Datenbanktransaktionen, was erklärte, warum die Abstände re<strong>in</strong> zufällig wirkten.<br />

Um das Problem zu beseitigen, änderte ich, wie das Skript gestartet wurde. Statt das<br />

Skript direkt auszuführen, rief ich das Tool Start.exe auf, wobei ich mit dem Argument<br />

/low festlegte, dass das Skript mit niedrigerer Priorität laufen sollte. Außerdem verwendete<br />

ich das Argument /aff<strong>in</strong>ity, um e<strong>in</strong>zustellen, dass das Skript nur e<strong>in</strong>en der vier<br />

Prozessorkerne auf dem Webserver benutzen durfte. Auf diese Weise brauchte das Skript<br />

länger, brachte aber nicht den ganzen Webserver zum Erliegen.

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!