Exchange und der Hauptspeicher

Die Ära der 32-Bit-PC-Systeme neigt sich langsam ihrem Ende entgegen. Dabei treten teilweise Probleme auf, wie man sie schon von den 16-Bit-Systemen im Speicherbereich kannte. 32 Bit ermöglichen es, 232 Byte, also 4 GB an Speicher direkt zu adressieren. Die Speicherbausteine sind mittlerweile so preiswert, dass es sich in vielen Fällen lohnen würde, Systeme mit mehr als 4 GB pro Prozessor auszustatten. Die Möglichkeit, auf einer immer geringeren Zahl leistungsfähigerer Server immer mehr Benutzerkonten zu verwalten, birgt einiges Potenzial für eine Kostenersparnis in sich. Deshalb ist es ärgerlich, wenn diese Möglichkeit durch ein technisches Hemmnis, anstelle einer reinen Kostenbarriere, unmöglich gemacht wird. 64-Bit-Architekturen sind zwar rechtzeitig am Markt erschienen und haben mittlerweile auch bereits einen beträchtlichen Marktanteil, aber die Migration auf diese Architektur ist noch nicht vollzogen. Insbesondere im Windows-Bereich ist vor allem die Software noch hauptsächlich in 32-Bit-Versionen verfügbar. Exchange wird diesen Schritt ebenfalls erst mit der nächsten Version gehen. Die Produktzyklen der Programme sind in diesem Fall schlichtweg zu lang für die rasante Entwicklung des Hardwaresektors.

Grundlagen des Prozessspeichers

Genau genommen handelt es sich bei dem betrachteten Speicherproblem mehr um ein „virtuelles“ Problem. Es betrifft nämlich den virtuellen Hauptspeicher der einzelnen Prozesse und nur mittelbar den physischen Speicher des Rechners. Ähnlich wie früher bei 16-Bit-Architekturen haben Systemarchitekten Technologien wie PAE (Physical Address Extension) und AWE (Address Windowing Extensions) entwickelt, mit denen sich Rechner mit mehr als den rechnerisch möglichen 4 GB physischem Hauptspeicher pro Prozessor ausstatten lassen.

Windows weist jedem einzelnen Prozess einen virtuellen Adressraum zu. Er ist, unabhängig vom wirklich vorhandenen physischen Speicher, maximal 4 GB groß. In der Praxis können Programme diesen Speicher allerdings nur sehr selten vollständig ausschöpfen. Auf jedem Rechner laufen parallel mehrere Prozesse, die theoretisch alle Anspruch auf 4 GB Hauptspeicher haben. Zudem kooperieren sie in keiner Weise miteinander, wenn es um die Verteilung des physischen Speichers geht. Die Schaffung der virtuellen Adressräume für Prozesse dient ja gerade dazu, die Programmierer von derartigen Fragen zu entlasten. Fast alle Programme sind deshalb so programmiert, als würde ihnen der Speicher allein gehören.

Zudem betrachtet kaum ein Programm die auf dem konkreten Rechner vorhandene Speichersituation. Dies trifft allerdings im Falle von Exchange nicht ganz zu. Exchange macht beim Hochfahren der Dienste eine kurze Speicheranalyse und schreibt gegebenenfalls einen Eintrag mit der ID 9665 in das Windows-Ereignisprotokoll. Die genaue Beschreibung der auslösenden Faktoren für diesen Eintrag und einige weitere Maßnahmen zur Speicheroptimierung finden sich im Knowledgebase-Artikel KB815372.

Die Konkurrenz der Programme um den zur Verfügung stehenden physischen Speicher ist in der Regel nicht so groß. Die meisten Programme benötigen nicht annähernd den ihnen zustehenden theoretischen Speicher und haben einen eher konstanten Speicherbedarf. Nur einzelne Anwendungen eines Rechners verbrauchen einen Großteil des Speichers. Exchange geht bei seiner Speicheranalyse genauso wie die folgende Darstellung davon aus, dass es das einzige derartig anspruchsvolle Programm auf dem Server ist. Vorsicht ist geboten, wenn auf einem Rechner ein zweites Serverprogramm läuft, beispielsweise ein Domänencontroller. Dann gilt es bei der Optimierung der Speichersituation auch die Anforderungen dieses Programms zu berücksichtigen.

Auslagerungsspeicher

