Logo faq-o-matic.net
Logo faq-o-matic.net

Wieviel RAM ist sinnvoll bei Terminal Servern?

von veröffentlicht am26. Oktober 2004, 15:03 Uhr Kurzlink und Zitatlink einblenden
Kategorie Kategorie: Terminal Server, Windows   Translate with Google Translate Translate EN   Die angezeigte Seite drucken
Zuletzt aktualisiert: 26. September 2013

Wenn man sich mit Performance-Tuning und Server Scaling beschäftigt, dann stößt man früher oder später an die sogenannte 4 GB-Grenze. Das klassische Windows ist ein 32 Bit-System und damit lassen sich grundsätzlich maximal 4 GB Hauptspeicher sinnvoll nutzen. Überraschend für viele ist allerdings die Tatsache, dass eine Hauptspeicherausstattung von >3GB für herkömmliche Terminal Server nicht sinnvoll ist. Woher kommt diese Grenze?

Per Definition nutzt ein 32-Bit-Prozessor 32 Bits, um den Hauptspeicher anzusteuern. 2ˆ32 = 4.2 Milliarden – also kann eine 32 Bit breite Speicheradresse maximal 4.2 Milliarden Speicherzellen ansteuern. Daraus resultiert also die 4 GB-Grenze. In unserer 32-Bit-Windows-Welt steht jeder Applikation ein eigener ‚virtueller‘ 4 GB großer Speicherbereich zur Verfügung. Diese 4 GB werden in zwei Hälften zerlegt, je 2 GB für Kernel und User Memory Space. Jede Applikation bekommt ihre eigenen 2 GB User Memory Space. Der Haken: Die anderen 2 GB Kernel Memory Space sind zwischen allen Applikationen geshared.

Das verursacht die Probleme im Terminal Server-Umfeld. Auf Terminal Servern mit vielen Usern, die mehrere Applikationen nutzen (je nach Nutzungsart ab ca. 40 User aufwärts), wird dieser 2 GB große Kernel-Memory-Bereich recht zügig belegt. Praxistests haben ergeben, dass ein Windows 2000-basierender Terminal Server maximal ca. 200 User-Anmeldungen verträgt, dann ist der 2 GB Kernel Memory Space ausgereizt, auch wenn ein ‚Monster-Server‘ mit 16 GB RAM und acht 3GHz Xeons zur Verfügung steht.

Mit Windows 2003 ist etwas mehr Finetuning in der Belegung der 2 GB Kernel Memory Space möglich. Das schafft allerdings auch keine Abhilfe, wenn sich tausende von Prozessen und hunderte von Usern diesen 2 GB Kernel Memory Space teilen.

Nun könnte man auf die Idee kommen, den /3GB- (Windows 2000) oder den /4GT-Schalter (Windows 2003) in der boot.ini zu nutzen. Das macht aber bei einem Terminal Server alles nur schlimmer – es halbiert die mögliche Anzahl der gleichzeitigen User. Denn für den User Memory Space gibt es zwar dann 3 GB, der Kernel Memory Space wird aber auf 1 GB verringert – das führt dann auf Terminal Servern doppelt so schnell an das Kapazitätslimit.

Oft wird dagegen der Einwand gebracht, dass Versionen wie Enterprise und die Datacenter Edition mehr als 4 GB physikalischen Hauptspeicher unterstützen. Aber auch wenn mehr als 4 GB RAM eingebaut sind, hat jeder Prozess das normale 2 GB-Limit und der Kernel Memory Space ist weiterhin 2 GB geshared – wie bei einem normalen non-PAE-System.

Die einzige sinnvolle Nutzung kann man mit /PAE erreichen. Dann können bis zu 64 GB RAM adressiert werden. Ein 32 Bit-Prozess benutzt dann große Speicherblöcke via AWE-Funktion (Address Windowing Extension). Das bedeutet, dass einzelne Bereiche des physikalischen Speicherbereichs in den (immer noch nur) 2 GB großen virtuellen User Memory Space gemappt wird. Insgesamt kann der Prozess aber auch hier max. 2 GB physikalischen Speicher zur Zeit nutzen.

