Ist jede Terminalsitzung ein eigener Prozess?

[robbery 10]

Hallo,

 

bevor ich mich auf die Lösung eines Terminalservers stürze würde ich gerne noch wissen, ob bei jeder TS-Sitzung eines Users ein neuer Prozess gestartet wird?!?

 

Grund:

Ich möchte ein W2K8-Server in 32Bit mit ca. 32 GB RAM betreiben. In den PC-Eigenschaften werden mir diese eingebauten RAM auch angezeigt, anscheinend ist PAE schon automatisch aktiviert.

Da aber mein zu verwendendes Programm nicht mehr wie 4GB RAM nutzen kann, ist es für mich nun wichtig zu wissen, ob jedem TS-Nutzer ein neuer Prozess zugewiesen wird?

 

Halbwegs einleuchtend? Schon mal jetzt danke für mögliche Hilfen!

[nicholasdille 10]

Hallo,

 

eine Benutzersitzung auf einem Terminalserver sieht genauso aus wie auf einem Fat Client. Wenn Du also auf Deinem Rechner mal den Process Explorer startest, siehst Du, dass Deine Prozesse unterhalb der explorer.exe "hängen" und alle in Deinem Kontext ausgeführt werden.

 

Wenn Du mehrere Benutzer auf einem Terminalserver in einer Desktopsitzung angemeldet hast, sieht Du genau diese Struktur für jeden Benutzer einzeln.

 

Verwendest Du dagegen RemoteApps, sieht es etwas anderes aus, weil Du keinen Desktop von explorer.exe angezeigt bekommst. Aber auch dann werden alle Prozesse einer Benutzersitzung im Kontext des Benutzers ausgeführt und sind klar zu unterscheiden.

 

Ich hoffe, das hilft dir weiter.

 

Viele Grüße!

[OliverHu 19]

Hallo,

 

zusätzlich würde ich beim Hersteller des Programmes noch erfragen, ob das in einer Terminalserver-Umgebung auch unterstützt wird.

[zahni 521]

Die Frage wird sich auf diesem Thread beziehen:

 

https://www.mcseboard.de/windows-7-forum-76/dos-programme-win7-64bit-184043.html

 

Mit einem 32-Bit TS wirst Du auch mit PAE und 32 GB RAM nicht glücklich. Denn der TS kann trotzdem nur 4GB adressieren. Verwirrt ? Lies mal faq-o-matic.net » Wieviel RAM ist sinnvoll bei Terminal Servern? Ob DOS-Anwendunger überhaupt per AWE verschoben werden können, ist noch die Frage.

 

Gott sei Dank ist das AWE/PAE-Geraffel seit 64-Bit-Windows-Zeiten vorbei.

[nicholasdille 10]

Ich stimme zahni zu. Du kannst mit der Standard Edition von Windows Server 2008 auch 64-Bit mit bis zu 32GB RAM betreiben.

 

Trotzdem kann Windows Server 2008 in der Enterprise Edition auch mit 32-Bit 32GB RAM ansprechen. Der große Unterschied liegt aber darin, dass Dein Kernelspeicher auf 2GB beschränkt bleibt. Jedenfalls ohne besondere Konfiguration. Der Kernelspeicher wird zur Folge haben, dass Du i.d.R. nicht mehr Benutzer bedienen kannst, aber die Benutzer Anwendungen mit höherem Speicherbedarf ausführen können.

 

Die Beschränkungen des Kernelspeichers sollten Dich aber dazu bewegen, auf 64-Bit zu setzen!

 

Grüße!

[zahni 521]

Er will ja DOS-Programme laufen lassen. Das geht mit dem 64-Bit Windows nicht ,)

 

Und auch bei PAE kann man den RAM oberhalb der 4GB-Grenz nicht direkt ansprechen. Die AWE-Erweiterung blendet dazu den gewünschten Bereich oberhalb 4GB in einem Fenster unterhalb der 4GB Grenze ein ("AWE"). Das ist 1. nicht wirklich performant uns muss normalerweise von der jeweiligen Anwendung unterstützt werden. Standardmäßig kann Windows AWE-bereich als "Pagefile.sys" im RAM verwenden.

 