Wird die Hardware eines Rechners voll ausgenutzt, dann kann es vorkommen, dass die laufenden Prozesse zusammen mehr Speicher beanspruchen, als physischer Speicher in dem Rechner vorhanden ist. Um auch diesem Problem zu begegnen, besitzen moderne Betriebssysteme so genannte Auslagerungsdateien (Swap Files). Speichersegmente, die gerade nicht verwendet werden, werden temporär auf der Festplatte gespeichert, um Platz für weitere Speicheranforderungen zu schaffen. Die Auslagerungsdatei erweitert hierdurch den Hauptspeicher, der dem System zur Verfügung steht.

Die Auslagerung von Speichersegmenten macht allerdings nur Sinn, wenn diese zwar angefordert, aber nur selten verwendet werden. Dann müssen diese Segmente nur selten wieder aus der Auslagerungsdatei in den physischen Speicher zurückgeladen werden. Wenn die Speicherauslastung so groß wird, dass auch häufig verwendete Segmente zwischenzeitlich ausgelagert werden müssen, wird es problematisch. Das Auslagern und Laden eines Speichersegments kostet einigen Aufwand. Wenn Segmente zu häufig ausgetauscht werden müssen, dann wird die Leistung des Gesamtsystems stark herabgesetzt. eanspruchen die laufenden Prozesse insgesamt mehr Speicher, als die Größe des Hauptspeichers und der Auslagerungsdatei zusammen zur Verfügung stellen, kommt es schließlich zu Systemfehlern bis hin zum Absturz des Rechners.

Anwendungs- und Kernelspeicher

Erschwerend kommt hinzu, dass der virtuelle Adressbereich einer Anwendung in zwei Teile geteilt ist. Der eine Teil steht der Anwendung zur alleinigen Verfügung und der andere Teil, der so genannte Kernelspeicher, dient dazu, Daten mit dem Betriebssystem auszutauschen. Den Zugriff auf diesen Bereich teilen sich Anwendung und Systemkern.

Standardmäßig ist die Aufteilung des Adressbereichs gleichmäßig, das heißt, dass Kernel- und Anwendungsspeicher virtuell jeweils 2 GB groß sind. Diese Aufteilung kann aber über einen Schalter (/3GB) in der Datei Boot.ini angepasst werden. Ist dieser Schalter hinter der gestarteten Systemkonfiguration angegeben, stehen jeder Anwendung nur noch 1 GB Kernelspeicher zur Verfügung. Diese Vorgabe gilt dann für alle Prozesse des Rechners.

Einer Anwendung kann sowohl der Kernelspeicher als auch der Anwendungsspeicher ausgehen. Die Entscheidung, ob der /3GB-Schalter gesetzt wird, muss sich deshalb nach den Ansprüchen der speicherhungrigsten Anwendung eines Systems richten. Besonders Serveranwendungen brauchen viel Kernelspeicher, da jede einzelne Netzwerkverbindung Systemspeicher benötigt. Für Exchange Server 2000 und 2003 empfiehlt Microsoft das Setzen des /3GB-Schalters deshalb nur für Server, die Postfächer und öffentliche Ordner speichern und über mehr als 1 GB physischen Hauptspeicher verfügen (KB815372). In diesem Fall ist der Bedarf des Store. exe-Prozesses an Anwendungsspeicher größer als der des Netzwerks an Kernelspeicher. Der Schalter sollte nicht gesetzt werden, wenn der Server auch Domänencontroller oder Active Directory-Server ist, wie dies auch für Small Business Server gilt. Gleiches trifft zu, wenn andere Serveranwendungen auf dem Rechner parallel ausgeführt werden, die viel Kernelspeicher benötigen.

Über den /USERVA-Schalter kann die Aufteilung zwischen Kernel- und Anwendungsspeicher noch genauer gesteuert werden. Für die Konfiguration von Postfach-Servern mit Windows 2003 und Exchange 2003 empfiehlt die Vorgabe /USERVA: 3030 (KB810371). Dies gibt 3030 MB Anwendungsspeicher vor anstelle der 3072 MB, wenn nur der /3GB-Schalter angegeben würde. Der /USERVA-Schalter muss zusätzlich zum /3GBSchalter angegeben werden (/3GB /USERVA: 3030).

PSE und PAE

Die Erweiterung des physischen Hauptspeichers durch eine Auslagerungsdatei birgt ein weiteres Problem. Ein 32-Bit-Prozessor kann maximal 4 GB adressieren. Dies bedeutet auch, dass unter diesen Umständen kein Prozess seinen virtuellen Adressbereich voll ausschöpfen kann, da auf modernen Systemen immer mehrere Prozesse gleichzeitig laufen.

