Wie Windows mit großem Hauptspeicher umgeht

Da es immer wieder Unklarheiten zum Umgang von Windows-Betriebssystemen mit großen Speichermengen (RAM) gibt, fasse ich die wichtigsten Punkte noch einmal zur Beachtung zusammen.

„Ich möchte mehr als 4 GB in meinen Server einbauen.“

Die bisher genutzten Betriebssysteme – nicht nur Windows, sondern auch Linux und andere – sind auf 32-Bit-Technik gebaut. Es stehen damit 32 Bit zur Verfügung, um Speicherinhalte zu adressieren (also Daten im Speicher ausfindig zu machen). Mit 32 Bit lassen sich maximal 4 Gigabytes RAM ansprechen (2³² = 4294967296 Bytes). Es ist also nicht möglich, mehr als 4 GB RAM mit einem 32-Bit-Betriebssystem anzusprechen.

Natürlich kann es trotzdem sinnvoll sein, mehr als 4 GB RAM zu nutzen. Der derzeit beste Weg, das zu tun, besteht im Einsatz eines 64-Bit-Betriebssystems für die sog. „x64“-Plattform. Solche Systeme sind für Windows XP, Windows 2003 und Vista verfügbar (und natürlich für andere Betriebssysteme).

„Meine Applikationen nutzen von den 4 GB immer maximal 2 GB aus!“

Die 4 GB, die ein 32-Bit-Windows adressieren kann, teilt es in zwei virtuelle Speicherbereiche auf: Das System und seine Daten (sowie Treiber usw.) haben Zugriff auf einen virtuellen Speicher von 2 GB („Kernel Mode“). Applikationen erhalten ebenfalls einen virtuellen Speicher von 2 GB („User Mode“) – pro Applikation. Da diese virtuellen Speicher schon rechnerisch zusammen mehr als 4 GB ergeben, bringt Windows einen sehr leistungsfähigen Speichermanager mit, der die Zugriffe koordiniert. Datenbereiche, die gerade benötigt werden, liegen stets auf sog. „Speicherseiten“ (Pages) im RAM. Datenbereiche, die gerade nicht aktiv benötigt werden, lagert Windows auf die Festplatte aus (in die Auslagerungsdatei oder „Page File“). Von dort werden sie bei Bedarf wieder ins RAM geladen.

Es ist zar möglich die Aufteilung von 2 GB Kernel zu 2 GB Usermode zu verändern. Dafür gibt es eine Konfigurationsoption, die den Kernelbereich auf 1 GB einschränkt und den Applikationsbereich auf 3 GB erweitert. Vorsicht aber: Das geht meist nach hinten los und ist nur für sehr wenige Applikationen geeignet, denn mit 1 GB Systemspeicher läuft Windows selbst schnell gegen die Wand. Sehr schön erläutert das Tipp 1.13 in dem Buch „Windows Server 2003 – Die Expertentipps“.

In einem x64-System gibt es diese Aufteilung so nicht mehr – oder genauer: Sie spielt weniger eine Rolle, weil die Grenze viel höher liegt (derzeit 8 TB …). Allerdings wird auch hier der adressierbare Bereich nur dann von Applikationen genutzt, wenn diese das auch unterstützen. Bei professionellen Anwendungen, die für x64 entwickelt wurden, kann man davon ausgehen, dass es klappt.

„Mit der Enterprise Edition von Windows 2003 kann man aber bis zu 64 GB RAM einsetzen!“

Die Enterprise Edition von Windows Server 2003 in der 32-Bit-Fassung bietet (genau wie die von Windows 2000 Server) Unterstützung für ein Feature namens „PAE“ (Physical Address Extension) bzw. „AWE“ (Address Windowing Extension; so nennt Intel das). Dadurch ist es einem 32-Bit-System möglich, Speicherbereiche, die über der Grenze von 4 GB liegen, dynamisch bei Bedarf im Adressbereich unter 4 GB einzublenden. Sobald die Daten von dort gelesen oder verändert sind, werden die Zeiger auf den Speicher wieder zurückgesetzt, und der erweiterte Speicher wird wieder ausgeblendet.