Ich hatte mal einen DB2-Server mit AWE laufen. Der konnte seine Bufferpools per AWE vergößern. Mehr nicht.

[nicholasdille 10]

Ach, ich muss den anderen Thread lesen, damit ich diese Frage verstehe ... *grmpf*

 

Bzgl. der Nutzung von Speicher oberhalb von 4GB mit 32-Bit-Windows-Servern muss ich Dir allerdings wiedersprechen. Ich habe schon mehrere Terminalserverumgebungen ... ähm, sorry, RDS-Umgebungen ;-) ... aufgebaut, um Kunden die Nutzung von speicherhungrigen Anwendungen zu ermöglichen. Die Benutzeranzahl ließ sich nicht weiter erhöhen (aus oben genanntem Grund), aber jedem Benutzer steht mehr Arbeitsspeicher zur Verfügung, der sich ohne AWE nutzen lässt.

 

Bei einer 16-Bit-Anwendung ist die Energie vielleicht besser in eine neue Anwendung investiert ;-)

[zahni 521]

Vielleicht gibt es heir auch nur ein Mißverständnis. Hier Operating Systems and PAE Support gibt es einen schönen Artikel zu dem Thema.

 

Ansonten gehört das für mich, wie das A20-Gate, ins Museum. In die Ecke, die keiner sehen will ;)

 

-Zahni

[nicholasdille 10]

Hallo zahni,

 

sehr guter Artikel. Den muss ich auf jeden Fall als Referenz behalten!

 

Ich denke, wir reden von unterschiedlichen Dingen und haben daher beide Recht :-)

 

Mir geht es nur um den Punkt 1 unter "Operating System Implementation and Application Support", weil es manchen meiner Kunden hilft, wenn mehr Arbeitsspeicher zur Verfügung steht. Jeder Prozess ist selbstverständlich an den Adressraum von 4GB gebunden und kann nicht mehr Speicher allozieren, selbst wenn mehr eingebaut ist.

 

In dem Punkt habe ich mich unklar ausgedrückt. Du hast natürlich Recht, dass eine Anwendung nur dann mehr als den für 32-Bit üblichen Adressraum nutzen kann, wenn spezielle APIs wie AWE genutzt werden.

 

Ich hoffe, das klärt unser Missverständnis :-)

 

Grüße!

[Forseti2003 14]

Aus der Praxis heraus kann ich nur sagen, wenn schon dann gleich die 64bit Version nutzen, gerade im Hinblick des Terminalservers. Man kann natürlich zwecks DOS-Kompatibilität zwischen R1 und R2 Candidaten wählen, aber gerade wegen dem Speicher, wie schon nicholasdille ausführt, ist es wichtig das ein Terminalserver ausreichend RAM hat um das seinen Nutzern zur Verfügung zu stellen.

 

Ansonsten beginnt ja der TS die Prozesse in die Auslagerungsdatei zu verfrachten, um seinen Speicher aufrecht zu erhalten, was mit mehr I/O auf der Festplatte verbunden ist, und die Auslagerung ist auch nicht unendlich groß.

 

Ganz vergessen, zum Topic-Thema:

 

Wenn fünf User 5x Outlook starten würde im Explorer das so stehen:

 

outlook.exe Benutzer1 0% 5.000 Bemerkung

outlook.exe Benutzer2 0% 5.000 Bemerkung

outlook.exe Benutzer3 2% 5.500 Bemerkung

outlook.exe Benutzer4 0% 4.000 Bemerkung

outlook.exe Benutzer5 0% 15.000 Bemerkung

 

sprich jede Applikation erhält einen eigenständigen Speicher- und CPU-Bereich. Ist die Summe der Anwendungen über 100% der Ressource verlangsamt sich der TS entsprechend. Jedoch shared er auch die Anwendungen mit gemeinsamen Speicherbereichen, womit ein TS Ressourcen schonender arbeitet.