Bereits mit dem Pentium II-Prozessor hat Intel allerdings eine Technologie namens Page Size Extension (PSE) eingeführt, die es dem Prozessor erlaubte, mehr als 4 GB physischen Speicher zu adressieren. Mit dem Pentium Pro kam als Alternative Physical Address Extension (PAE) hinzu. Diese Technologien waren zuerst auf spezielle Serversysteme zumeist auf Unix-Basis ausgerichtet. Die neueren Windows-Systeme unterstützen die PAE-Technologie aber ebenfalls. Sie stellt dem System 4 weitere Adressbits zur Verfügung, also insgesamt 36. Hierdurch kann ein Prozessor bis zu 32 GB Speicher adressieren.

PAE-Unterstützung ist im Windows-Systemkern seit Version 2000 integriert. Sie ist war aber ursprünglich standardmäßig deaktiviert. Aktiviert wird sie über den /PAE-Schalter in der Boot.ini-Datei. /NOPAE deaktiviert sie entsprechend. Erst wenn ein Systemkern mit aktivierter PAE-Unterstützung gestartet wird, kann er auch mehr als 4 GB Speicher adressieren. In Windows 2000 Advanced Server ist die PAE-Unterstützung allerdings auf maximal 8 GB begrenzt. Für die kleineren Versionen von Windows 2000 und Windows XP sowie Windows 2003 Standard Edition ist dem System auch bei aktivierter PAE-Unterstützung die Adressierung von mehr als 4 GB nicht erlaubt.

Windows enthält zudem eine Programmierschnittstelle namens Address Windowing Extensions (AWE), die es auch einzelnen Anwendungen erlaubt, mehr als 4 GB Speicher zu verwenden. Die Schnittstelle wird von allen Windows-Versionen ab 2000 unterstützt. Die an Exchange Server beteiligten Prozesse verwenden diese Schnittstelle allerdings nicht und müssen deshalb mit einem Adressraum von 4 GB auskommen.

Die 64-Bit-Versionen von Windows unterstützen weder AWE noch PAE, da sie diese Technologien nicht benötigen.

PAE und DEP

Im Bestreben, Virenautoren das Leben schwer zu machen, haben die Prozessordesigner eine Technologie ersonnen, die es möglich macht, für bestimmte Speichersegmente festzulegen, ob in ihnen ausführbarer Code oder nur reine Daten stehen können. Auf diese Weise sollen Sicherheitslücken durch Pufferüberläufe vermieden werden, die in der Regel in reinen Datensegmenten entstehen. Diese Technologie heißt Data Execution Prevention (DEP) bzw. Datenausführungsverhinderung auf deutschen Systemen. DEP ist in Windows ab Windows XP SP2 und Windows 2003 SP1 integriert. Die Unterstützung von DEP ist in Windows zwingend mit der PAE-Unterstützung verbunden. Der Schalter /NOEXECUTE, der in der Datei Boot.ini die DEP-Unterstützung steuert, aktiviert deshalb auch gleichzeitig PAE. Dies gilt selbst dann, wenn gleichzeitig der /NOPAE-Schalter übergeben wird. Zudem überprüft Windows während des Systemstarts die DEPFähigkeit des installierten Prozessors. Falls das System DEP hardwareseitig unterstützt und keine explizite Festlegung über den /NOEXECUTESchalter getroffen wurde, dann wird /NOEXECUTE= OPTIN angenommen und damit auch PAE aktiviert. PAE wird zudem automatisch aktiviert, wenn ein Server über Hot-Add-RAM-Fähigkeiten verfügt.

PAE und Exchange

Die PAE-Unterstützung bewirkt an sich noch nichts Negatives. Aus Gründen der Systemsicherheit ist sie im Zusammenhang mit DEP sogar zu begrüßen. Problematisch wird es, wenn das System tatsächlich über mehr als 4 GB physischen Speicher verfügt. In diesem Fall muss es zusätzliche Informationen speichern, um die erweiterten Daten korrekt adressieren zu können. Dies führt zu einem erhöhten Bedarf an Kernelspeicher.

Die Praxis hat ergeben, dass Exchange kaum einen Leistungsgewinn durch das Vergrößern des Hauptspeichers über 4 GB erzielt, da die einzelnen Prozesse nur 4 GB Adressraum besitzen. Ganz im Gegenteil: Durch den erhöhten Verwaltungsaufwand, den PAE und Hot Add Memory verursachen, wird schneller eine Speicherfragmentierung im Kernelspeicher erreicht. Diese führt dann zu Leistungsproblemen des Servers. Durch Weglassen des /3GB-Schalters auf Postfach-Servern ließe sich zwar der Kernelspeicher für die Prozesse vergrößern, damit würde aber gleichzeitig der Anwendungsspeicher reduziert, was wiederum die Leistung des Postfachspeichers beeinträchtigen würde.

