Folgende Frage wurde an mich herangetragen: “Immer wieder thematisiert: Vor- und Nachteile der eigenen Partition für die Auslagerungsdatei (Swap) unter Microsoft Windows. Administratoren diskutieren seit den Zeiten von Windows NT 4.0 über die Swap-Partition, die ja auch bei Unix/Linux gern eingerichtet wird. Ist die Einrichtung einer speziellen Swap-Partition jetzt eine Legende oder bringt es wirklich etwas?” Ergänzen kann man die Frage noch um die Diskussion der notwendigen Größe einer Auslagerungsdatei und ob man sie überhaupt benötigt, wenn man viel Arbeitsspeicher im System hat.

Vorneweg: DIE Antwort auf diese Frage werde ich hier nicht geben, aber hoffentlich ein paar wesentliche Gedanken zur eigenen Meinungsbildung.

Wenn man auf den Microsoft Support Seiten nach den Begriffen “pagefile large memory” sucht, findet man auf jeden Fall Berge von Treffern – an Lesestoff sollte also erst einmal kein Mangel sein. Aber zum Thema:

Wie jedes andere moderne Betriebssystem verwendet Windows eine virtuelle Speicherverwaltung. Der “scheinbar” verfügbare Arbeitsspeicher ist daher in der Regel merklich größer als der physisch in dem Rechner verbaute Speicher. Dazu lagert der Memory Manager bei Bedarf physische Speicherseiten aus dem Arbeitsspeicher auf die Platte aus, um den freigewordenen Speicher zur Erfüllung einer Anfrage nach Speicher zu verwenden. Wird der ausgelagerte Speicher von der entsprechenden Anwendung wieder benötigt, lagert das Betriebssystem diesen wieder ein und dafür bei Bedarf andere am längsten nicht benutzte Seiten wieder aus. Das ist der generelle bekannte Prozess. Auf der anderen Seite lagern moderne Memory Manager auch dann Speicherseiten in die Auslagerungsdatei aus, wenn noch gar kein Engpass besteht. Dies ist ein Hintergrundprozess, der dann läuft, wenn das System nicht ausgelastet ist. Die Leistungsfähigkeit des darunter liegenden (Festplatten) Speichers ist daher von untergeordneter Bedeutung. Sollte aber jetzt plötzlich Speicher benötigt werden, steht sehr schnell freier Speicher zur Verfügung, da er sowohl im RAM wie auch in der Auslagerungsdatei existiert und daher nur noch gelöscht (mit NULL beschrieben) werden muss.

Anders sieht es aus, wenn ein akuter Engpass besteht. Dann muss der Memory Manager die Speicherseiten suchen, die am ehesten ausgelagert werden können, diese in die Auslagerungsdatei schreiben, den Speicher löschen und dann der anfragenden Anwendung übergeben. Hier ist die Geschwindigkeit beim schreiben in die Auslagerungsdatei von entscheidender Bedeutung. Ähnliches gilt beim Einlagern – hier ist die Lesegeschwindigkeit entscheidend.

Ein grundlegender Artikel über die Zusammenhänge bietet KB2267427.

1. Frage: Braucht es überhaupt eine Auslagerungsdatei, wenn viel physischer Arbeitsspeicher im System vorhanden ist?

Einmal dient die Auslagerungsdatei als Erweiterung des installierten Arbeitsspeichers. Ist dort genügend vorhanden, bräuchte man im Prinzip keine Auslagerungsdatei. Server sollten auch so dimensioniert sein, dass das Auslagern möglichst vermieden wird oder aber eher sparsam vorkommt. Immerhin ist RAM in der Größenordnung von 800.000 Mal schneller als eine Festplatte. Aber die Auslagerungsdatei ist bei Windows auch notwendig, wenn man im Falle eines Systemabsturzes diesen analysieren will. Die Erstellung der Crash Dump Datei geht nur über die Auslagerungsdatei: KB254649. Je nach Art des benötigten Dump kann man daher die Auslagerungsdatei auch deutlich kleiner dimensionieren, als der installierte Arbeitsspeicher. Bei sehr großen Servern entspricht dies auch der empfohlenen Vorgehensweise.

2. Frage: Empfiehlt sich eine eigene Swap Partition?

Bei Unix/Linux Systemen ist “Swap” ein eigener Partitionstyp. Im Prinzip handelt es sich hier um ein Raw Device, das direkt vom Memory Manager verwaltet wird. Windows verwendet dagegen die bekannte Auslagerungsdatei. Die Datei “Pagefile.sys” entspricht dabei dem Raw Device. Da die Datei immer auf einer formatierten Partition liegt, ist es daher prinzipiell erst einmal egal, wo diese liegt. Eine eigene Partition definiert hierbei die maximale Größe, da sie nicht beliebig vergrößert oder verkleinert werden kann. Aus Performance Sicht betrachtet, ist der Overhead des Dateisystems auf jeden Fall zu berücksichtigen – eine eigene Partition bringt keine Vorteile. Vermieden wird aber eine mögliche Fragmentierung, da es eigentlich nur diese eine Datei gibt (etwas vereinfacht betrachtet). Auf der anderen Seite fällt abe einer Fragmentgröße von etwa 64MB die Fragmentierung nicht mehr wesentlich ins Gewicht, weswegen auch der Windows Defragmentierer nicht das Ziel hat, 0% Fragmentierung zu erreichen. Hintergrund: Der Aufwand der erneuten Positionierung der Leseköpfe im Verhältnis zu gesamt benötigten Lesezeit wird sehr klein und kann daher meist vernachlässigt werden.

3. Frage: Auf welcher Platte bringe ich die Auslagerungsdatei sinnvoll unter?

