Exchange NOTFALL - Hohe Serverlast

Hohe CPU-Last

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).

Hier lassen sich sehr schnell die Prozesse und ihre aktuelle CPU-Belastung anzeigen. Wenn Sie dann noch die Sortierung nach der CPU-Belastung ausrichten, dann sollten Sie sehr schnell den fraglichen Prozess finden, welcher die hohe Last produziert. Nur sieht man nicht wirklich viel mehr. Detaillierter werden die Ergebnisse mit dem Process Explorer (Sysinternals), welcher sogar auf die einzelnen Thread herunter gehen kann und auch deren zeitlichen Verlauf einews einzelnen Prozesses anzeigen. Hier am Beispiel des Leerlaufprozesses

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:

• STORE
  Das ist der Informationsspeicherdienst. Das Herz von Exchange.
• EMSMTA
  Dieser Prozess überträgt Nachrichten per X.400 und den alten EDK-Gateways (Viele Faxserver nutzen noch diesen Weg)
• EXMGMT
  Exchange Management Prozess. Erlaubt u.a. die Abfrage des Nachrichtentracking per WMI aus der Ferne.
• MAD
  Exchange Systemaufsicht. Erstellt u.a. Adressbücher, betreibt den RUS etc.
• EVENTS
  Der Exchange Ereignisdienst (Siehe auch Exchange Skripting), welche Skripte auf dem Server startet.
• SRSMAIN
  Der Exchange SRS ist nur in einer gemischten Umgebung vorhanden (Exchange 5.5)
• MSSEARCH
  Indexdienst, der auch in Exchange den Index für die Volltextsuche erstellt und pflegt.
• INETINFO und W3WP
  IIS Admin Dienst und der WWW-Worker Prozess. Letztlich eine Komponente des Webservers, der Exchange bei OWA unterstützt aber auch bei der Verwaltung der öffentlichen Ordner (WebDAV). Auch der IMAP4 und POP3-Prozess sind Bestandteil des IISADMIN. Aber auch das Exchange Routing ist hier untergekommen.

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"

• Festplatte voll
  Gerade ältere Server sind eher "klein", so dass eine Datenbank dann eben die Festplattenpartition bis auf wenige Bytes voll schreibt. (Siehe auch Exchange NOTFALL - Festplatte voll)
• 16/18/75 GB Limit Erreicht
  Das andere Limit ist beim Standard Server vorhanden, dessen Datenbank nicht bis 8 TB wachsen darf. (Siehe Exchange NOTFALL - 16 Gigabyte Limit)

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

• Festplattenplatz addieren
  Ist die Datenbank gestoppt, weil die Festplatte voll ist, dann können Sie die Datenbank natürlich bei ausreichend Platz wieder starten. Manchmal reicht es schon, einige andere Daten auf der Festplatte zu komprimieren, temporär auszulagern oder zu löschen. Wenn dies nicht reicht, könnten Sie oftmals seine große externe Festplatte per USB oder Firewire anbinden und die Datenbank dorthin verschieben und starten.
• Exchange 2003 SP2 Limit erhöhen
  Wenn die Datenbank aufgrund der administrativen Limit von Exchange 2003 SP2 beendet wurde, dann können Sie natürlich einfach in der Registrierung diese Grenze etwas höher stellen und die Datenbank wieder online nehmen.
• Enterprise Version oder SP2
  Vielleicht haben Sie aber noch Exchange 2003 SP1 oder früher und ihre Datenbank ist bei 16 GB beendet worden. Dann können Sie bei Exchange 2003 natürlich das Service Pack 2 installieren. Bei Exchange 2000 ist ein Update auf Exchange 2003 oder ein Update auf den Exchange 2000 Enterprise Server möglich, um die Datenbank wieder starten zu können.
• Restore und partielles Roll-Forward
  Wenn all das nicht möglich ist, dann könnten Sie die Datenbank natürlich löschen und vom Backup zurückholen. Wenn Sie dann noch alle Transaktionsprotokolle haben und z.B.: die letzten davon entfernen, können Sie ein Rollforward bis zu einigen MB vor dem Shutdown erreichen. Allerdings ist dieser Weg sehr steinig, da Sie die letzten Mails verlieren und natürlich auch beim Restore und den Folgeaktionen nichts schief gehen darf. Das ist also sicher die schlechteste Option.
• ESEUTIL
  Mit Exchange 5.5 gab es eine Version von ESEUTIL, um offline aus der Datenbank Nachrichten mit bestimmen Inhalten zu löschen. Dazu muss man natürlich wissen welche das sind und diese Lösung hat damals primär dabei geholfen, Exchange Server mit Virenbefall ("I love you") zu bereinigen. Eine so bereinigte Datenbank kann man natürlich noch defragmentieren und damit wieder etwas verkleinern. Ich weiß aktuell nicht mal, ob diese Funktion bei Exchange 2000/2003 überhaupt noch vorhanden ist und führe Sie daher nur der Vollständigkeit halber an.
• PowerControls 4 oder Recovery Storage Group
  Es gibt Programme, die eine Datenbank "offline" ohne Exchange öffnen und Inhalte extrahieren können. Sie könnten daher einfach eine "leere" Datenbank anlegen und die Mitarbeiter weiter arbeiten lassen. Die Inhalte könnten Sie dann über eine Recovery Storage Group von einem anderen Server nachträglich einspielen. Sicher eher eine Lösung, wenn Sie sehr schnell wieder Mails senden und empfangen können müssen und Altdaten nicht sofort wieder erforderlich sind.

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

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.

• Filemon (Sysinternals)
  Filemon protokolliert alle Dateizugriffe und erlaubt ihnen so zu sehen, welcher Prozess und welches Programm auf welche Dateien zugreift. Leider ist ist Ausgabe dann einfach eine "Liste" der Zugriffe. Eine statistische Auswertung oder Konsolidierung der Daten (Megabyte pro Prozess o.ä.) findet leider nicht statt. Daher ist die "Suche" natürlich etwas mühselig. Allerdings können Sie hier schon gut erkennen, welche Prozesse außer Exchange auf den Festplatten aktiv sind. Vielleicht ist es ja gerade ein Virenscanner, ein Backup oder der Windows Defender auf der Suche nach SpyWare.
• Perfmon (Windows)
  Aber auch der Performance Monitor erlaubt eine Annäherung an das Thema, da Windows für jeden Prozess auch die Anzahl und Menge der I/Os mitprotokolliert. Zwar fallen darunter auch andere Operationen wie Netzwerk und Gerätetreiber aber das Dateisystem macht hier natürlich einen gewichtigen Anteil aus
  
  Wenn Sie sich daher von allen Prozessen einfach die E/A-Daten anzeigen lassen, dann finden Sie zumindest die "aktivsten" Prozesse

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

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.