Es wird deshalb empfohlen, auf Servern nicht mehr als 4 GB Hauptspeicher zu verwenden. Mehr vorhandener Speicher sollte aus dem Server entfernt werden. Ersatzweise kann Windows durch Verwendung des Schalters /MAXMEM=4096 in der Datei Boot.ini von der Verwendung des zusätzlichen Speichers abgehalten werden. Dadurch werden keine zusätzlichen Systemressourcen für die Verwaltung des Zusatzspeichers eingesetzt.

Die Verwendung einer Hot Add RAM-Funktion der Serverhardware, also der Möglichkeit, den Speicher im laufenden Betrieb zu erweitern, hat einen vergleichbaren Effekt. Hier muss Windows damit rechnen, zur Laufzeit mehr als 4 GB Hauptspeicher zur Verfügung zu haben. Das System wird deshalb von Anfang an so arbeiten, als wäre dies bereits der Fall. Für Systeme vor Windows 2003 SP1 sollte deshalb die Hot Add RAM-Unterstützung im BIOS abgeschaltet werden. Mit Windows 2003 SP1 kann die Funktion auch innerhalb des Betriebssystems deaktiviert werden. Vor SP1 funktionierte dies durch einen Systemfehler noch nicht richtig. Zur Deaktivierung muss in der Registry unter HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management der DWORD-Eintrag DynamicMemory auf den Wert 1 gesetzt werden.

Netzwerkverbindungen

Für den Verbrauch von Kernelspeicher auf Netzwerkservern stellen die verbundenen Clients einen entscheidenden Faktor dar. Für jeden verbundenen Client muss der Server die Zugangsrechte des Clients in Form eines Client Access Token für die Dauer der Verbindung speichern. Diese Token werden im Kernelspeicher abgelegt. Jedes Token enthält dabei neben dem Hash des Benutzerkennworts auch sämtliche Gruppenzugehörigkeiten des Kontos in der betreffenden Domäne. Dies bedeutet, dass wenn in einer Umgebung die Benutzer vielen Gruppen zugeordnet werden, die Länge der Token zunimmt. Dies wirkt sich umso mehr aus, da die Länge der Token nicht fließend zunimmt, sondern sich schrittweise erhöht. Die Größe eines Tokens beträgt deshalb entweder 4 KByte, 8 KByte, 12 KByte und so weiter.

Allerdings sind die Gruppenzugehörigkeiten, die sich ein Server merkt, nur diejenigen, die aus der eigenen Domäne stammen. Eine Möglichkeit, die Größe der Token zu reduzieren, besteht deshalb darin, die Postfach-Server und die Clients in verschiedenen Domänen zu installieren.

Ein Umstand, der bei der Betrachtung von Netzwerkverbindungen eines Servers nicht außer Acht gelassen werden sollte, ist die Anzahl der Verbindungen eines einzelnen Clients. Outlook 2003 allein baut im Cached-Modus fünf bis sechs parallele Verbindungen auf. Für jede dieser Verbindungen speichert der Server ein eigenes Access Token im Kernelspeicher. Zusatzprogramme wie Messenger, Desktop- Suchprogramme oder sonstige Outlook-Add-Ins bauen eventuell zusätzlich eigene Verbindungen auf, die wiederum Kernelspeicher verbrauchen. Eine Kontrolle der parallel laufenden Client-Programme kann deshalb ebenfalls die Kernelspeicher-Belastung reduzieren.

Leistungsmessung des Kernelspeichers

Bei den verschiedenen dargestellten Einstellungen zur Reduzierung des Kernelspeichers handelt es sich jeweils nur um Empfehlungen. Grundsätzlich kann Exchange mit oder ohne PAE, 4-GB-Limit und Hot Add Memory betrieben werden. Genauso können auch beliebig viele Zusatzanwendungen von den Benutzern oder Gruppenzuordnungen verwendet werden, die zusätzlichen Kernelspeicher auf dem Server in Anspruch nehmen. In diesem Fall muss aber in Kauf genommen werden, dass weniger Benutzer pro Server zugeordnet werden können.

Allgemein empfiehlt es sich bei Servern, die an der Lastgrenze betrieben werden, die Kernelspeicher-Auslastung im Auge zu behalten. Dies gilt besonders dann, wenn sich Symptome einer Speicherfragmentierung zeigen. Sie können sich in einem schlechten Antwortverhalten des Systems und abgebrochenen oder verweigerten Netzwerkverbindungen äußern. Zudem treten in diesem Fall Systemeinträge im Ereignisprotokoll mit den IDs 2019 und 2022 auf.