Bezogen auf die Ausführungen von oben, sollte die Notwendigkeit der Nutzung der Auslagerungsdatei, also der Vorgang des benötigten Auslagerns zur Befriedigung der Nachfrage nach Speicher für Anwendungen möglichst vermieden werden oder aber begrenzt werden. Kann dies durch eine entsprechende Auslegung des Servers erreicht werden, sieht die Auslagerungsdatei im wesentlichen nur Hintergrundaktivitäten, weswegen die Platzierung relativ egal wäre. Ansonsten muss man nicht die Frage nach der eigenen Partition, sondern (aus Performance Sicht) die der eigenen Spindeln stellen. Nur so optimieret man die Leistung der Auslagerungsdatei. Aber: Selbst dann ist die schnellste Platte etwa 800.000 Mal langsamer als der langsamste Arbeitsspeicher…

4. Frage: Lohnt es sich eine SSD für die Auslagerungsdatei zu verwenden?

Eine SSD ist sicherlich erheblich schneller als eine Festplatte. Wenn sie 100x so schnell wie die Festplatte wäre, wäre sie aber immer noch etwa 8.000 Mal langsamer als Arbeitsspeicher… Entsprechende Kapazitäten mit hoher Geschwindigkeit kosten aber auch relativ viel Geld – zumindest im Vergleich zur klassischen Festplatte. Arbeitsspeicher dürfte dann im Verhältnis wieder teurer als die SSD sein, aber auch erheblich schneller. Der Gewinn an Systemleistung bei ausreichendem Arbeitsspeicher dürfte aber über alles betrachtet immer noch die preiswerteste Lösung sein (Kosten / Nutzen).

5. Frage: Wann betrifft mich das Problem eigentlich?

Einfach gesagt: Immer dann, wenn der Server mehr Arbeitsspeicher sinnvoll verwenden könnte. Beispiel: Ein Virtualisierungshost erlaubt ein Memory Overcommit. Sobald die virtuellen Maschinen ihren Arbeitsspeicher benötigen, muss der Host anfangen, auszulagern. Gegebenenfalls wird dabei die virtuelle Maschine angehalten oder der Host verweigert temporär weitere Dienste. Dies ist im wesentlichen der Grund, warum Hyper-V mit “Dynamic Memory” kein Overcommit, sondern eine dynamische Balancierung des verfügbaren Arbeitsspeichers zwischen den virtuellen Maschinen anbietet. Andere Serveranwendungen zwingen das System gegebenenfalls indirekt zum Auslagern. Solange Speicher vorhanden ist, nutzen sie zur Arbeit (meist als Cache) was sie kriegen können. Laufen gleichzeitig andere Dienste, die irgendwann einmal plötzlich mehr Speicher benötigen, gibt es einen Engpass, weil die andere Anwendung nichts von “Ihrem” Speicher wieder frei gibt. Dann wird Windows gezwungen, die Auslagerungsdatei zu Hilfe zu nehmen… Deswegen ist es zum Beispiel nicht empfehlenswert, neben dem SQL Server oder Exchange noch andere Dienste auf dem gleichen Server zu betreiben.

Fazit oder wie macht man es vermutlich richtig?

Wichtig ist erst einmal die Arbeitslast der jeweiligen Rechner zu kennen und die Notwendigkeit der Auslagerung zu erkennen. Dazu sollte man wissen, dass Windows, wenn es nicht untersagt wird, immer auslagert, wie auch oben beschrieben. Um einen Überblick darüber zu bekommen, ob es sich um Hintergrundaktivitäten oder eine Notwendigkeit für den Betrieb handelt, kann man die Informationen der Artikels KB2267427 und KB2160852 und die dort angeführten Leistungsindikatoren zur Beurteilung heranziehen. Dazu sollte man wissen, dass es Unterschiede zwischen 32-Bit (ältere Server, KB2160852) und 64-Bit (ab Windows Server 2003 möglich, ab Windows Server 2008 R2 nur noch verfügbar, KB889654) gibt.

Als Grundregel sollte man erst einmal Windows die Kontrolle über die Auslagerungsdatei überlassen. Speziell bei sehr “großen” Servern kann dies aber nachteilig sein, siehe auch KB955635. Hier sollte man dann selbst die Konfiguration vornehmen. Üblicherweise wird daher die Auslagerungsdatei sehr viel kleiner werden, als der installierte Arbeitsspeicher. Man darf dabei aber nicht vergessen, dass dies Auswirkungen auf die Diagnosemöglichkeiten bei Systemabstürzen hat (KB254649).

Bei Virtualisierungshosts darf man nicht vergessen, dass auch die Hostpartition (das installierte Windows System) arbeiten muss. Wenn die virtuellen Maschinen den Host auslasten, kann daher die Parent Partition gezwungen sein, für den eigenen Bedarf auszulagern. Hier sollte dann die Kalkulation des Speicherbedarf des Host eine Grundlage für die Festlegung der Auslagerungsdatei liefern.

Am Ende bleibt noch zu bedenken, dass in der Auslagerungsdatei potentiell sensitive Daten lagern. Wer also den Host mittels Bitlocker schützt, muss auch darauf achten, dass die Partition mit der Auslagerungsdatei verschlüsselt ist. Die Option zum Löschen der Auslagerungsdatei hilft hier aus zwei Gründen nicht: Einmal verlangsamt sie jedes Herunterfahren (meist in nicht akzeptabler Weise), da die Auslagerungsdatei komplett mit NULL beschrieben wird und andererseits, weil das System ja auch nicht geordnet stehen bleiben kann, wobei die Auslagerungsdatei ihren vollständigen Inhalt behält.