Dieses Ein- und Ausblenden großer Speicherbereiche erfordert natürlich Zeit und Prozessorleistung. Auf diese Weise wird der Zugriff auf den „hohen“ Speicher langsamer sein als der auf „niedrige“ Speicherbereiche – die Performance leidet. Die wichtigste Einschränkung aber ist: Das ganze lässt sich ohnehin nur dann nutzen, wenn die eingesetzte Applikation dies auch unterstützt – sonst wird sie weiterhin nur 2 GB nutzen. Eine der sehr (!) wenigen Applikationen, die das Speicher-Mapping unterstützen, ist SQL Server ab Version 2000. Voraussetzung ist hier, dass in der boot.ini-Datei des Betriebssystems der Schalter „/PAE“ gesetzt ist, der das Feature aktiviert (bzw. seit Windows 2003 SP1 ist PAE standardmäßig aktiviert – es sei denn, man schaltet die „No Execute“-Unterstützung pauschal ab, dann ist erst mal auch PAE abgeschaltet).

Bleibt die Schlussfolgerung: Wer mehr als 4 GB physischen Speicher braucht oder seiner Applikation mehr als 2 GB gönnen möchte, kann dies am besten mit einer x64-Version erreichen.

„Ich habe 4 GB RAM in meinem Server bzw. PC, aber Windows zeigt nur 3,24 GB an. Was macht Windows mit dem Rest?“

Auf fast allen Rechnern wird von 4 GB nur ein Teil angezeigt und genutzt. Windows ist unschuldig – das Problem liegt in der Architektur. Das Phänomen ist bekannt als „PCI Hole“ und liegt vereinfacht gesagt daran, dass bereits das BIOS einen Teil des 4-GB-Adressraums vor dem Betriebssystem versteckt, um dort Adressbereiche für die Hardware-Unterstützung abzulegen.

Ob sich dieses Problem durch den Schalter „PAE“ beheben lässt, wie man bisweilen liest, hängt davon ab, welche Windows-Version eingesetzt wird. Mit Windows Server 2003 (sogar Standard Edition) lassen sich via PAE die vollen 4GB RAM nutzen, wenn das BIOS Memory Remapping unterstützt (zwingende Voraussetzung!). Bei Vista und Windows XP wird, weil es Client-Betriebssysteme sind, die Nutzung auf Speicheradressen unterhalb von 4GB begrenzt. Der Hintergrund ist, dass viele Consumer-Treiber von den Herstellern nicht mit PAE getestet werden und mit Speicheradressen oberhalb von 32 Bit nicht umgehen können. Im Server ist das was anderes – die Servertreiber sind in der Regel aufwändiger getestet.

Der Microsoft-Mitarbeiter Daniel Melanchthon hat das recht hübsch für Vista beschrieben, wobei es auch für alle anderen Windows-Versionen zutrifft: „4 GB RAM mit Windows Vista“

„Wieviel RAM kann ich denn für Applikation XYZ einsetzen?“

Die meisten derzeit eingesetzten Programme laufen noch auf 32-Bit-Systemen und sind dafür optimiert. Hier ein kleiner Überblick über ein paar wichtige Applikationen:

• Windows-Dienste (Dateidienste, Druckdienste, Active Directory usw.): Auf 32-Bit-Systemen steht diesen Diensten ein Adressraum von 2 GB zur Verfügung. In größeren Netzwerken können auch diese einfachen Dienste von dem hohen Speicherausbau eines x64-Systems profitieren, denn in den x64-Versionen können alle diese Applikationen auf den großen Adressraum zugreifen. Dadurch passen mehr Daten ins RAM, und die Performance steigt.
• Terminalserver 32 Bit: Ein klassischer Terminalserver auf 32-Bit-Basis kann nicht mehr als 4 GB RAM adressieren; manche Experten legen die optimale RAM-Größe hier sogar mit 3 GB fest. Von allen Versuchen, einen 32-Bit-Terminalserver mit der Enterprise Edition und mehr RAM zu betreiben oder ihm mit dem „/3GB“-Schalter mehr RAM zuzubilligen, ist Abstand zu nehmen: Die Performance wird höchstwahrscheinlich drastisch einbrechen. Warum das so ist, erklärt wiederum Daniel Melanchthon hier: „Wieviel RAM ist sinnvoll bei Terminal Servern?„
• Terminalserver x64: Terminalserver profitieren sehr von x64-Systemen – aber nur, wenn das Gesamtsystem auch ausreichend performant ausgelegt ist (Prozessoren, interne I/O, externe I/O). Gerade bei Terminalservern gibt es einige mögliche Flaschenhälse, von denen das RAM nur einer ist.
• Exchange Server 2003: Exchange 2003 kann maximal 2 GB RAM adressieren, der maximal mögliche Speicherausbau liegt also bei 4 GB (weil das System selbst ja auch noch Platz braucht).
• Exchange 2000 Server: Exchange 2000 kommt mit mehr als 1 GB nicht klar – wer einen instabilen Exchange-2000-Server mit mehr RAM hat, sollte die überschüssigen Riegel entfernen.
• Exchange Server 2007: Das neue Exchange wird in Produktionsumgebungen nur in der x64-Version unterstützt. (Nur für Testzwecke gibt es eine 32-Bit-Variante.) Dadurch kann es mit viel RAM umgehen; für größere Kunden können 8 GB oder mehr durchaus sinnvoll sein.
• SQL Server 2000: SQL 2000 Standard kann nur 2 GB RAM ansprechen, maximaler Systemausbau also 4 GB. Die Enterprise Edition hingegen beherrscht PAE/AWE und kann damit mehr RAM ansprechen. Sinnvoller ist aber ein Umstieg auf SQL Server 2005 in der x64-Version.
• SQL Server 2005: Neue SQL Server sollten nur noch als x64-Version installiert werden (geht in allen Editionen), weil sie so auch mit viel RAM arbeiten können. Auch hier können für größere Kunden 8 GB oder mehr durchaus sinnvoll sein. Für 32-Bit-Versionen hingegen gilt dasselbe wie bei SQL Server 2000.

„Brauche ich für x64 nicht komplett neue Applikationen?“

Nein. Die x64-Technik ist in Wirklichkeit 32-Bit-Technik, die nur einen Speicherzugriff mit 64 Bit ermöglicht (eigentlich sind es derzeiit sogar „nur“ 40 Bit). Das bedeutet: Applikationen, die für 32-Bit-Windows entwickelt wurden, laufen in der Regel problemlos auf einem x64-System (die meisten sogar schneller als auf einem 32-Bit-System). Schwierigkeiten gibt es allerdings mit Treibern – diese müssen tatsächlich für x64-Systeme separat entwickelt werden. Für Server sollte das heute kein Problem mehr sein, solange es Hardware betrifft. Da aber auch manche speziellen Applikationen mit Treibern arbeiten – z.B. Virenscanner, Backupsysteme usw. -, sollte in Spezialfällen erst eine Überprüfung stattfinden.

Alte 16-Bit-Software hingegen ist auf einer x64-Maschine nicht lauffähig, weil es dafür keine Emulationsschicht mehr gibt. Das betrifft DOS-Applikationen (wie so manche alte Warenwirtschaft) oder auch manche sehr alte Windows-Software, die noch aus Windows-3.1-Zeiten stammt.

„Und was heißt das nun?“ 

Im Effekt heißt das: Für die meisten aktuellen Server kommt x64 durchaus in Frage. Bei Terminalservern sollte das genau geprüft werden. Für Workstations und PCs ist x64 derzeit nur im Ausnahmefall attraktiv (wegen der häufigen Treiberprobleme insbesondere mit externer Hardware).