Re: W23K-Terminalserver mit Qber_8GB_RAM_?=
From: Daniel Melanchthon [MVP] (melanchthon_at_gmx.de)
Date: 08/18/04
- Next message: Daniel Melanchthon [MVP]: "Re: Lizenzserver für TS"
- Previous message: Daniel Melanchthon [MVP]: "Re: W2k3 TS in W2k Domäne"
- In reply to: Andreas Filippelli: "W23K-Terminalserver mit Qber=208GB=20RAM?="
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 18 Aug 2004 22:32:24 +0200
Andreas Filippelli wrote:
> Muss ich bei der Konfiguration eines Windows 2003 Terminalserver
> (Citrix Metaframe) mit 8 GB RAM etwas beachten? Wenn ja, was?
die Kurzfassung lautet: Wenn Du 4 GB ausbaust oder Windows Standard
Edition installierst oder keine zusätzlichen Parameter in die boot.ini
schreibst und somit auch bei Windows 2003 Enterprise Edition nur max.
4GB nutzt, dann ist alles so, wie bisher gehabt.
Bei allen anderen Szenarien findest Du nach ein wenig Lesen auch raus,
dass es sinnlos ist, einen Server so fett auszustatten :-)
Wesentlich sinnvoller wären zwei kleinere Server gewesen, da Du damit
wesentlich besser skalieren kannst, als mit einer großen Kiste und Du
gleichzeitig mehr Ausfallsicherheit hast. Bei Terminal Servern mußt Du
Scale out statt Scale up betreiben. Deswegen gibt es defacto in
größeren Umgebungen immer TS-Farmen und keine Windows Datacenter Editions.
Fazit: Alles größer 3 GB sind Perlen vor die Säue und alles größer 2
Prozessoren [aus Windows(!)-Sicht => Hyperthreading...] ist ebenso
fraglich und sollte genau gemessen werden. Xeon im TS-Umfeld ist
oversized, Pentium III mit 1,4GHz reichen locker aus.
Eventuell kann es sinnvoll sein, sich für ca. 3.750 US$ noch ein
VMware ESX Server (Dual CPU-Lizenz) zuzulegen und anstatt den ganzen
Server mit Windows 2003 Enterprise Edition laufen zu lassen, auf der
Hardware zwei bis vier virtuelle Server mit Windows 2003 Standard als
Terminal Server zu fahren.
Worauf begründen sich diese Ausagen?
Wenn man sich mit Performance-Tuning und Server Scaling beschäftigt,
dann stößt man früher oder später auf den unumstößlichen Fakt, das
Windows ein 32 Bit-System ist und damit maximmal 4 GB Hauptspeicher
sinnvoll nutzen kann.
Per Definition nutzt ein 32 Bit Prozessor 32 Bits um den Hauptspeicher
anzusteuern. 232 = 4.2 Milliarden - also kann eine 32 Bit breite
Speicheradresse maximal 4.2 Milliarden Speicherzellen ansteuern. Daher
kommen also die 4 GB.
In unserer 32 Bit Windows-Welt stehen 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 seine 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 (so ab 40 aufwärts), die mehrere
Applikationen nutzen, 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 voll, auch wenn die
ganze Maschine 16 GB RAM und acht 3GHz Xeons hat. Es handelt sich ganz
simple um ein Architekturlimit von 32 Bit Windows-Systemen.
Mit Windows 2003 ist an einigen Schrauben gedreht worden, damit etwas
mehr Finetuning in der Belegung der 2 GB Kernel Memory Space möglich
ist. Das hilft aber nichts, 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 zum Disaster.
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 folgender Artikel interessant:
http://support.microsoft.com/?id=247904
Weiterhin gibt es von MS einen Kernel Tuning Assistant, der einnem
beim Finetuning helfen kann:
http://www.dabcc.com/ThinSol/Downloads/Files/Kernel%20Tuning%20Assistant.xls
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.
Zitat:
"How does Terminal Services uses memory? Why is it bound to the
kernelmemory of 2Gb?
In 32-bit Windows systems, the kernel can never ever use more than 2GB
of memory. Period. Even with the x86 PAE, the kernel still is limited
to 2GB. That’s just the way it is, and there’s no way around it. The
kernel is bound to 2GB because the memory manager can never address
more than 4GB.
Why? Because the memory manager uses 32-bit addresses for memory, and
232 = 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."
Gruß!
Daniel
-- Gruss aus dem Hoch im Norden! Daniel Melanchthon - MVP Exchange Server "Banging your head against a wall uses 150 calories an hour!"
- Next message: Daniel Melanchthon [MVP]: "Re: Lizenzserver für TS"
- Previous message: Daniel Melanchthon [MVP]: "Re: W2k3 TS in W2k Domäne"
- In reply to: Andreas Filippelli: "W23K-Terminalserver mit Qber=208GB=20RAM?="
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