Die Messung der Kernelspeicher-Belastung kann mit der Windows-eigenen Leistungsprotokollierung (Systemsteuerung/Verwaltung/Leistung) durchgeführt werden. Wichtige Indikatoren sind Freie Seitentabelleneinträge, Auslagerungsseiten (Bytes)und Nicht-Auslagerungsseiten (Bytes). Seitentabelleneinträge (System Page Table Entries; PTE) zeigen an, welche Speichersegmente sich derzeit im physischen Hauptspeicher und welche sich in der Auslagerungsdatei befinden. Auslagerungsseiten (Paged Pool) geben den Anteil des Kernelspeichers an, der für die Speicherung in der Auslagerungsdatei geeignet ist. Nichtauslagerungsseiten (Nonpaged Pool) sind dementsprechend die Kerneldaten, die so lebenswichtig für das System sind, dass sie in jedem Fall im physischen Hauptspeicher verbleiben müssen. Die zugehörigen Werte hängen von der Verwendung der Schalter /3GB und /USERVA in der Datei Boot.ini ab. Die Richtwerte finden sich in Tabelle 1.

	Auslagerungsseiten	Nichtauslagerungsseiten	Seitentabelleneinträge
Standard bei 2 GB Kernelspeicher)	356 MB	256 MB	300000
Standard mit /3 GB /USERVA=3030	245 MB	128 MB	24000
Warnung/Kritisch bei 2 GB Kernelspeicher	>320 MB >200 MB belegt	>200 MB >220 MB belegt	<8000 / <5000 frei
Warnung/Kritisch mit /3GB /USERVA=3030	>200 MB >220 MB belegt	>100 MB >110 MB belegt	<8000 / <5000 frei

Messung des Anwendungsspeichers

Auch wenn die Wahrscheinlichkeit, dass der Kernelspeicher Probleme bereitet, in der Regel höher ist, kann manchmal auch der Anwendungsspeicher knapp werden. Dies passiert beispielsweise dann, wenn der /3GB-Schalter auf Postfach-Servern nicht gesetzt ist. Der Verbrauch an Anwendungsspeicher lässt sich ebenfalls über eine Leistungsprotokollierung beobachten. Als Indikator kann zum einen Speicher/Verfügbare MB verwendet werden. Dieser Wert sollte zu jeder Zeit mehr als 50 MB betragen. Speicher/Seiten/ s gibt außerdem Aufschluss darüber, inwieweit häufig genutzter Speicher in die Auslagerungsdatei geschrieben werden muss. Der zugehörige Wert sollte 1000 nicht überschreiten.

Anwendungsspeicher lässt sich vor allem durch Deinstallation oder Deaktivierung nicht benötigter Programme und Prozesse sparen. Zudem sollte sichergestellt werden, dass Wartugngsprozesse nur zu Zeiten geringer Systembelastung, also nachts oder am Wochenende ausgeführt werden.

Zusammenfassung

Jedem Windows-Programm steht ein virtueller Speicher von 4 GB zur Verfügung. Dieser verteilt sich in Anwendungs- und Kernelspeicher im Verhältnis 2 GB zu 2 GB. Durch eine Systemeinstellung kann dieses Verhältnis in 3 GB zu 1 GB geändert werden, was für Exchange-Postfach-Server mit mehr als 1 GB Speicherausbau empfohlen wird. Einem Programm kann entweder Anwendungspeicher oder Kernelspeicher ausgehen.

Der in Anspruch genommene virtuelle Speicher der Programme wird vom Betriebssystem auf den physischen Hauptspeicher und ein oder mehrere Auslagerungsdateien verteilt. Der Hauptspeicher kann nur mit Zusatztechnologien wie PAE mehr als 4 GB pro Prozessor betragen. Exchange Server profitiert aber kaum von einem Speicherausbau jenseits der 4-GB-Marke. Durch den zusätzlichen Verwaltungsaufwand von PAE, falls mehr als 4 GB Hauptspeicher vorhanden sind, kann es sogar zu Leistungseinbußen kommen. Allgemein ist ein Systemausbau über 4 GB pro Prozessor deshalb nicht zu empfehlen. Dies betrifft auch den Einsatz von Hot Add RAM.

Kernelspeicher enthält verschiedene Daten des Betriebssystems. Bei Exchange-Servern wird der Kernelspeicher vor allem durch Netzwerkverbindungen verbraucht. Bei auftretenden Leistungsproblemen und Systemfehlern empfiehlt es sich, den Speicherverbrauch über die Leistungsprotokolle zu analysieren.