Mehr dazu findet man in Kapitel 7 von „Inside Windows 2000“ von David Solomon und Mark Russinovich:

„All of the Intel x86 family processors since the Pentium Pro include a memory-mapping mode called Physical Address Extension (PAE). With the proper chipset, the PAE mode allows access to up to 64 GB of physical memory. When the x86 executes in PAE mode, the memory management unit (MMU) divides virtual addresses into four fields.

The MMU still implements page directories and page tables, but a third level, the page directory pointer table, exists above them. PAE mode can address more memory than the standard translation mode not because of the extra level of translation but because PDEs and PTEs are 64-bits wide rather than 32-bits. The system represents physical addresses internally with 24 bits, which gives the x86 the ability to support a maximum of 2ˆ(24+12) bytes, or 64 GB, of memory.

As explained in Chapter 2 , there is a special version of the core kernel image (Ntoskrnl.exe) with support for PAE called Ntkrnlpa.exe. (The multiprocessor version is called Ntkrpamp.exe.) To select this PAE-enabled kernel, you must boot with the /PAE switch in Boot.ini.

Only Windows 2000 Advanced Server and Windows 2000 Datacenter Server are required to support more than 4 GB of physical memory. (See Table 2-2.) Using the AWE Win32 functions, 32bit user processes can allocate and control large amounts of physical memory on these systems.“

Daher sind mehr als 4 GB RAM nur in Ausnahmefällen sinnvoll. Es handelt sich dabei um spezielle Datenbank-Versionen (z.B. MS SQL 2000 Enterprise Edition), die mehr Speicher verwenden können, da sie diese speziellen Aufrufe nutzen können. Die breite Masse der Windows-Anwendungen sind dafür nicht ausgelegt.

Zum Problem des fragmentierten Kernel Memory Spaces und die Optimierungsmöglichkeiten ist der Artikel Konfigurieren des Auslagerungsspeichers und des System-PTE-Speichers interessant.

Nun könnte man ja auch auf die Idee kommen, auf einem TS mit mehr als 4 GB RAM den PAE-Schalter zu nutzen. Leider sorgt aber der PAE-Schalter nicht für mehr Speicher für den Kernel. Er sorgt nur für mehr nutzbaren RAM im User Memory Space. Daher ist die Nutzung von PAE in Terminal Server-Umgebungen eher schlecht. Jede Applikation würde vier mal mehr Einträge im Kernel Memory Space verbrauchen, wodurch die 2 GB noch schneller voll laufen.

Dazu ein Zitat aus The 4 GB Windows Memory Limit: What does it really mean? von Brian Madden:

„How does Terminal Services uses memory? Why is it bound to the kernelmemory of 2 Gb?
In 32-bit Windows systems, the kernel can never ever use more than 2 GB of memory. Period. Even with the x86 PAE, the kernel still is limited to 2 GB. That’s just the way it is, and there’s no way around it.  The kernel is bound to 2 GB because the memory manager can never address more than 4 GB. Why? Because the memory manager uses 32-bit addresses for memory, and 2ˆ32 = 4GB. This will probably never change, since 64-bit OSes are around the corner, and this 2GB kernel limit is only hit in Terminal Server environments.“

Erst mit x64-Systemen steht eine Möglichkeit zur Verfügung, die 4-GB-Grenze zu überwinden. Siehe dazu: Wie Windows mit großem Hauptspeicher umgeht

© 2005-2017 bei faq-o-matic.net. Alle Rechte an den Texten liegen bei deren Autorinnen und Autoren.

Jede Wiederveröffentlichung der Texte oder von Auszügen daraus - egal ob kommerziell oder nicht - bedarf der ausdrücklichen Genehmigung durch die jeweiligen Urheberinnen oder Urheber.

Das Impressum findet sich unter: http://www.faq-o-matic.net/impressum/

Danke, dass du faq-o-matic.net nutzt. Du hast ein einfaches Blog sehr glücklich gemacht!