Ausschließen von Arbeitsspeicherproblemen
Letztes Änderungsdatum des Themas: 2006-07-25
Exchange Server nutzt, was beabsichtigt ist, in großem Umfang Arbeitsspeicher und kann bis zu 3 GB physischen Arbeitsspeicher belegen. Auf einem Produktionsserver belegt der Prozess Store.exe häufig 1,5 GB virtuellen Speicher, da dieser Prozess mit großen Speichercaches arbeitet.
Zusätzlich zur Arbeitsspeichernutzung durch diverse Prozesse innerhalb von Exchange belegt auch der Exchange-Kerneltreiber ExIFS Kernelspeicher. Wenngleich weniger spürbar, verursacht eine hohe Auslastung des Kernelspeichers eine weit reichende Leistungsverschlechterung und Instabilität.
Untersuchen des Benutzerspeichers
Sobald der Server Arbeitsspeicher belegt und freier Arbeitsspeicher knapp wird, beginnt das Betriebssystem mit dem Verkleinern der Arbeitsseite des Prozesses und einer stärkeren Nutzung der Auslagerungsdatei. Die Nutzung der Auslagerungsdatei wirkt sich auf die Systemleistung aus, da Datenträgervorgänge länger als Arbeitsspeichervorgänge dauern.
Wenn darüber hinaus die Datenauslagerung zwischen Auslagerungsdatei und Datenträger einen gewissen Grad erreicht, kommt es zu einem Datenträgerengpass und Leistungseinbußen. In diesem Fall ist der Arbeitsspeicher das eigentliche Problem und der Datenträgerengpass nur eine Folge.
Bestimmen Sie anhand der Leistungsindikatoren in der folgenden Tabelle den aktuellen Status des Benutzerspeichers.
Leistungsindikatoren für den Benutzerspeicher
| Leistungsindikator | Erwartete Werte |
|---|---|
Speicher\Verfügbare MB Zeigt die Größe des physikalischen Speichers (in MB) an, der einem Prozess oder für die Verwendung durch das System unmittelbar zur Verfügung steht. Dies ist gleich der Summe des Speichers, der Standby- (zwischengespeicherten), freien und Nullseitenlisten zugewiesen ist. |
|
Speicher\Seiten/s Gibt die Rate an, mit der Seiten vom Datenträger gelesen bzw. auf den Datenträger geschrieben werden, um schwere Seitenfehler zu beheben. Dieser Leistungsindikator ist hauptsächlich für das Anzeigen von Fehlern zuständig, die das ganze System verlangsamen. Dies umfasst Seiten, die zum Beheben von Seitenfehlern im Dateisystemcache abgerufen werden. Diese Seiten werden normalerweise von Anwendungen angefordert. |
|
Verbessern des Benutzerspeichers
Die folgende Liste beschreibt, wie Sie die Leistung des Benutzerspeichers verbessern können:
- Entfernen überflüssiger Software
Um Ressourcen für Exchange freizugeben, entfernen Sie vom Server Softwaretools von Drittanbietern, die der Remoteüberwachung dienen oder sonstige unwesentliche Dienste leisten. Mithilfe der Leistungskonsole können Sie ermitteln, wie viel Arbeitsspeicher jede Anwendung belegt. - Ausführen von Wartungsaufgaben außerhalb der Spitzenzeiten
Durch das Ausführen von Wartungstools (z. B. eseutil) oder von Aufgaben (z. B. Postfachverwaltung) während der Spitzenzeiten kann Arbeitsspeicher belegt werden, der ggf. von Exchange benötigt wird. Es empfiehlt sich, diese Tools und Aufgaben außerhalb der Spitzenzeiten oder in Zeiträumen mit geringer Auslastung (z. B. am Wochenende) auszuführen.
Untersuchen der Belegung des Kernelspeichers
Der Windows-Kernelspeicher, der aus mehreren Speicherstrukturen besteht, die vom Kernel (dem Kernbetriebssystem) verwendet werden, ist ein weiterer Bereich, der zur Gewährleistung einer stabilen Exchange Server-Bereitstellung überwacht werden muss. In diesem Abschnitt werden die Überwachung und Problembehandlung der Kernelspeicherstrukturen beschrieben, welche die Leistung und Zuverlässigkeit des Servers mit Exchange beeinflussen.
Auf Servern mit Exchange müssen drei wichtige Kernelspeicherstrukturen überwacht werden:
- Ausgelagerter Pool Der ausgelagerte Poolspeicher ist der Teil des gemeinsam genutzten Systemspeichers, der in die Auslagerungsdatei auf dem Datenträger ausgelagert werden kann. Der ausgelagerte Poolspeicher wird bei der Systeminitialisierung erstellt und von Kernelmoduskomponenten zum Zuordnen von Systemspeicher verwendet.
- Nicht ausgelagerter Pool Der nicht ausgelagerte Poolspeicher besteht aus virtuellen Systemadressen, die stets im physischen Arbeitsspeicher vorhanden sind und auf die deshalb aus jedem Adressraum ohne anfallende E/A-Vorgänge in die Auslagerungsdatei zugegriffen werden kann. Wie der ausgelagerte Poolspeicher wird der nicht ausgelagerte Poolspeicher bei der Systeminitialisierung erstellt und von Kernelmoduskomponenten zum Zuordnen von Systemspeicher verwendet.
- System-PTEs Die virtuellen Speicheradressen der Auslagerungsdatei werden physischen Speicheradressen mithilfe einer Seitentabelle zugeordnet. Microsoft Exchange Server 2003 verwendet einen Pool von System-PTEs (Page Table Entries, Seitentabelleneinträgen), um Systemseiten, z. B. E/A-Bereiche, Kernelstapel und Speicherbeschreibungslisten, zuzuordnen.
Einstellungen in der Datei "Boot.ini" beeinflussen die Größe von Kernelspeicherbereichen
Die Höchstgröße der Kernelspeicherbereiche auf einem Server mit Exchange kann durch Einstellungen in der Microsoft Windows Server™ 2003-Datei boot.ini beeinflusst werden. Wenn Sie beispielsweise den Parameter /3GB in der Datei boot.ini angeben, werden dem Benutzermodusprozess 3 GB virtueller Adressraum und dem Betriebssystem nur 1 GB virtueller Adressraum zugewiesen.
Weitere Informationen zum Parameter /3GB finden Sie in den folgenden Microsoft Knowledge Base-Artikeln:
- 823440, "Sie müssen die Startoption "/3GB" verwenden, wenn Sie Exchange Server 2003 auf einem Windows Server 2003-System installieren" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=823440)
- 316739, "Verwenden der /userva-Option zusammen mit der /3 GB-Option zum Optimieren des Benutzermodusspeichers auf einem Wert zwischen 2 GB und 3 GB" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)
Die folgende Tabelle zeigt, wie sich der ungefähre Höchstwert jedes Kernelspeicherbereichs auf einem Server mit Exchange je nach Einstellung in der Datei boot.ini ändert. In diesem Beispiel wird Exchange Server 2003 auf einem Server mit mehreren Prozessoren und Windows Server 2003 mit vier GB Arbeitsspeicher (RAM) ausgeführt.
"Boot.ini"-Einstellungen und maximale Größen des Kernelspeicherbereichs
| Kernelspeicherbereich | Maximale Größe bei standardmäßigen "Boot.ini"-Optionen | Maximale Größe bei den "Boot.ini"-Optionen "/3GB" und "/USERVA = 3030" |
|---|---|---|
Ausgelagerter Poolspeicher |
356 MB |
245 MB |
Nicht ausgelagerter Poolspeicher |
256 MB |
128 MB |
System-PTEs |
300.000 verfügbare Seitentabelleneinträge |
24.000 verfügbare Seitentabelleneinträge |
Die folgende Tabelle zeigt Warneinstellungen des Systemmonitors für Exchange Server auf einem Server mit vier GB Arbeitsspeicher und Windows Server 2003. Auf der Stufe "Warnung" arbeitet der Server stabil, doch sollten Speicherzuordnungen auf mögliche Speicherlecks (durch die Nichtfreigabe von Arbeitsspeicher) untersucht werden. Auf der Stufe "Kritisch" kann der Server instabil werden, insbesondere bei Belastungsspitzen.
Systemmonitor-Warneinstellungen bei unterschiedlichen Einstellungen in der Datei "Boot.ini"
| Kernelspeicherbereich | Leistungsindikator im Systemmonitor | Systemmonitor-Auslöser bei Standardoptionen für "Boot.ini" | Systemmonitor-Auslöser bei den "Boot.ini"-Optionen "/3GB" und "/USERVA = 3030" |
|---|---|---|---|
Ausgelagerter Poolspeicher |
Speicher\Auslagerungsseiten (Bytes) |
|
|
Nicht ausgelagerter Poolspeicher |
Speicher\Nicht-Auslagerungsseiten (Bytes) |
|
|
System-PTEs |
Speicher\Freie Seitentabelleneinträge * |
|
|
* Der Leistungsindikator im Systemmonitor Speicher\Freie Seitentabelleneinträge ist bei Installationen von Windows Server 2003 ohne Service Pack 1 ungenau. Weitere Informationen zu diesem Leistungsindikator finden Sie im Microsoft Knowledge Base-Artikel 894067, "In dem Leistungsüberwachungstool werden unter Windows Server 2003 die verfügbaren freien Seitentabelleneinträge nicht genau angezeigt" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=894067).
Symptome der Erschöpfung des Kernelspeichers auf Servern mit Exchange
Die Symptome der Erschöpfung des Kernelspeichers auf Servern mit Exchange reichen von langsamen Antworten bis hin zu einem vollständigen Ausfall.
Symptome der Erschöpfung des Kernelspeichers auf Servern mit Exchange
| Kernelspeicherbereich | Erschöpfungssymptome |
|---|---|
Ausgelagerter Poolspeicher |
|
Nicht ausgelagerter Poolspeicher |
|
System-PTEs |
|
Behandeln von Problemen mit dem Kernelspeicher auf Servern mit Exchange
Wenn die Leistungsindikatoren im Systemmonitor zum Kernelspeicher in der vorherigen Tabelle "Systemmonitor-Warneinstellungen für unterschiedliche Einstellungen in der Datei Boot.ini" nicht den empfohlenen Werten entsprechen und/oder die in der Tabelle "Symptome der Erschöpfung des Kernelspeichers auf Servern mit Exchange" angegebenen Symptome auftreten, befolgen Sie den folgenden Problembehandlungsansatz, um die Ursache der Erschöpfung des Kernelspeichers zu ermitteln.
- Führen Sie das Tool Microsoft Exchange Server Best Practices Analyzer aus, um zu bestimmen, ob der Server mit Exchange ordnungsgemäß konfiguriert ist.
Es gibt verschiedene Konfigurationseinstellungen, welche die Kernelspeicherbereiche von Exchange Server beeinflussen (z. B. die Einstellungen /3GB und /Userva in der Datei boot.ini, der Registrierungsschlüssel SystemPages u. a.). Vor dem Untersuchen der Erschöpfungssymptome beim Kernelspeicher müssen Sie sicherstellen, dass der Kernelspeicher des Servers ordnungsgemäß konfiguriert ist. Führen Sie das Tool Microsoft Exchange Server Best Practices Analyzer aus, um sicherzustellen, dass die Serverkonfiguration ordnungsgemäß ist. Weitere Informationen über das Tool finden Sie unter "Exchange Server Best Practices Analyzer" im Microsoft Download Center. - Ermitteln Sie, welcher Kernelspeicherbereich erschöpft ist.
- Analysieren Sie Ereignisse Untersuchen Sie die Protokolle der Ereignisanzeige auf die Ereignis-IDs 2019 und 2020 zu Fehlern beim Reservieren von (Nicht-) Auslagerungspoolspeicher.
- Analysieren Sie die Leistung Erstellen Sie mithilfe von Systemmonitor ein Protokoll des ausgelagerten und nicht ausgelagerten Poolspeichers sowie der freien System-PTEs, wobei Stichproben alle 60 Sekunden über einen Zeitraum von 24 Stunden genommen werden. Vergleichen Sie die Ergebnisse der Systemmonitorprotokolle mit den Auslösern für "Warnung" und "Kritisch" in der vorherigen Tabelle, "Systemmonitor-Warneinstellungen für unterschiedliche Einstellungen in der Datei Boot.ini".
Wenn Sie die Protokolle von Ereignisanzeige und Systemmonitor anhand der drei vorherigen Tabellen analysieren, sollte der erschöpfte Kernelspeicherbereich schnell zu erkennen sein.
- Ermitteln Sie, warum der Kernelspeicherbereich erschöpft ist.
Bestimmen Sie, welche Tags im ausgelagerten und/oder nicht ausgelagerten Poolspeicher die Speichererschöpfung verursachen.
Das Betriebssystem verwendet Tags, um Zuordnungen von ausgelagertem und nicht ausgelagertem Poolkernelspeicher nachzuverfolgen. Unter Windows Server 2003 erfolgt dies standardmäßig. Microsoft Windows 2000 Server verwendet das Dienstprogramm gflags.exe (Global Flags Editor), um die Erstellung von Pooltags zu aktivieren. Detaillierte Informationen zu Flags beim Behandeln von Arbeitsspeicherproblemen finden Sie im Microsoft Knowledge Base-Artikel 177415, "Verwendung der Überwachung des Speicherpools ("Poolmon.exe") bei Speicherfehlern im Kernelmodus" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=177415) und im Knowledge Base-Artikel 298102 mit Informationen zum Suchen von Pooltags, die von Treibern von Drittanbietern verwendet werden (https://go.microsoft.com/fwlink/?linkid=3052&kbid=298102).
Führen Sie poolmon.exe (Memory Pool Monitor) oder das Arbeitsspeicherprofil-Tool MemSnap (memsnap.exe mit dem Parameter /p) aus, um die Tags in eine Datei auszugeben. Ermitteln Sie anschließend, welches Tag den meisten ausgelagerten bzw. nicht ausgelagerten Poolspeicher belegt. Das Ausführen des Arbeitsspeicherprofil-Tools MemSnap in regelmäßigen Abständen dient dem Isolieren von Speicherlecks und liefert einen Hinweis, wie sich Speicherzuordnungen mit der Zeit ändern. Weitere Informationen zum Arbeitsspeicherprofil-Tool MemSnap finden Sie unter "Memsnap Overview" in (https://go.microsoft.com/fwlink/?LinkId=50167).Beispiel eines MemSnap-Arbeitsspeichersnapshots
Tagtyp Allocs Frees Diff Bytes Per Alloc AGP Nonp
1
0
1
344
344
AGP Paged
7
5
2
384
192
AcdN Nonp
2
0
2
1,072
536
AcpA Nonp
39
36
3
192
64
AcpA Paged
1
0
1
504
504
AcpB Paged
42
38
4
576
144
AcpD Nonp
315
170
45
15,080
335
AcpF Nonp
493
485
8
320
40
Untersuchen Sie in dem in der vorherigen Tabelle gezeigten Beispiel die Spalte "Bytes", um das Tag zu isolieren, das den meisten Speicher belegt. In diesem Beispiel ist dies "AcpD Nonp". Anhand der Spalten "Allocs" und "Frees" können Sie potenzielle Speicherlecks nachverfolgen. Die Werte für "Allocs" und "Frees", die um einen großen Betrag voneinander abweichen, können ein Zeichen eines potenziellen Speicherlecks sein.
Gleichen Sie die Tags für ausgelagerten und nicht ausgelagerten Poolspeicher mit der Anwendung oder dem Treiber ab. Gleichen Sie mithilfe der folgenden Ressourcen das betreffenden Tag mit der aufrufenden Anwendung oder dem aufrufenden Treiber ab:
Laden Sie die Microsoft Debugging Tools für Windows (https://go.microsoft.com/fwlink/?LinkId=50168) herunter, und installieren Sie sie. Bei der Installation wird pooltag.txt im Verzeichnis %program files%\Debugging Tools for Windows\triage abgelegt, wodurch Sie eine Zuordnung der Microsoft-Anwendungen oder -Treiber zu den dazugehörigen Tags erhalten. Beispiel:
Ntf? – ntfs.sys – NTFS-spezifische Zuordnungstags
Ntf0 – ntfs.sys – Allgemeine Poolzuordnung
Ntf9 – ntfs.sys – Großer temporärer Puffer
Weitere Informationen zu Tags finden Sie im Microsoft Knowledge Base-Artikel 298102 mit Informationen zum Suchen von Pooltags, die von Treibern von Drittanbietern verwendet werden (https://go.microsoft.com/fwlink/?linkid=3052&kbid=298102).
Führen Sie bei Tagzuordnungslecks Korrekturmaßnahmen aus:
Wenden Sie sich an den Microsoft Software Service, wenn das das Leck verursachende Tag eine Anwendung oder ein Treiber ist, die/der von Microsoft entwickelt wurde (entsprechend der Angabe in der zuvor genannten Datei pooltag.txt).
Wenden Sie sich an die Supportservices des Drittanbieters, wenn das das Leck verursachende Tag eine Anwendung oder ein Treiber ist, die/der von einem Drittanbieter entwickelt wurde.
Deaktivieren oder deinstallieren Sie, falls möglich, die fehlerhaften Anwendungen und/oder Treiber, um die Systemstabilität zu sichern, bis das Speicherleck beseitigt wurde.Ergreifen Sie Korrekturmaßnahmen bei Tags mit hohen Arbeitsspeicherzuordnungen, bei denen es keine Anzeichen von Speicherlecks gibt.
Es gibt Fälle, bei denen Tags für ausgelagerten bzw. nicht ausgelagerten Poolspeicher beträchtliche Mengen von Kernelspeicher belegen (ca. 10 MB pro Tag für nicht ausgelagerten und 40 MB pro Tag für ausgelagerten Poolspeicher), die Tags jedoch keine Speicherlecks verursachen. Im Allgemeinen treten diese Fälle beim vertikalen Skalieren eines Exchange-Postfachservers auf mindestens 4000 Postfächer oder bei Nachrichtenübermittlungswarteschlangen mit mehr als 10.000 Nachrichten auf.
Es folgen spezifische Fälle einer hohen Arbeitsspeicherauslastung basierend auf der Tagzuordnung:
TOKE-Tag für ausgelagerten Poolspeicher Dieses Tag wird von Windows zum Zwischenspeichern von Sicherheitsinformationen zu jeder auf dem Server geöffneten Benutzersitzung verwendet. Ein Token (für das mit dem TOKE-Tag für ausgelagerten Poolspeicher Arbeitsspeicher zugewiesen wird) wird beispielsweise für jede Benutzersitzung erstellt, die von einem E-Mail-Client wie Microsoft Office Outlook generiert wird. Je nach Client können mehrere Sitzungen für jeden E-Mail-Client geöffnet werden, was bewirkt, dass mehrere Token für jeden Client auf dem Server zwischengespeichert werden. Die Größe des ausgelagerten Poolspeichers für jedes Token basiert im Allgemeinen auf der Anzahl der Sicherheitsgruppen, denen der Benutzer angehört. Je mehr Sicherheitsgruppen ein Benutzer angehört, desto mehr ausgelagerter Poolspeicher wird von den Token belegt, die zu den Sitzungen dieses Benutzers gehören.
In der MemSnap-Ausgabe in der folgenden Tabelle beträgt die durchschnittliche Tokengröße ca. 3 KB.Beispiel eines MemSnap-Arbeitsspeichersnapshots
Tagtyp Allocs Frees Diff Bytes Per Alloc Toke Paged
4,856,027
4,855,591
436
12,093,848
2,967
Führen Sie die folgenden Schritte aus, um die Erschöpfung des ausgelagerten Poolspeichers zu beseitigen, die hauptsächlich durch das TOKE-Tag verursacht wird:
Wenn die Größe des ausgelagerten Poolspeichers pro Token (TOKE per Alloc) größer als 8 KB ist:
• Verringern Sie die Anzahl der Sicherheitsgruppen in der Organisation.
• Führen Sie Sicherheitsgruppen zusammen, und entfernen Sie tiefe Schachtelungen.
Wenn die Größe des ausgelagerten Poolspeichers pro Token (TOKE per Alloc) kleiner als 8 KB ist:
• Wenn die Erschöpfung des ausgelagerten Poolspeichers auf einem Postfachserver auftritt, verringern Sie die Anzahl der Postfächer auf dem Server, und/oder heben Sie die Öffentliche Ordner-Funktion des Postfachservers auf.
• Wenn die Erschöpfung des ausgelagerten Poolspeichers auf einem Server für Öffentliche Ordner auftritt, verringern Sie die Anzahl der Postfachspeicher, die den Server für Öffentliche Ordner als standardmäßigen öffentlichen Informationsspeicher verwenden. Dadurch verringert sich die Anzahl der Clients (und demzufolge die Anzahl der Benutzersitzungen) auf dem Server für Öffentliche Ordner.
• Wenn die gemeinsame Nutzung von Kalendern in Outlook häufig vorkommt, stellen Sie sicher, dass auf allen Clients Outlook 2003 oder höher ausgeführt wird. Die gemeinsame Nutzung von Kalendern sorgt für eine zusätzliche Tokenbelastung auf dem Server, da zusätzliche Benutzersitzungen erstellt werden. Outlook 2003 führt diese Aufgabe effizienter (mit weniger Sitzungen) als frühere Versionen durch.
MMST-Tag für ausgelagerten Poolspeicher Der Windows Cache-Manager verwendet dieses Tag für die Dateizwischenspeicherung. Der Windows Cache-Manager verringert automatisch die Dateizwischenspeicherung, um ausgelagerten Poolspeicher freizugeben, wenn der Pool erschöpft ist. Wenn das Tool Exchange Best Practices Analyzer keine Warnungen oder Fehler zur SMTP-Konfiguration meldet, sind keine Korrekturmaßnahmen erforderlich. Nicht standard- oder ordnungsgemäße SMTP-Einstellungen können den Windows Cache-Manager zusätzlich belasten, was zur Belegung von mehr ausgelagertem Poolspeicher führen kann.
Wenden Sie sich an den Microsoft Software Service, wenn Symptome für eine Erschöpfung des ausgelagerten Poolspeichers und/oder Ereignisse in Verbindung mit dem MMST-Tag für ausgelagerten Poolspeicher auftreten.
Tags für nicht ausgelagerten Poolspeicher AUXL und FLST Diese Tags werden von exifs.sys verwendet, dem Kernelmodustreiber, mit dem der Exchange-Informationsspeichertreiber Elemente aus Messagingdatenbanken liest bzw. Elemente in diese Datenbanken schreibt.
Wenn eines dieser Tags der hauptsächliche Verursacher der Erschöpfung des ausgelagerten Poolspeichers ist, wenden Sie sich an den Microsoft Software Service.
IpSA-Tag für nicht ausgelagerten Poolspeicher IPSec.sys, der primäre Gerätetreiber für IPSec (IP Security), verwendet dieses Windows-Tag, um auf Sicherheitszuweisungen zuzugreifen, die sich im ausgelagerten Poolspeicher befinden. Mit der Verwendung von IPSec.sys auf Exchange-Server wird die Belastung des nicht ausgelagerten Poolspeichers erhöht. Wenn dieses Tag der primärer Verursacher einer Erschöpfung des nicht ausgelagerten Poolspeichers ist, ziehen Sie die folgenden Korrekturmaßnahmen in Betracht:
Wenn die Erschöpfung des nicht ausgelagerten Poolspeichers auf einem Postfachserver auftritt, verringern Sie die Anzahl der Postfächer auf dem Server, und/oder heben Sie die Öffentliche Ordner-Funktion des Postfachservers auf.
Wenn die Erschöpfung des nicht ausgelagerten Poolspeichers auf einem Server für Öffentliche Ordner auftritt, verringern Sie die Anzahl der Postfachspeicher, die den Server für Öffentliche Ordner als standardmäßigen öffentlichen Informationsspeicher verwenden. Auf diese Weise reduzieren Sie die Anzahl der Clients (und dementsprechend die Anzahl der Benutzersitzungen) auf dem Server für Öffentliche Ordner.Isolieren Sie die Ursachen der PTE-Erschöpfung, was nicht so einfach ist wie das Isolieren der Ursache der Erschöpfung des ausgelagerten oder nicht ausgelagerten Poolspeichers. Für die Überwachung der PTE-Belegung gibt es kein Tool wie MemSnap. Zur Beseitigung einer PTE-Erschöpfung können nur allgemeine Maßnahmen empfohlen werden.
PTE-Speicherlecks Eine PTE-Erschöpfung aufgrund eines Speicherlecks kann mithilfe von Systemmonitor isoliert werden (und zwar mithilfe der oben beschriebenen Leistungsindikatoren für freie System-PTEs). Ein PTE-Leck zeigt sich als kontinuierliche Verringerung des Werts des Systemmonitor-Leistungsindikators Speicher\Freie Seitentabelleneinträge über mehrere Tage. Wenden Sie sich in einem solchen Fall an den Microsoft Software Service.
PTE-Erschöpfung ohne Anzeichen von Speicherlecks Eine PTE-Erschöpfung kann auftreten, wenn kein PTE-Leck vorhanden ist. Im Allgemeinen treten diese Fälle beim vertikalen Skalieren eines Exchange-Postfachservers auf mindestens 4000 Postfächer oder durch die Belegung von PTEs durch Drittanbietertreiber auf. Über die folgenden Schritte können Sie die PTE-Erschöpfung beseitigen:
• Entfernen Sie unnötige Drittanbietertreiber.
• Verwenden Sie /BASEVIDEO oder einen generischen Grafiktreiber zum Freigeben von System-PTEs. Grafikkarten verwenden die System-PTEs zum Zuordnen ihrer Puffer im Kernelspeicher. Diese Verwendung steht im Konflikt mit dem Bedarf an System-PTEs von Microsoft Exchange.
• Verringern Sie die Einstellung /USERVA in der Datei boot.ini, um mehr verfügbare PTEs hinzuzufügen. Befolgen Sie dazu die Anweisungen im Microsoft Knowledge Base-Artikel 823440, "Sie müssen die Startoption "/3GB" verwenden, wenn Sie Exchange Server 2003 auf einem Windows Server 2003-System installieren" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=823440).
• Wenn die PTE-Erschöpfung auf einem Postfachserver auftritt, verringern Sie die Anzahl der Postfächer auf dem Server, und/oder heben Sie die Öffentliche Ordner-Funktion des Postfachservers auf.
• Wenn die PTE-Erschöpfung auf einem Server für Öffentliche Ordner auftritt, verringern Sie die Anzahl der Postfachspeicher, die den Server für Öffentliche Ordner als standardmäßigen öffentlichen Informationsspeicher verwenden. Dadurch verringert sich die Anzahl der Clients (und demzufolge die Anzahl der Benutzersitzungen) auf dem Server für Öffentliche Ordner.
Untersuchen des virtuellen Speichers des Exchange-Informationsspeichers
Jeder Prozess Store.exe auf einem Server kann nur eine begrenzte Speichermenge, die virtueller Speicher genannt wird, adressieren. Beim Anpassen des Servers an eine größere Anzahl von Benutzern und eine entsprechend höhere Auslastung verringert sich der zur Verfügung stehende virtuelle Speicher. Wenn ein Server bereits 4 GB Arbeitsspeicher (RAM) aufweist, kann dieser Arbeitsspeicher nicht mehr erweitert werden. Durch Hinzufügen von mehr physischem Arbeitsspeicher können keine Fehler behoben werden, die darauf hindeuten, dass der virtuelle Speicher erschöpft ist.
Wenn ein Server nur noch wenig virtuellen Speicher zur Verfügung hat, verschlechtert sich seine Leistung, da dadurch der Prozess Store.exe gezwungen wird, die Auslagerungsdatei zu verwenden, wobei Store.exe schnell mit dem Auslagern beginnt.
Bestimmen Sie anhand der Leistungsindikatoren in der folgenden Tabelle den aktuellen Status des virtuellen Speichers des Informationsspeichers.
Leistungsindikatoren für den virtuellen Speicher des Exchange-Informationsspeichers
| Leistungsindikator | Erwartete Werte |
|---|---|
MSExchangeIS\Max. Blockgröße des VS Zeigt die Größe (in Bytes) des größten freien virtuellen Speicherblocks an. Der Indikator wird als Linie dargestellt, die mit einer zunehmenden Belegung des virtuellen Speichers abfällt. Wenn dieser Leistungsindikator unter 32 MB fällt, verzeichnet Exchange 2003 im Ereignisprotokoll eine Warnmeldung (Ereignis-ID=9582). Bei einem Speicher mit einer Größe unter 16 MB wird eine Fehlermeldung protokolliert. |
|
MSExchangeIS\Gesamtanzahl von Bytes in 16 MB großen freien Blöcken im VS Zeigt die Gesamtanzahl freier virtueller Speicherblöcke mit einer Größe von mindestens 16 MB an. Dieser Indikator wird als Linie dargestellt, die möglicherweise zuerst ansteigt, dann jedoch bei zunehmend fragmentiertem Speicher abfällt. Es werden zuerst einige große virtuelle Speicherblöcke angezeigt und anschließend möglicherweise eine größere Anzahl einzelner kleinerer Speicherblöcke. Wenn die Speicherblöcke eine Größe unter 16 MB aufweisen, fällt die Linie ab. |
|
MSExchangeIS\Gesamtzahl freier Blöcke im VS Zeigt die Gesamtzahl freier virtueller Speicherblöcke unabhängig von deren Größe an. Dieser Indikator wird als Linie dargestellt, die möglicherweise zuerst ansteigt, dann jedoch unter Umständen abfällt, wenn der freie Arbeitsspeicher in kleinere Speicherblöcke fragmentiert wird und diese Speicherblöcke dann belegt sind. Mithilfe dieses Indikators kann der Grad der Fragmentierung des verfügbaren virtuellen Speichers ermittelt werden. Die durchschnittliche Blockgröße ergibt sich aus Prozess\Virtuelle Bytes\SPEICHER geteilt durch MSExchangeIS\Gesamtzahl freier Blöcke im VS. |
|
MSExchangeIS\Gesamtzahl von Bytes in freien großen Blöcken im VS Zeigt die Summe (in Bytes) aller virtuellen Speicherblöcke mit einer Größe von größer gleich 16 MB an. Der Indikator überwacht die Speicherfragmentierung des Informationsspeichers und wird als Linie dargestellt, die mit einer zunehmenden Belegung des virtuellen Speichers abfällt. Auf einem stabilen Server muss diese Linie oberhalb von 50 MB verbleiben. |
|
Der Prozess Store.exe verwendet auch eigene Heapzuordnungsmechanismen und -strukturen, die "Exchmem" genannt werden. Der Prozess Store.exe erstellt beim Systemstart mehrere Exchmem-Heaps und erhöht die Anzahl der Heaps nur dann, wenn die vorhandene Anzahl entweder vollständig genutzt wird oder bis zu einem Grad fragmentiert ist, bei dem für eine erfolgreiche Zuordnung nicht genügend zusammenhängender Arbeitsspeicher vorhanden ist.
Wenn ein Speicherbelegungsproblem oder eine interne Fragmentierung vorliegt (d. h. eine Fragmentierung innerhalb der Exchmem-Heaps, die sich innerhalb des virtuellen Speicherbereichs des Informationsspeichers befinden), erstellt der Prozess Store.exe neue Exchmem-Heaps.
Wenn der Prozess Store.exe wiederholt zusätzliche Heaps erstellen muss, kommt es zur Fragmentierung oder Erschöpfung des gesamten virtuellen Speichers des Informationsspeichers. Durch Überwachen der Leistungsindikatoren in der folgenden Tabelle können Sie bestimmen, ob Exchmem-Heaps die Ursache von Problemen oder einer Leistungsverschlechterung durch die Fragmentierung von Heaps sind.
Leistungsindikatoren für Exchmem-Heaps
| Leistungsindikator | Erwartete Werte |
|---|---|
MSExchangeIS\Exchmem: Anzahl von Heaps mit Speicherfehlern Gibt die Gesamtanzahl von Exchmem-Heaps an, die aufgrund von zu wenig verfügbarem Speicher nicht zugeordnet werden konnten. |
|
MSExchangeIS\Exchmem: Anzahl von Speicherfehlern Gibt die Gesamtanzahl von Exchmem-Zuweisungen an, die kein Speicher verfügbar war. |
|
MSExchangeIS\Exchmem: Anzahl zusätzlicher Heaps Gibt die Anzahl von Exchmem-Heaps an, die vom Informationsspeicher nach dem Start erstellt wurden. |
|
Verbessern des virtuellen Speichers des Exchange-Informationsspeichers
Nachfolgend wird beschrieben, wie Sie die Leistung des virtuellen Speichers des Exchange-Informationsspeichers verbessern können:
- Zusammenführen von Speichergruppen
Für jede Speichergruppe muss der Prozess Store.exe Strukturen zuweisen und Speicher belegen. Arbeiten Sie nach Möglichkeit mit der Mindestanzahl von Speichergruppen, welche die SLA erfüllt. Dies ist wesentlich bedeutsamer in Exchange 2000 als in Exchange 2003. In Exchange 2003 wurden wesentliche Änderungen durchgeführt, um die Zunahme der Größe des virtuellen Speichers pro zusätzlicher Speichergruppe zu verringern. Dies hat zur Folge, dass es sehr unwahrscheinlich ist, dass die Speichergruppen- oder Datenbankkonfiguration die Hauptursache einer Fragmentierung des virtuellen Speichers in Exchange Server 2003 ist. Weitere Informationen zum Konfigurieren von Speichergruppen in Exchange 2003 finden Sie im Microsoft Knowledge Base-Artikel 890699 mit Informationen zum Konfigurieren von Speichergruppen in Exchange Server 2003 (https://go.microsoft.com/fwlink/?linkid=3052&kbid=890699). - Verschieben von Serverfunktionen
Wenn die Speicherbelegung zunimmt, weil der Server mehrere Funktionen erfüllt (z. B. als Server für Öffentliche Ordner oder als Postfachserver), empfiehlt sich das Verschieben von Funktionen auf dedizierte Server. - Lesen des Microsoft Knowledge Base-Artikels 815372
Weitere Informationen über das Optimieren der Nutzung des virtuellen Speichers finden Sie im Microsoft Knowledge Base-Artikel 815372, "Optimieren der Speichernutzung in Exchange Server 2003" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=815372).