Swap Größe / Größe Auslagerungsdatei richtig bestimmen
Linux/OpenSource, Windows/Microsoft Februar 17th, 2008Bei der Windows Auslagerungsdatei bzw. Linux Swap Space handelt es sich um virtuellen Speicher. Virtueller Speicher dient dazu, den physisch „echt“ vorhandenen Speicher in Form von RAM zu ergänzen. Es wäre schön, wenn man statt den relativ teuren RAM Modulen einfach 100GB Auslagerungsspeicher einstellen könnte und sich nie wieder Sorgen um die Größe des Speichers machen müßte.
So einfach ist es jedoch nicht: Swap Space kommt mit einem ganz anderen Preisschildchen, nämlich der Geschwindigkeit. Bei meinem PC habe ich eine Speichergeschwindigkeit von ungefähr 3GB/s auf den Hauptspeicher (RAM), während meine Festplatte vielleicht 20 oder 30MB/s auf die Wage bringt. Doch noch schlimmer wird es bei Zugriffszeiten: Während Hauptspeicher in Bereich von Nanosekunden eine Speicherstelle ansprechen kann, liegt dies bei Festplatten im Milisekunden Bereich: Hier sind ganze Größenordnungen Unterschied zu verzeichnen!
Was passiert eigentlich wenn ein Betriebssystem virtuellen Speicher verwendet, sei es in Form einer Swap Partition, einer Swap Datei oder wie bei Microsoft Windows einer Auslagerungsdatei?
Sobald mehr Speicher benötigt wird, als physisch vorhanden, wird durch die MMU (Memory Management Unit) einfach so getan als sei ab einer gewissen Adresse noch mehr Speicher da. Je nach der verwendeten Strategie (Paging, Swapping oder Segmentierung) ist das Verhalten etwas anders, aber das Prinzip ist immer gleich. Die MMU merkt sich, ob ein Adreßbereich gerade auf echtes RAM zeigt, oder auf virtuellen Speicher der eigentlich garnicht da ist.
Erfolgt ein Zugriff auf einen Bereich der im RAM liegt, so wird der Zugriff einfach auf die echte RAM Adresse umgelenkt. (Dank der MMU sind alle Adressen im Speicher niemals die echten Adressen, sondern nur Verweise auf den zugeordneten Bereich. So lassen sich z.B. auch Speicherbereiche der Grafikkarte einfach in diesem MMU Adressraum abbilden.)
Erfolgt jedoch ein Zugriff auf einen Bereich, der gerade ausgelagert ist, so wird der Zugriff eingefroren und das Betriebssystem informiert, dass dieser Bereich benötigt wird. Das Betriebssystem kümmert sich dann darum den Speicherbereich wieder in den Hauptspeicher zu laden – meist wird sogar etwas mehr zurückgeladen da das Betriebssystem davon ausgeht dass auch die nächsten Bereiche bald benötigt werden könnten.) Ggf. muss dazu erstmal Platz im Hauptspeicher geschaffen werden – Caches werden geleert oder andere Speicherbereiche ausgelagert.
Dann wird der MMU mitgeteilt wo jetzt angefragten Daten zu finden sind, und der ursprüngliche Zugriff wird dahin umgeleitet.
Ein ganz schöner Akt – und noch ein Argument mehr auf Swap und virtuellen Speicher zu verzichten?
Im Prinzip ja – „aber“.
Festplatten sind wie bereits erwähnt sehr langsam, deswegen möchte man möglichst nicht auf diesen sogenannten Sekundärspeicher zugreifen. Das Betriebssystem versucht häufig benutzte Bereiche der Festplatte im Hauptspeicher abzubilden – der sogenannte Cache. (Grob gesagt das umgekehrte zur Auslagerung)
Startet man ein großes Programm, wie z.B. OpenOffice, beendet es und startet es dann nochmal merkt man den spürbaren Unterschied zwischen gecachten Daten und Lesen vom Sekundärspeicher.
Und jetzt wird deutlich warum swapping bzw. Auslagern so wichtig für eine erhöhte Geschwindigkeit ist: Ich starte OpenOffice und fange an einen Brief zu schreiben. Weil ich aber doch lieber etwas spielen möchte, starte ich z.B. CounterStrike oder WorldOfWarcraft: Hier werden viele Daten in Form von Texturen, Sounds und Levelinformationen benötigt. Wenn ich keinen Auslagerungsspeicher habe, so kann nur der tatsächlich freie Hauptspeicher verwendet werden, um diese Informationen um schnellen RAM vorzuhalten.
Habe ich jedoch virtuellen Speicher, so kann OpenOffice und andere Dinge einfach ausgelagert werden – solange ich nicht darauf zugreife steht der Speicher somit für mein Spiel zur Verfügung.
Das macht also durchaus Sinn und bringt Geschwindigkeitsvorteile – wenn ich dann wieder auf die ausgelagerten Daten zugreife dauert es dafür etwas. Die schlimmste Situation die auftreten kann, ist dabei das sogenannte „thrashing“ – der physische Speicher reicht nicht aus, um alle aktiv genutzten Programme und Daten aufzunehmen. Das Betriebssystem lagert ständig Bereiche ein und wieder aus.
In der Situation wäre es mir lieber, wenn das Betriebssystem melden würde: „Nicht genug Speicher.“ als virtuellen Speicher als tatsächliche RAM-Erweiterung zu nutzen, und damit unerträglich langsam zu werden.
Jetzt stellt sich also die Frage: Wie groß soll ich den Swap Bereich einstellen?
Aus den Zeiten von Unix und PDC-11 Computern mit wenigen MB Hauptspeicher stammt die Daumenregel: Auslagerungsspeicher doppelt so groß zu machen, wie den physisch vorhandenen Speicher.
Seit dem hat sich einiges geändert. Heutige Computer verfügen über einige Gigabyte Hauptspeicher, dieser ist um vieles schneller geworden als zu den Zeiten als Unix und diese Form der Speicherverwaltung erfunden wurde.
Festplatte sind auch schneller und größer geworden – allerdings sind sie wesentlich größer als denn auch schneller geworden! Konnte früher in 100ms vielleicht ein MB gelesen werden, so ist das heute nicht viel besser, denn allein 20 bis 30 Milisekunden gehen für den Zugriff drauf, und da hilft dann eine hoher Durchsatz nicht mehr viel, es sind dann vielleicht 5 MB die geschafft werden können.
Hat man also einen Rechner mit 2GB Hauptspeicher, macht es nicht unbedingt Sinn hier 4GB Auslagerungsspeicher als Größe zu wählen. Bei einem Desktop (Arbeitsplatz / Spielerechner) würde ich davon ausgehen, dass ich Teile des Betriebssystems (Windows oder Linux) auslagern möchte, und nicht verwendete Dienste und Komponenten. Selbst wenn ich mit wirklich großen Grafiken arbeiten möchte, bieten die Programme in der Regel eigene Techniken zur Auslagerung an, die für den Zweck besser geeignet sind, als eine generische Betriebssystem Lösung.
Daher würde ich nicht mehr als 1-2 GB als Auslagerungsspeicher auswählen, sondern lieber darauf achten keine unnötigen Programme zu starten, wenn ich spielen möchte (Virenscanner, Firewall, oder das Dinge wie das extrem ressourcenhungrige ICQ), bei der normalen Arbeit sollte der Speicher erst recht passen.
Für Linux ist hier eine Besonderheit zu beachten, Suspend-to-disk bzw. Hibernate funktioniert derzeit über den Swap Bereich – dieser muß ca. 120% so groß sein, wie der physische Speicher, damit das korrekt funktioniert. Windows legt zusätzlich zum Auslagerungsspeicher eine „hiberfile.sys“ der passenden Größe an, hier sind die beiden also getrennt.
Generell sollte also der Auslagerungsspeicher nicht größer als der physisch vorhandene Speicher sein, und auch dann hat man leider keine Garantie, dass kein thrashing eintritt.
Für Serverumgebungen habe ich gute Erfahrungen mit der halben Größe des physisch vorhandenen Speichers als swap Größe gemacht. Empirische Daten dazu habe ich jedoch nicht erhoben und auch nicht finden können.
Ganz wichtig, vor allem bei Windows: Hat man keine eigene Partition für den Swap Bereich angelegt, sondern verwendet Dateien zur Auslagerung und/oder Hibernation, wie Windows dies tut: Es ist darauf zu achten, dass diese nicht fragmentiert sind, sondern in einem zusammenhängenden Bereich auf der Festplatte liegen.
Deswegen sollte man bei Windows die größe der Auslagerungsdatei manuell festlegen und sowohl die minimale als auch die maximale Größe fest konfigurieren.
Einige Tools bieten die Defragmentierung dieser Datei auch an (meist als sogenannte offline Defragmentierung).
Hat man keins der Tools zur hand, kann man den Hibernation Modus und die Auslagerungsdatei gänzlich deaktivieren, nach einem Neustart die Festplatte defragmentieren und anschließend die Optionen wieder aktivieren.
Hat man mehrere Festplatten zur Verfügung, so macht es grundsätzlich Sinn, den Auslagerungsspeicher nicht auf der Festplatte anzulegen, auf der hauptsächlich die Zugriffe eintreten, auch dann wenn die andere Festplatte etwas langsamer ist. So können dann Zugriffe auf den virtuellen Speicher und auf benötigte Daten parallel erfolgen und konkurrieren nicht miteinander.
Neue Kommentare