Exchange NOTFALL - Hohe Serverlast
Auf dieser Seite finden Sie Informationen, wie Sie einer plötzlichen sehr hohen Last auf ihrem Server auf die Spurkommen können. Das Wissen um das "woher kommt die Last" ist der erste Ansatz zum Abstellen der Ursache.
Symptome
Zu den große Problemen eines Exchange Administrators gehören Situationen, in denen der Exchange Server anscheinend etwas tut aber nicht das, was man von ihm erwartet. Es scheint so, als ob sich das System mehr mit sich selbst beschäftigen würde also mit der Abarbeitung von Anfragen der Anwender. Das kann sich durch folgenden Symptome zeigen:
- Hohe CPU-Last
- Datenbankgröße explodiert
- Hohe Festplattenaktivität verbunden mit "langsamer" gefühlter Performance
- Protokolldateien schreiben die Festplatte voll
- Client bekommt das Fenster "Daten werden abgerufen"
(Siehe auch Outlook Daten werden abgerufen)
Ehe wir nun für jedes Symptom die entsprechenden Maßnahmen durchgehen erkläre ich ihnen die Werkzeuge, die einem Exchange Administrator so zur Verfügung stehen
Werkzeuge
Folgende Hilfsmittel haben sich für die Fehlersuche als sehr hilfreich herausgestellt:
-
Nachrichtentracking
(Exchange Lieferumfang)
Wenn Sie den Verdacht haben, dass eine Mail "im Kreis läuft, eine Regel ein Ping Pong produziert oder ein Anwender ihr System als Relay missbraucht, dann ist das Nachrichtentracking eine Anlaufstelle, dieses Fehlverhalten zu analysieren. Zwar kann man mit den Bordmitteln erst einmal nur den Weg einer Nachricht verfolgen, aber oft reicht schon der Blick in das Verzeichnis mit dem Messagetracking. Dort liegen in der Regel 14 Dateien und allein die Größe der Dateien ist ein Hinweis, ob sich das Volumen noch im Rahmen der normalen bewegt - SMTP-Tracking (Windows System, per Default OFF)
Nicht alle Nachrichten gehen "durch" das Exchange Routing, sondern einige werden schon durch den SMTP-Dienst verarbeitet. - HTTP/POP3/IMAP4-TRACKING
(Windows und Exchange, per Default OFF)
Auch diese Protokolle helfen mit, besonders aktive Clients zu erkennen und deren Verhalten zu beobachten. -
NetMon, Wireshark und
Packetyzerrr
Diese Programme sind eigentlich "Netzwerkmonitore" mit denen man in die einzelnen Pakete reinschauen kann. Aber allein für statistische Datenerhebungen sind diese Programme ebenfalls nützlich, da Sie alle Kommunikationspartner samt der Anzahl der Pakete aufzeichnen und mehr oder minder nett grafisch anzeigen. Mein Favorit ist hier href="../tools/packetyzer.htPacketyzer. So können Sie bei einem noch laufenden Server vielleicht "besonders" aktive Clients ermitteln. -
ExMon (Microsoft, Freeware, Add-on)
Diese Programm wird auf dem Exchange Server gestartet und zeigt vor allem auch die Aktivität der MAPI-Clients an, die anders nur sehr schwer zu ermitteln sind. Diese Programm hat mir schon oft geholfen, wenn Anwender etwas "unfreundlich" mit dem Server umgegangen sind, z.B.: massenhaft Daten exportieren oder importieren oder Regel oder Synchronisation sich "daneben" benehmen. - ProcessXP (Sysinternals)
Der Windows Taskmanager ist keine echte Hilfe bei der Analyse von hohen CPU-Belastungen. Bessere Arbeit leistet hier der Process Explorer von Sysinternals, mit dem Sie sogar bis auf Threadebene herunter gehen können. -
Perfmon
Analog dazu können Sie mit PERMON durchaus aussagekräftige Ergebnisse erhalten und Verhalten analysieren. Allerdings ist es hier natürlich von Vorteil, wenn Sie die Daten für den "Normalbetrieb" können. Ein deutlicher Fingerzeig Richtung MOM2005. Aber auch so können Sie natürlich z.B.: die Verbindungen des SMTP-Servers oder die RPC-Aufrufe des Informationsspeichers anzeigen lassen. - Filemon (Sysinternals)
Manchmal ist es aber gar nicht der Exchange Server sondern ein anderer Prozess. Dann ist Filemon ein Hilfsmittel, da Sie damit die einzelnen Dateizugriffe ermitteln können. Leider ist das nur eine lange Liste, in der natürlich auch die Exchange Datenbanken einen großen Anteil haben, aber mit etwas Erfahrung können Sie auch Filtern und sich den "Rest" anschauen. Interessant ist hier z.B.: TEMP aber auch die SMTP-Warteschlange etc. Ein anderer Weg für Dateiaktivitäten zu ermitteln ist natürlich wieder mit Perfmon und der I/O-Aktivität pro Prozess möglich
Schritte zur Ursachenfindung
Um Ursachen zu finden, müssen Sie was tun und je nach "Schwere" ihres Exchange Servers können Sie noch was tun. Ich unterscheide hier folgende Fälle:
- Hohe Belastung aber kaum Betriebsstörung
In dem Fall bemerken die Anwender nur wenig und nur ihnen fällt etwas auf, z.B.: hohe CPU-Last oder schnell abnehmender Platz auf der Festplatte. Entscheiden Sie, ob Sie den Zustand nun einfach nur "passiv" untersuchen möchten und Änderungen außerhalb der Kernarbeitszeit verlegen. - Hohe Belastung mit Betriebsstörung aber Administration möglich
Wenn die Anwender sich aber über starke Einbußen oder gar Ausfälle klagen, dann müssen Sie aktiv werden. Solange Sie aber auf dem Server selbst noch Aktionen ausführen können, sollten Sie diese Chance nutzen und erst einmal" beobachten". - Server reagiert sehr träge
In der Situation können Sie meist nicht mehr viel machen und die Anwender auch nicht. Wenn Sie etwas Geduld mitbringen, kann es aber sinnvoll sein, hier zumindest mal den Taskmanager mit "CTRL-SHIFT-ESC" zu starten, um vielleicht doch etwas zu sehen. - Server reagiert überhaupt nicht mehr
Tja dann ist Hilfe schwer. Vielleicht haben Sie aber noch eine Chance, indem Sie entweder aus der Ferne einige Diente beenden oder vielleicht einfach nur das Netzwerkkabel ziehen. Wenn die Ursache wirklich ein Zugriff über das Netzwerk ist , dann könnte es sein, dass sich der Server doch wieder fängt und Sie weiter analysieren können
Auf jeden Fall sollten Sie den Server nicht einfach ausschalten oder herunterfahren, weil nach einem Neustart meist das Problem wieder für einige Zeit weg ist aber Sie keinen Schritt näher der Lösung sind. Also schauen wir mal, was man "tun" kann.
Symptom und Aktion
Auch wenn es sehr schwer ist eine "Schritt für Schritt"-Anleitung für jeden Fall zu schreiben, so möchte ich doch versuchen, ein paar Hinweise all denen zu geben, die gar nicht weiter wissen. Sie sollten aber immer sich daran erinnern, dass ein Telefonat mit einem qualifizierten Spezialisten bei Microsoft oder einer Partnerfirma weniger kostet als ein kompletter Datenverlust oder der Vertrauensverlust bei den Mitarbeitern und Firmeninhabern.
Symptom | mögliche Aktion |
---|---|
Hohe CPU-Last |
Eine hohe CPU-Belastung würde jeder Administrator eines Großrechners
freudig begrüßen, da hier oft nach CPU-Zyklen abgerechnet wird und eine
CPU ohne Arbeit teuer brachliegendes Kapital ist. Bei PCs hingegen ist
eine CPU auf 100% fast immer ein Zeichen einer Fehlfunktion oder
zumindest eines temporären Engpasses. Natürlich kann ein langsamer
Server auch stundenlang auf 100% laufen ohne dass jemandem dies auffällt
da Windows auch eine Priorisierung von Prozessen erlaubt. Sie glauben
gar nicht wie viele Exchange Server noch mit einem Pentium 200 "gehen". Um eine Aussage wie "die CPU hat eine Hohe Last" zu treffen, sollten Sie schon vorab ein paar Tage einfach ihre "normale" CPU-Last z.B. mit Perfmon beobachten. Trotzdem ist natürlich bei einer unerwarteten hohen CPU-Last der
erste Blick der Windows Taskmanager (Schnellstart über CTRL-SHIFT-ESC). Wenn Sie den fraglichen Prozess gefunden haben, müssen Sie anhand des Namens natürlich auch das Programm zurück schließen. In Verbindung mit Exchange sind folgende Prozesse zu sehen:
Auf einem Exchange Server sind aber sehr oft noch andere Dienste wie z.B.: ein Blackberry Server, Virenscanner, Datensicherung und MOM-Agent installiert, die Verursacher einer hohen CPU-Last sind. Eine Anweisung, wie Sie diese hohe Last eingrenzen, kann ich leider nicht geben, da die Ursachen vielfältig sind. Das kann eine korrupte Mail ebenso sein, wie ein Amok laufender Virenscanner oder Backupprozess. |
Datenbankgröße "explodiert" |
Normalerweise haben Exchange Datenbanken die Angewohnheit immer
größer zu werden. Das liegt in der Natur der Sache, da jeden Tag neue
Nachrichten geschrieben und empfangen werden und die meisten Personen
diese natürlich nicht löschen, sondern aufbewahren. Das ist auch nicht
schlimm, solange es eine normale Verwendung ist und die Datenbanken
"geplant" langsam wachsen. Aber es gibt Situationen, bei denen die
Datenbank quasi explosionsartig wächst und an eine der Obergrenzen
stößt:
Eine sehr große Datenbank hat aber auch noch den Nachteil, dass die Datensicherung viel mehr Zeit und Bandmaterial benötigt und die Handhabung schwerer wird. Daher müssen Sie natürlich wissen, was in der Datenbank enthalten ist und wie Sie diese Daten wieder beseitigen können. Wenn ihre Datenbank noch läuft, dann ist der Blick mit dem Exchange System Manager natürlich der einfachste Weg die Größe der einzelnen Postfächer zu betrachten und die Ausreißer zu erkennen und zu ermahnen. Die Inhalte selbst können die Anwender selbst oder auch Sie als Administrator auf dem Server z.B.: mit EXMERGE extrahieren und auf dem Server löschen. Damit werden aber nur Speicherseiten in der Datenbank freigegeben. Die Datenbank selbst wird erst durch ein Offline Defragmentierung (siehe Exchange Datenbank defragmentieren) kleiner. Ehe Sie nun aber sofort defragmentieren, sollten Sie eventuell eine Nacht abwarten, bis Exchange die online Defragmentierung durchgeführt hat. Im Eventlog finden Sie dann nämlich sehr einfach den freien Speicherplatz, den Sie durch eine Defragmentierung gewinnen können. Es wäre nicht das erste mal, dass die Hoffnung auf ein Defrag in Ernüchterung umgeschlagen ist. Zukünftig sollten Sie mit Postfachbeschränkungen als "Schutzmaßnahme" arbeiten, d.h. damit ein Benutzer durch absichtliche oder unabsichtliche Fehlbedienung nicht einen ganzen Server stört. Seit Exchange 2003 SP2 ist es auch möglich, dass Sie als Administrator per Registrierung eine Obergrenze festlegen. Das ist besonders wichtig, wenn Exchange nicht alleine auf dem Server läuft und daher eine Datenbank besser herunter gefahren wird, als den Server komplett voll zu schreiben und damit andere Dienste in Mitleidenschaft zieht. Aber auch hier sollten Sie sich eine Überwachung (z.B. MOM2005) überlegen, da Exchange entsprechende Warnungen in das Eventlog schreibt. Ist die Datenbank allerdings schon "herunter" gefahren, so ist guter Rat teuer. Es ist nämlich gar nicht so einfach, eine Datenbank von Ballast zu befreien, die nicht mehr gestartet wird. Hier haben Sie je nach Version vier Optionen
Sie sehen, dass es mit dem entsprechenden Wissen sehr viele Optionen gibt einen Exchange Server mit diesem Problem wieder in Gang zu bringen. Dennoch ist es natürlich besser, wenn diese Fall gar nicht erst eintritt. Daher prüfen Sie, ob Sie die administrativen Limits von Exchange 2003 SP2 und Postfachgrenzwerte einsetzen und ihren Server proaktiv überwachen. |
Hohe Festplattenaktivität verbunden mit "langsamer" gefühlter Performance |
Oft sehen Sie auf dem Server eine niedrige CPU-Last aber dennoch
scheint der Server irgendwie "träge" zu sein und die Festplatten blinken und leuchten wie verrückt. Auch in diesem Fall ist eine Analyse möglich.
Denn Festplatten sind nun mal Mechanik und der langsamste Teil eines
Servers. Speziell Positionierung und Datenübertragung sind ein
vielfaches langsamer, als CPU, Hauptspeicher und mittlerweile auch
Netzwerk übertragen können. Ein langsames Festplattensubsystem ist daher
oft der eigentliche Engpass in einem Server. Und solche einen Engpass
kann man müssen und erkennen. Die Lämpchen an den Festplatten sind hierzu überhaupt nicht geeignet, wenn würden diese wirklich nur beim Zugriff leuchte, dann wäre dies so kurz, dass unser menschliches Auge das nicht mal sehen würde. Es sieht ja auch nicht, dass jede Leuchtstoffröhre 100 Mal pro Sekunde kurz aus ist. Das Hilfsmittel hier ist zu allererst Perfmon und hier die Counter für die Festplattenwarteschlange. Diese zeigen genau an, wie viele ausstehende Aktionen auf die Festplatte warten.
So können Sie gut erkennen, ob die Festplatten der Engpass sind. (Details siehe auch Exchange Sizing - Wie dimensioniere ich die Hardware ?) Sollte sich herausstelle, dass wirklich die Festplatten beschäftigt sind, dann gilt das Interesse natürlich dem jeweiligen Dienst, welcher die Last erzeugt. Hier gibt es zwei Wege der Sache näher auf den Grund zu kommen.
Wenn sie einen "guten" RAID-Controller haben, dann können Sie oftmals auch mit den dazugehörigen Hilfsprogrammen Informationen über dessen Betriebsdaten und die Belegung der Festplatten und BUS-Systeme erhalten. Auch hier kann ein Engpass vorhanden sein, z.B.: wenn Sie ein RAID5 mit 7 Festplatten auf einem SCSI-Bus betreiben und gerade ein Rebuild stattfindet. Lieber einmal mehr schauen. Vielleicht ist ihr Server nur deshalb so langsam, weil das Raid-Controller gerade einen Fehler korrigiert. Es ist schon vorgekommen, dass auch ein Exchange Server nebenbei als "Dateiserver" dienen durfte. Kontrollieren Sie doch mal, welche Freigaben auf dem Server vorhanden sind und wer darauf gerade zugreift. Auch eine verzögerte Datensicherung kann manchmal tagsüber starten, wenn das defekte Band morgens repariert wird und der Job der Nacht dann erst lost startet. Leider ist es ansonsten nicht einfach, mit Bordmitteln sehr viel tiefer in die Tätigkeit eines Servers vorzustoßen. Der hierfür sicherlich geeignete FILEMON ist leider nicht für die Ermittlung von Mengen geeignet und nur wenige werden dessen Ausgabe mit Excel oder dem LogParser geeignet umformatieren. |
Protokolldateien schreiben die Festplatte voll |
Viele Transaktionsprotokolle bedeuten, dass Informationen in die
Datenbank geschrieben werden. Meist nimmt dann auch die Größe der
Datenbank entsprechend zu. Wenn die Datenbank weiter wächst, dann könnte
eine Regel oder ein Client die Ursache sein, die massenhaft Nachrichten
an Empfänger in ihrer Datenbank sendet. Hier können Sie über das Nachrichtentracking oder auch einfach die Anzeige der Postfachgrößen oftmals das fragliche Postfach erkennen. Ein schneller Blick dort hinein zeigt ihnen dann, was darin "los" ist. Sie können temporär zur Fehlersuche auch einfach mal den SMTP-Dienst und den MTA beenden. Die Anwender können weiterhin arbeiten, nur werden keine Nachrichten mehr übermittelt. Wenn die Protokolldateien dann nicht mehr geschrieben werden, dann ist die Ursache in eine Mail zu suchen, die übertragen wird. Hier können Sie auch mit dem Nachrichtentracking nun auf Spurensuche gehen. Ist nach dem Stoppen dieser Transportdienste aber immer noch keine Ruhe, dann liegt es wohl am Client, der z.B.: Daten importiert oder über Outlook repliziert. Nun ist es an der Zeit den urheber ausfindig zu machen. mit NetMon, Wireshark und Packetyzer und natürlich mit ExMon können Sie auf dem Server versuchen, den Client zu finden, der ihren Server so stark belastet. Wenn Sie den Client gefunden haben können Sie den Anwender bitten ihnen seine aktuelle Tätigkeit zu beschreiben. Es passiert durchaus, dass der Anwender gar nicht bemerkt, dass er ein Problem verursacht. Er kann Outlook beenden, seinen PC herunterfahren oder einfach mal das Netzwerk abtrennen. Wenn der PC nicht von ihnen erreichbar ist, dann können Sie als Administrator natürlich z.B.: den Leitweg zur IP-Adresse dieses PCs mit einem "ROUTE ADD" verbiegen, so dass der PC nicht mehr arbeiten kann. Optional können Sie das Konto des Anwenders einfach deaktivieren, aber Sie sollten dazu die Seiteneffekt von Exchange 2000/2003 Disabled Account können. Der Anwender kann ohne weitere Vorkehrungen auch keine Mails mehr empfangen ! Wenn Sie mit EXMON und den anderen Werkzeugen aber keinen Client finden, der ihren Server belastet und auch das beenden des MTA und SMTP-Servers keine Hilfe bringt, dann scheint es sich um eine umfangreichere Problematik zu handeln, die ich hier nicht lösen kann. Sie können natürlich einfach mal den Informationsspeicher beenden und neu starten. Wenn die Clients alle in einem andren Subnetz sind, dann können Sie z.B.: mit "ROUTE ADD Clientsubnetz Mask 255.x.x.x 1.2.3.4" diese Netz "unerreichbar" machen und damit alle Clients aussperren ohne den Server selbst von seinen anderen Exchange Servern oder Domaincontrollern zu trennen. Route ADD ist unter Windows 2008 und höher nicht mehr empfohlen. Nutzen Sie stattdessen netsh (IP routing commands http://technet.microsoft.com/en-us/library/cc783403(WS.10).aspx) netsh interface ipv4 add route 1.2.3.4/24 Interface=nicname nexthop=xx.xx.xx.xx store=persistent Ein anderer häufiger Verdächtiger ist der Virenscanner. Es wäre nicht das erste Mal, dass diese Exchange stören, da Sie über die AVAPI-Schnittstelle ja jede Mail erhalten und bei Bedarf auch verändern. Oftmals Ich kenne ihren Server nun nicht aber vielleicht hat jemand ja eine Regel auf dem Server, ein Exchange Event Skript oder einen globalen Event Sink eingerichtet. Wohl dem der eine aktuelle Dokumentation hat. Knifflig wird es, wenn ihnen in absehbarer Zeit der Festplattenplatz ausgeht oder Sie die Ursache nicht finden. Dann können sie Protokolldateien löschen, indem Sie mit ihrer Backupsoftware z.B.: ein Inkrementelles oder ein volles Backup fahren. Löschen Sie bitte nie Transaktionsprotokolle, solange die Datenbanken noch gestartet sind, da das Risiko einer Fehlbedienung sehr hoch ist. Transaktionsprotokolle löschen ist möglich, denn die Datenbanken beendet sind (Exchange beendet die Datenbanken ebenfalls automatisch, wenn der Platz zur Neige geht). Wenn Sie dann mit ESEUTIL sichergestellt haben, dass die Datenbank konsistent ist, können Sie alte Protokolldateien löschen. Temporär kann auch die umschaltung der Speichergruppe auf "Umlaufprotokollierung" (Circular Logging) den Notstand überbrücken. |
Client bekommt das Fenster "Daten werden abgerufen" |
Diese Fenster ist seit Outlook 2003 neu und zeigt dem Anwender an, dass eine RPC-Anfrage an den Server etwas länger als erwartet dauert. Dabei kann es sich um temporäre Spitzenlasten des Servers oder eine langsame Anbindung (Speziell über WAN) handeln (Tipp -> Outlook 2003 Cached Mode) Über Gruppenrichtlinien können Sie nun Outlook so einstellen, dass die Warnung nicht mehr nach einer Sekunde kommt, sondern später. Oft reicht das schon aus. Trotzdem sollten Sie ihren Server genauer untersuchen, ob er vielleicht doch an seiner Leistungsgrenze angekommen ist. |
Ich hoffe Sie haben vielleicht den ein oder anderen Tipp zur Fehlersuche erhalten und ich wünsche ihnen eine erfolgreiche Suche. Ansonsten sollten Sie immer im Hinterkopf haben, dann für eine Fehlersuche eine gute Vorarbeit, z.B.: in Form einer Ist-Aufnahme der "normalen" Betriebsdaten, damit Sie überhaupt erkennen können, ob etwas nicht mehr normal ist, z.B. mit MOM2005. Auch die Installation entsprechender Tools auf "Vorrat" ist eine sinnvolle Vorarbeit, die Sie direkt nach der Installation des Server durchführen können.
Meine Empfehlung für Tools:
Windows Support Tools, Windows Ressource Kit, ExMON, FileMon, RegMon,
Paketyzer, Process Explorer, WinDirStat, ExBPA