2K8: x64 vs. x86 bei Terminalserver

[michael.ettl 10]

Hi.

wie ist das eigentlich bei Terminalserver 2008? v.a. wegen Hauptspeicher?

 

Angenommen, ich habe vier 2003er TS mit je 4 GB RAM, passen die auf 2x 2008er TS (64bit) mit 8 GB RAM. 2x 8 sollte ja 4x 4 sein, oder?

 

Die Anwendungen selbst sind 32bittig, z.B. Office2003 und so.

Oder gibts Office auch in 64bit?

 

Ja, Druckertreiber braucht man dann auch neue.

 

Ciao

[LukasB 10]

2008 R2 gibt es nur noch in 64bit. Ein guter Grund, nur noch in Notfällen WS08 in 32bit zu deployen.

 

Bei Terminalservern ist vorallem interessant das die Limiten für Paged Pool / Non Paged Pool bei der 64bit Version gewaltig gestiegen ist - ein 2003 TS 32bit Enterprise mit 8GB RAM hat ja nix gebrach, weil eben die Pools zuende waren.

 

Es kann also schon gut sein das ein 64bit TS mehr "Punch" hat als ein 32bit - bei gleicher RAM Menge.

 

Die Applikationen dafür müssen nicht 64bit sein.

 

Aber was du schauen musst: Support. Supportet der Softwarehersteller den Betrieb unter WS08 x64? Wenn nein, dann musst du in den saueren Apfel beissen.

[Velius 10]

Nachtrag: 32Bit Applikationen ohne Kernel Level Treiber laufen auf 64Bit - sobald Kernel Level dabei sind muss es nativ 64Bit sein.

[michael.ettl 10]

Bei Terminalservern ist vorallem interessant das die Limiten für Paged Pool / Non Paged Pool bei der 64bit Version gewaltig gestiegen ist - ein 2003 TS 32bit Enterprise mit 8GB RAM hat ja nix gebrach, weil eben die Pools zuende waren.

ich dachte bei Terminalserver sei das Problem (okay, ein Problem): Jede Anwendung sieht immer 4 GB, auch wenn bloss 512 MB stecken, von den 4 GB sind 2 GB "privat" und 2 GB "gemeinsam für alle Programme"

[Velius 10]

Es gibt verschiedenset Probleme: Eines davon hast du erwähnt, aber nicht ganz korrekt formuliert. Kernel Level Applikationen stehen nur max 2 GB Speicher zur Verfügung. Das Verhältnis Kernel/Rest lässt sich aber zu ungunsten (z.B. Exchange) verändern, so dass er nur noch sagen wir 1 GB anspricht.

 

Weiss aber gerade nicht, ob sich bei 64Bit was geändert hat bezüglich Kernel.

 

 

Ein anderes und viel mehr wichtigeres Problem aus Performance sicht: 32Bit OS generell können nur max 4 GB RAM ansprechen. Das ist eine rein rechnerische Limitation und lässt sich nur durch Trciks die schon bei DOS angewandt wurden umgenen (Extended Memory Manager == Physical Address Extension).

 

 

64Biter können weit mehr RAM direkt verwalten. Irgendwas im 2 stelligen Tera bereich glaub ich.

[Velius 10]

Ok, lag ein weeeeenig daneben - es sind 16 Exabytes die ein 64Biter theoretisch direkt adressieren kann (~16 Millionen (!) Terabytes).

[michael.ettl 10]

Bei jährlicher Verdoppelung des Speicherverbrauchs bedeutet der Schritt 2^32 auf 2^64 genau 32 Jahre Ruhe. Da bin ich schon in Ruhestand, oder fast.

 

Andererseits konnte schon Win 2000 Advanced mit 8 GB umgehen - und heute sind wir 8 Jahre weiter. Wo ist der Fortschritt?

[Velius 10]

Win 2000 Advanced benutzt PAE (Physical Address Extension)....

 

Am besten einfach selbst ma lesen.;)

Physical Address Extension (Windows)

 

Du hast mit 64Bit & >= 4GB RAM nicht diesen Overhead wie mit Memeory splitting und rewriting wie mit 32Bit & PAE.

[zahni 571]

32-Bit Adresslänge (also 32 Leitungen) können nun mal nur 4 GB Adressieren.

 

Der Zusätzliche Speicher wird mit einem Hardwaretrick adressiert. Das ist weder performant (Speicherfenste müssen jeweils in einem Bereich unterhalb der 4Gb-Grenze eingeblendet werden), noch können Anwendungen den Speicher über 4GB direkt adressieren. Wenn der Taskmanager über 4GB anzeigt, ist das ein klein wenig gelogen. 64-Bit ist allemal besser. Details dazu:

 

Operating Systems and PAE Support

 

-Zahni

[Velius 10]

Das ist weder performant (Speicherfenste müssen jeweils in einem Bereich unterhalb der 4Gb-Grenze eingeblendet werden), noch können Anwendungen den Speicher über 4GB direkt adressieren. Wenn der Taskmanager über 4GB anzeigt, ist das ein klein wenig gelogen.

 

Nicht direkt gelogen: Address Windowing Extensions (Windows)

 

Aber es ist auch nur ein Trick und mit Overhead verbudnen. x64 ist allemal besser wenn man ne App hat die das braucht.

[michael.ettl 10]

32-Bit Adresslänge (also 32 Leitungen) können nun mal nur 4 GB Adressieren.

Kratzt mich, beisst mich, gebt mir Tiernamen, aber schon der PentiumPro hatte 1995 schon 36 Leitungen, definitiv, siehe Rechneraufbau und Rechnerstrukturen - Google Buchsuche und Die Geschichte des Computers - von Intels 80368er bis zum Duell Intel gegen AMD

[LukasB 10]

Kurzfassung:

 

PAE + AWE = Böse

x64 = Gut

 

Ich habe unseren internen Admin/Remote User TMS schon seit nem halben Jahr auf 2008 Beta 3 / RC / RTM x64 gehabt und wir hatten keine Probleme. Sämtliche Standardanwendungen die wir einsetzen funktionierten Problemlos, sogar unsere Inhouse-Anwendungen machten keine Probleme.

[Velius 10]

Kratzt mich, beisst mich, gebt mir Tiernamen, aber schon der PentiumPro hatte 1995 schon 36 Leitungen, definitiv, siehe [/url]

 

Da hast du recht, aber du bedenkst nicht, diese 36 Bahnen hat die CPU. Das 32Bit OS Rechnet aber mit 32 pro Cycle. Und ein 36Bit OS hätte absolut kein Sinn gemacht.

[michael.ettl 10]

Da hast du recht

Ich wollte nur

Der Zusätzliche Speicher wird mit einem Hardwaretrick adressiert.

widerlegen

 

Die Hardware kanns, bloss die Software nicht bzw. nicht gut

[Velius 10]

Ist deswegen trotzdem ein Trick durch die Hardware

 

Falsch wäre es einen Software Trick zu nennen. PAE wäre ohne die zusätzlichen 4 Bahnen nicht möglich, also =/= Softwaretrick.