Whitepaper Skalierbarkeit von 64-Bit Terminalserver

Technisches Whitepaper
Skalierbarkeit von
64-Bit Terminalserver-Plattformen
Dr. Bernhard Tritsch, Christa Anderson
www.visionapp.com
Inhalt
1
Einleitung ............................................................................................................ 2
2
Testaufbau ........................................................................................................... 3
2.1
Testumgebung .............................................................................................. 3
2.2
Testwerkzeuge und Testskripte ........................................................................ 5
2.3
Benutzerkonten anlegen ................................................................................. 5
2.4
3
4
5
2.3.1
Anwendungen installieren und Dokumente bereitstellen ........................... 6
2.3.2
Benutzersitzungen erstellen ................................................................. 7
2.3.3
Benutzerprofile und Testablauf ............................................................. 9
Testmethodik .............................................................................................. 10
Auswertung der Ergebnisse ............................................................................... 12
3.1
Testserver mit 4 GB RAM .............................................................................. 12
3.2
Testserver mit AMD CPUs und 16 GB RAM ....................................................... 14
3.3
Testserver mit Intel CPUs und 16 GB RAM ....................................................... 18
Fazit................................................................................................................... 19
4.1
Speicherbedarf steigt bei 64-Bit-Betriebssystemen ........................................... 20
4.2
PTEs sind nicht die einzige speicherrelevante Windows-Einschränkung................. 20
4.3
Bei aktuellen Hardwarepreisen sind 64-Bit-Betriebssysteme nicht unbedingt rentabel20
Anhang .............................................................................................................. 21
5.1
Ausgewertete Leistungsindikatoren................................................................. 21
5.2
Hintergrundinformationen ............................................................................. 22
5.3
Schrittweise Beschreibung eines Testlaufs ....................................................... 22
5.3.1
Steuerungsrechner einrichten............................................................. 22
5.3.2
Clients (Lastgeneratoren) einrichten.................................................... 23
5.3.3
Server einrichten.............................................................................. 23
5.3.4
Testen ............................................................................................ 24
5.3.5
Aufräumen ...................................................................................... 24
www.visionapp.com
1
1
Einleitung
Mit Microsoft Windows Terminal Services (WTS) lassen sich Windows-basierte Anwendungen
auf einer entfernten Windows Server 2003 Plattform ausführen. Die wichtigsten Vorteile von
Terminalservern sind die schnelle und zentralisierte Verteilung von Anwendungen sowie der
optimierte Zugang zu Daten bei geringer Netzwerkbandbreite. Die Produktivität der Benutzer
steigt, da der Zugang zu aktuellen Anwendungen über viele verschiedene Geräte ermöglicht
wird.
In einer serverbasierten Umgebung erfolgt die Ausführung der Anwendungen und die
Verarbeitung aller Daten auf dem Server. Aus diesem Grund ist es für Serverhersteller
sinnvoll und wünschenswert, die Skalierbarkeit und Kapazität ihrer Server zu testen, um
festzustellen, wie viele Clientsitzungen ein Server üblicherweise in verschiedenen Szenarien
bewältigen kann.
Normalerweise wird ein geplantes typisches Arbeitsszenario vor der produktiven Installation
in einer eigens eingerichteten Testumgebung simuliert. Schwerpunkt dieses Tests ist ein
realitätsnaher Vergleich zwischen 32- und 64-Bit-Serverplattformen. Die Windows Server
2003 x64 Edition mit Terminaldiensten im Applikationsservermodus ist in der Lage, die
Speicherbeschränkungen der 32-Bit-Edition zu überwinden. Dies bedeutet allerdings nicht,
dass sich die Anzahl der Terminalserver-Benutzer durch den Einsatz der 64-Bit-Technologie
auf jeden Fall und automatisch erweitern lässt. Dieses Whitepaper beschreibt zunächst die
Testumgebung und die angewendete Methodik. Danach folgen detaillierte Beschreibungen der
verschiedenen Testergebnisse. In der abschließenden Zusammenfassung werden die
Ergebnisse mit existierenden Terminalserverumgebungen verglichen.
Bitte beachten Sie, dass die hier vorgestellten Untersuchungen und Ergebnisse nicht isoliert
betrachtet werden sollten. Die im Test eingesetzten Anwendungen wurden in
Terminalserversitzungen ausgeführt und sollten lediglich einen reproduzierbaren Teil der
Serverressourcen belegen. Die Tests erfolgten unter vergleichsweise statischen Bedingungen:
Die Benutzer melden sich am System an, starten drei Anwendungen mit entsprechenden
Dokumenten und bleiben in der Folge für den Rest ihrer Sitzung inaktiv. Dadurch konnten
reproduzierbare Ergebnisse erzielt werden, die sich allerdings von Ihren eigenen Ergebnissen
unterscheiden können.
www.visionapp.com
2
2
Testaufbau
Der Testaufbau wurde von der visionapp GmbH, Systemintegrator für Terminalserversysteme
und unabhängiger Softwareanbieter, festgelegt. Die Tests wurden unter der Leitung von
erfahrenen Terminalserverspezialisten am Terminalserver-Testlabor der visionapp in Frankfurt
am Main und am Labor des Fujitsu Siemens Computers Support in Augsburg durchgeführt.
Die Testumgebung umfasste Hard- und Softwarekomponenten. Die Hardwarekomponenten
waren über ein eigens eingerichtetes lokales Netzwerk (LAN) miteinander verbunden. Mit
dieser Konfiguration wurden eventuelle Störeinflüsse durch einen nicht zur Testumgebung
gehörenden Netzwerkbetrieb vermieden.
2.1
Testumgebung
Am Terminalserver-Testlabor der visionapp wurde ein einfacher Testaufbau mit zwei
verschiedenen Servertypen eingesetzt:
> 2 Dell PowerEdge 850 Server; 1 x Intel XEON 3.0 GHz Dual-Core CPU, 2 MB Second Level
Cache, 4 GB Arbeitsspeicher.
> 10 Fujitsu Siemens Computers BX600 Blade Server, die als Clients eingesetzt wurden und
Last erzeugen sollten; 2 x Intel 2.8 GHz CPUs, 2 GB Arbeitsspeicher.
> 1 IBM T43 Notebook zur Steuerung und Überwachung des Testablaufs.
Am Labor des Fujitsu Siemens Computers Support gab es folgenden Testaufbau:
> 1 Fujitsu Siemens Computers Primergy BX630-A Server: 2 x AMD 1.8 GHz Dual-Core CPU,
16 GB Arbeitsspeicher.
> 1 Fujitsu Siemens Computers RX300S2-A Server: 2 x Intel 2.8 GHz Dual-Core CPU, 16 GB
Arbeitsspeicher.
> 10 Fujitsu Siemens Computers BX300 Blade Server, die als Clients eingesetzt wurden und
Last erzeugen sollten; 2 x Intel 933 MHz CPUs, 2 GB Arbeitsspeicher.
> 1 Fujitsu Siemens Computers E4010D Notebook zur Steuerung und Überwachung des
Testablaufs.
Hinzu kam an beiden Testlaboren eine Gigabit-Ethernet-Infrastruktur.
In nachfolgender Tabelle sind die Serversystemkomponenten zusammengefasst.
Systemkomponente
Menge
Beschreibung
Hardware-Typ
2
DELL PowerEdge 850 Server
Betriebssystem
Windows Server 2003, R2
Prozessor
1
Intel XEON 3.0 GHz Dual-Core, EM64T
Arbeitsspeicher
4
Gigabyte
Plattensubsystem
1
150 GB, Adaptec DELL Array SCSI
NIC
1
Broadcom NetXtreme Gigabit Ethernet
www.visionapp.com
3
Systemkomponente
Menge
Beschreibung
Hardware-Typ
1
FUJITSU SIEMENS RX300S2-A
Betriebssystem
Windows Server 2003, SP1
Prozessor
2
Intel 2.8 GHz Dual-Core, EM64T
Arbeitsspeicher
16
Gigabyte
Plattensubsystem
2
70 GB, LSI Logic RAID 1 SCSI
NIC
1
Broadcom NetXtreme Gigabit Ethernet
Systemkomponente
Menge
Beschreibung
Hardware-Typ
1
FUJITSU SIEMENS PRIMERGY BX630-A
Betriebssystem
Windows Server 2003, SP1
Prozessor
2
AMD 2.8 GHz Dual-Core, AMD64
Arbeitsspeicher
16
Gigabyte
Plattensubsystem
2
36 GB, LSI Logic RAID 1 SCSI
NIC
1
Broadcom NetXtreme Gigabit Fiber
Für alle während des Tests eingesetzten Serversysteme wurden mit Hilfe des
Systemprogramms msinfo32.exe die Systeminformationen dokumentiert.
www.visionapp.com
4
Abb. 1
Systeminformationen eines für die Tests eingesetzten Servers
2.2
Testwerkzeuge und Testskripte
Um die Tests zu unterstützen, hat visionapp eine Reihe von Werkzeugen und Skripten
entwickelt, die auf den verschiedenen Client- und Serverrechnern eingesetzt wurden.
2.3
Benutzerkonten anlegen
Vor dem Beginn der Tests mussten auf jeder Serverplattform 250 lokale Benutzer angelegt
werden. Diese Testbenutzerkonten wurden mittels eines Visual Basic Skripts der lokalen
Benutzergruppe und der Gruppe "Remote Desktop Users" hinzugefügt.
www.visionapp.com
5
nMaxUsers = 401
strPassword = "BigIron2006_!"
Set objComputer = CreateObject("Shell.LocalMachine")
strComputer = objComputer.MachineName
Wscript.Echo "Computer name: " & strComputer
Wscript.Echo "Multiple users enabled: " & objComputer.IsMultipleUsersEnabled
Wscript.Echo "Remote connections enabled: " &
objComputer.IsRemoteConnectionsEnabled
nCounter = 1
Do While nCounter < nMaxUsers
strUser = "v" & nCounter
Set colAccounts = GetObject("WinNT://" & strComputer & "")
Set objUser = colAccounts.Create("user", strUser)
objUser.SetPassword strPassword
objUser.SetInfo
wscript.Echo "User account " + strUser + " created"
Set objNewUser = GetObject("WinNT://" & strComputer & "/" & strUser &
",user")
Set objGroup = GetObject("WinNT://" & strComputer & "/Remote Desktop
Users,group")
objGroup.Add(objNewUser.ADsPath)
wscript.Echo "Added User account " + strUser + " to Remote Desktop Users
group"
Set objGroup = GetObject("WinNT://" & strComputer & "/Users,group")
objGroup.Add(objNewUser.ADsPath)
wscript.Echo "Added User account " + strUser + " to Users group"
nCounter = nCounter + 1
Loop
Abb. 2
2.3.1
Skript nuser.vbs zur Erstellung von 400 Benutzerkonten mit Windows Script Host. Das Skript
musste im Rahmen einer Benutzersession mit Administratorrechten ausgeführt werden.
Anwendungen installieren und Dokumente bereitstellen
Die für dieses Whitepaper durchgeführten Tests basieren auf dem Aufruf einer Reihe von
Anwendungen und der Öffnung von Dokumenten.
Folgende Anwendungen wurden auf den Terminalservern installiert:
www.visionapp.com
6
> Microsoft Office 2003
> Adobe Acrobat Reader 7
HINWEIS: Einzelheiten zur Feineinstellung der Anwendungen siehe „Server einrichten”.
Während der Tests wurden drei Anwendungen mit folgenden Dokumenten gestartet:
> Notepad.exe – ComputerWorld.txt: ANSI Textdatei, 8,4 KB
> Acrobat Reader – vCC_Admin_EN.pdf: Adobe Acrobat PDF-Datei, 3,8 MB
> Microsoft Word – vPMS_Inst_EN.doc: Microsoft Word-Dokument, 3,1 MB
Die Anwendungen hinterließen während der Tests einen vom jeweils geladenen Dokument
abhängigen spezifischen Speicherabdruck (Memory-Footprint). winword.exe belegte zwischen
13 und 18 MB, notepad.exe ca. 3 MB und Acrobat Reader fast 30 MB pro Session.
2.3.2
Benutzersitzungen erstellen
Während des Testablaufs wurden die Benutzersitzungen durch die Lastgeneratoren der
visionapp Remote Desktop Load Edition initiiert. Auf jedem Clientrechner waren in einer XMLDatei die IP-Adresse auf dem Zielserver und die Benutzerdaten (Name und Passwort)
definiert.
HINWEIS: Von jedem der Lastgeneratoren können problemlos bis zu 40 Benutzersitzungen
geöffnet werden.
Für diesen Testablauf wurden folgende Standardeinstellungen verwendet:
> Anzahl Lastgeneratoren pro Test: 10
> Anzahl Benutzer pro Lastgenerator: 20 bis 40
> Intervall zwischen Benutzeranmeldungen: 60 Sekunden (60.000 ms)
www.visionapp.com
7
Abb. 3
Eine Instanz der vRD Load Edition mit 20 konfigurierten und unmittelbar nach Testbeginn
angezeigten Benutzern. Es ist noch kein Testbenutzer angemeldet.
<?xml version="1.0" encoding="utf-16"?>
<vRDLoadConfigurationFile>
<Testcase ServerName="10.4.1.93">
<Domain>VAFE0SD3</Domain>
<User>v1</User>
<Password>BigIron2006_!</Password>
</Testcase>
<Testcase ServerName="10.4.1.93">
<Domain>VAFE0SD3</Domain>
<User>v2</User>
<Password>BigIron2006_!</Password>
</Testcase>
…
…
</vRDLoadConfigurationFile>
Abb. 4
XML-Beispiel für die Konfiguration der vRD Load Edition
www.visionapp.com
8
2.3.3
Benutzerprofile und Testablauf
Da es nicht möglich ist, ein und dasselbe physikalische Dokument aus mehreren
Benutzersitzungen heraus zu öffnen, mussten für alle Benutzer individuelle Dokumente
bereitgestellt werden. Zu diesem Zeck wurden individuelle Benutzerprofile verwendet, mit
deren Hilfe die benötigten Dokumente auf den jeweiligen Arbeitsplatz des Benutzers kopiert
und die dazugehörigen Anwendungen gestartet werden konnten.
Um die Benutzerprofile automatisch ohne Verwendung eines Domänencontrollers erstellen zu
lassen, wurde unter All Users dem Ordner Startup (Autostart) ein einfaches Skript
hinzugefügt. Damit sollten alle benötigten Dokumentdateien aus einer gemeinsamen Quelle
auf den Arbeitsplatz des jeweiligen Benutzers kopiert werden, sobald sich dieser anmeldet.
Nach einer Wartezeit von 10 Sekunden wurde die ASCII-Datei mit notepad.exe geöffnet.
Nach weiteren 20 Sekunden wurde die PDF-Datei mit Adobe Acrobat Reader und wiederum
nach 20 Sekunden schließlich das Word-Dokument mit Microsoft Word geöffnet.
HINWEIS: Die während des Tests erstellten Benutzerprofile waren im Schnitt 7,3 MB groß.
HINWEIS: Die Abstände zwischen den verschiedenen Aktionen im Skript wurden mit Hilfe des
Kommandozeilenwerkzeugs sleep.exe aus dem Microsoft Windows Server 2003 Resource Kit
gesteuert.
Es wurde überprüft, ob die Pfade für den Aufruf der 32-Bit-Anwendungen Adobe Acrobat
Reader und Microsoft Word korrekt gesetzt waren. Auf der 32-Bit-Plattform lautete der Pfad
C:\Program Files\, auf der 64-Bit-Plattform hingegen C:\Program Files (x86)\. Auf der
64-Bit-Plattform sah das Anmeldeskript wie folgt aus:
@echo off
if not exist "%userprofile%\Desktop\ComputerWorld.txt" copy
c:\Documents\ComputerWorld.txt "%userprofile%\Desktop"
if not exist "%userprofile%\Desktop\vCC_Admin_EN.pdf" copy
c:\Documents\vCC_Admin_EN.pdf "%userprofile%\Desktop"
if not exist "%userprofile%\Desktop\vPMS_Inst_EN.doc" copy
c:\Documents\vPMS_Inst_EN.doc "%userprofile%\Desktop"
echo Document files copied
sleep 20
start /B notepad.exe "%userprofile%\Desktop\ComputerWorld.txt"
echo Tried to launch Notepad with ComputerWorld.txt (8.4 KB)
sleep 20
start /B "C:\Program Files (x86)\Adobe\Acrobat 7.0\Reader\AcroRd32.exe"
"%userprofile%\Desktop\vCC_Admin_EN.pdf"
echo Tried to launch Acrobat Reader with vCC_Admin_EN.pdf (3.8 MB)
sleep 20
start /B "C:\Program Files (x86)\Microsoft Office\Office\WinWord.exe"
"%userprofile%\Desktop\vPMS_Inst_EN.doc"
echo Tried to launch Microsoft Word with vPMS_Inst_EN.doc (3.1 MB)
pause
Abb. 5
Skript BigIron.cmd im Ordner Startup (Autostart) unter All Users
www.visionapp.com
9
2.4
Testmethodik
Ziel des Tests war es, die maximale Anzahl Benutzer zu ermitteln, ab der sich die
Reaktionszeit eines Terminalservers mit beschränkten Arbeitsspeicherressourcen auf einen
nicht mehr akzeptablen Wert verschlechtert (ca. 15 Sekunden für das Öffnen eines Fensters).
Für jedes Testszenario setzte der Testingenieur die vRD Load Edition ein, um den Testlauf
vom Steuerungsrechner aus auf jedem Lastgenerator mit visionapp Remote Desktop zu
starten. Die vRD Load Edition war so konfiguriert, dass alle 60 Sekunden automatisch ein
Benutzer angemeldet wurde. Die festgelegte Reihenfolge der Anwendungsaufrufe wurde über
ein einfaches Skript im Ordner Startup (Autostart) unter All Users gesteuert.
> 10 Sekunden nach erfolgreicher Benutzeranmeldung: Notepad.exe –
ComputerWorld.txt: ANSI-Textdatei, 8,4 KB
> 30 Sekunden nach erfolgreicher Benutzeranmeldung: Acrobat Reader –
vCC_Admin_EN.pdf: Adobe Acrobat PDF-Datei, 3,8 MB
> 50 Sekunden nach erfolgreicher Benutzeranmeldung: Microsoft Word –
vPMS_Inst_EN.doc: Microsoft Word-Dokument, 3,1 MB
Durch den gleichzeitigen Einsatz von 10 Lastgeneratoren und den Start der Testreihen auf
den einzelnen Lastgeneratoren in einem Abstand von nur einigen Sekunden, melden sich 10
Benutzer innerhalb von rund 20 Sekunden an. Nach einer Minute melden sich weitere 10
Benutzer am System an, bis der Testlauf beendet ist – nach 20 oder 40 Testbenutzern pro
Lastgenerator.
www.visionapp.com
10
Abb. 6
Typische Situation, nachdem sich ein Testbenutzer angemeldet und drei Dateien mit Notepad,
Adobe Acrobat Reader bzw. Microsoft Word geöffnet hat.
Jede Benutzersitzung produzierte einen Speicherabdruck von ca. 60 MB, nachdem alle
Anwendungen gestartet worden waren.
Während des gesamten Ablaufs wurden folgende Leistungsindikatoren (Performance Counter)
überwacht und protokolliert:
>
>
>
>
>
>
>
>
>
>
>
Speicher: Available MBytes (Verfügbare MBytes)
Speicher: Free System Page Table Entries (Freie Seitentabelleneinträge)
Speicher: Page Faults/sec (Seitenfehler/s)
Speicher: Pages/sec (Seiten/s)
Speicher: Pool Nonpaged Bytes (Nicht-Auslagerungsseiten, Bytes)
Speicher: Pool Paged Bytes (Auslagerungsseiten, Bytes)
Festplatte: Avg. Disk Queue Length (Durchschnittliche Warteschlangenlänge)
Prozess: Working Set (Arbeitsmenge)
Prozessor: % Interrupt Time (Interruptzeit, %)
Prozessor: % Processor Time (Prozessorzeit, %)
Prozessor: Interrupts/sec (Interrupts/s)
www.visionapp.com
11
>
>
>
>
>
>
Server: Pool Nonpaged Bytes (Nicht-Auslagerungsseiten, Bytes)
Server: Pool Paged Bytes (Auslagerungsseiten, Bytes)
System: Context Switches/sec (Kontextwechsel/s)
System: Processes (Prozesse)
System: Processor Queue Length (Prozessor Warteschlangenlänge)
Terminaldienste: Active Sessions (Aktive Sitzungen)
HINWEIS: Für die Sammlung der Systeminformationen haben die Testingenieure auf dem
Server Windows Performance Monitor eingesetzt.
HINWEIS: Um einen einheitlichen Ausgangszustand sicherzustellen, wurden vor jeder
Wiederholung eines Tests alle Testbenutzerprofile gelöscht und alle Systeme neu gestartet.
3
Auswertung der Ergebnisse
3.1
Testserver mit 4 GB RAM
Beim ersten Test wurden auf einem DELL PowerEdge 850 Server mit einem Intel XEON 3.0
GHz Dual-Core Prozessor und 4 GB Arbeitsspeicher die 64- und 32-Bit-Versionen von
Windows Server 2003 R2 miteinander verglichen. Auf jedem Testsystem wurden pro Minute
10 weitere Benutzer angemeldet, bis die Systemressourcen erschöpft waren.
64-Bit – Windows Server 2003 x64
2 Intel CPU-Kerne, 4 GB RAM
32-Bit – Windows Server 2003
2 Intel CPU-Kerne, 4 GB RAM
Terminal Services\Active Sessions
Memory\Available MBytes
13:36:25
13:34:35
13:32:45
13:30:55
13:29:05
13:27:15
13:25:25
13:23:35
13:21:45
13:19:54
13:18:04
13:16:14
13:14:24
13:12:34
13:10:44
13:34:45
13:36:25
13:33:05
13:29:45
13:31:25
13:28:05
13:26:25
13:23:05
13:24:45
13:21:25
13:18:04
13:19:44
13:16:24
13:13:04
13:14:44
13:11:24
13:09:44
13:06:24
13:08:04
13:04:44
13:01:24
13:03:04
4:19:53
4:18:23
4:16:53
4:15:23
4:13:53
4:12:23
4:10:41
4:09:11
4:07:41
4:06:11
0
4:04:41
500
0
4:03:11
1,000
500
4:01:41
1,500
1,000
4:00:11
2,000
1,500
3:58:41
2,500
2,000
3:57:11
3,000
2,500
3:55:41
3,500
3,000
3:54:11
4,000
3,500
12:59:44
Memory\Available MBytes
4,000
www.visionapp.com
13:08:54
13:07:04
13:05:14
13:03:24
12:59:44
4:19:53
4:18:23
4:16:53
4:15:23
4:13:53
4:12:23
4:10:41
0
4:09:11
0
4:07:41
50
4:06:11
50
4:04:41
100
4:03:11
100
4:01:41
150
4:00:11
150
3:58:41
200
3:57:11
200
3:55:41
250
3:54:11
250
13:01:34
Terminal Services\Active Sessions
12
www.visionapp.com
0
13:36:25
0
13:34:45
5,000
13:33:05
10,000
5,000
13:31:25
15,000
10,000
13:29:45
15,000
13:28:05
20,000
13:26:25
25,000
20,000
13:24:45
30,000
25,000
13:23:05
30,000
13:21:25
Memory\Page Faults/sec
13:36:25
13:34:45
13:33:05
13:31:25
13:29:45
13:28:05
13:26:25
13:24:45
13:23:05
13:21:25
0
13:19:44
50
0
13:19:44
100
50
13:18:04
150
100
13:18:04
200
150
13:16:24
250
200
13:16:24
300
250
13:14:44
350
300
13:14:44
350
13:13:04
System\Processor Queue Length
13:13:04
13:36:25
13:34:35
13:32:45
13:30:55
13:29:05
13:27:15
13:25:25
13:23:35
13:21:45
13:19:54
13:18:04
13:16:14
13:14:24
13:12:34
13:10:44
0
13:11:24
20
0
13:08:54
40
20
13:11:24
Processor\% Processor Time
13:09:44
40
13:07:04
13:33:05
13:34:45
13:36:25
13:19:44
13:21:25
13:23:05
13:24:45
13:26:25
13:28:05
13:29:45
13:31:25
13:08:04
13:09:44
13:11:24
13:13:04
13:14:44
13:16:24
13:18:04
0
13:09:44
2,000,000,000
0
13:08:04
4,000,000,000
2,000,000,000
13:08:04
4,000,000,000
13:06:24
12:59:44
13:01:24
13:03:04
13:04:44
13:06:24
6,000,000,000
13:05:14
60
13:03:24
8,000,000,000
6,000,000,000
13:06:24
8,000,000,000
13:04:44
10,000,000,000
13:04:44
4:19:53
4:18:23
4:16:53
4:15:23
4:13:53
4:12:23
4:10:41
4:09:11
4:07:41
4:06:11
4:04:41
4:03:11
4:01:41
4:00:11
3:58:41
3:57:11
3:55:41
3:54:11
10,000,000,000
13:03:04
60
13:01:34
80
13:03:04
12:59:44
80
13:01:24
12:59:44
4:19:23
4:17:43
4:16:03
4:14:23
4:12:43
4:10:51
4:09:11
4:07:31
4:05:51
4:04:11
4:02:31
4:00:51
3:59:11
3:57:31
3:55:51
3:54:11
100
13:01:24
4:19:53
4:18:23
4:16:53
4:15:23
4:13:53
4:12:23
4:10:41
4:09:11
4:07:41
4:06:11
4:04:41
4:03:11
4:01:41
4:00:11
3:58:41
3:57:11
3:55:41
3:54:11
100
12:59:44
4:19:23
4:17:43
4:16:03
4:14:23
4:12:43
4:10:51
4:09:11
4:07:31
4:05:51
4:04:11
4:02:31
4:00:51
3:59:11
3:57:31
3:55:51
3:54:11
Process (_Total)\Working Set (in Bytes)
Process (_Total)\Working Set (in Bytes)
Processor\% Processor Time
System\Processor Queue Length
Memory\Page Faults/sec
13
Physical Disk\Avg. Disk Queue Length
159 aktive Sitzungen
1.100 Prozesse
102 x Command Shell
99 x Notepad
98 x Acrobat Reader
86 x Microsoft Word
13:36:25
13:34:45
13:33:05
13:31:25
13:29:45
13:28:05
13:26:25
13:24:45
13:23:05
13:21:25
13:19:44
13:18:04
13:16:24
13:14:44
13:13:04
13:11:24
13:09:44
13:08:04
13:06:24
13:04:44
13:03:04
12:59:44
4:19:53
4:18:23
4:16:53
4:15:23
4:13:53
4:12:23
4:10:41
4:09:11
4:07:41
4:06:11
0
4:04:41
10
0
4:03:11
20
10
4:01:41
30
20
4:00:11
40
30
3:58:41
50
40
3:57:11
60
50
3:55:41
70
60
3:54:11
70
13:01:24
Physical Disk\Avg. Disk Queue Length
200 aktive Sitzungen
1.400 Prozesse
125 x Command Shell
123 x Notepad
118 x Acrobat Reader
112 x Microsoft Word
Auf dem 32-Bit x86 Windows-System wurden rund 20% mehr aktive Sitzungen geöffnet und
Anwendungen erfolgreich gestartet. Die Erklärung für dieses Phänomen liegt auf der Hand:
Der Aufruf einer Anwendung unter x64-Windows erfordert mehr Arbeitsspeicher als unter
x86-Windows.
Ein Grund hierfür liegt im WOW64-Subsystem, das eine hochleistungsfähige 32-Bit-WindowsUmgebung erstellt, die x64-Windows erlaubt, 32-Bit-Anwendungen ohne Modifikationen
auszuführen. Aber auf einem x64-Windows-System benötigen die 32-Bit-Programme mehr
Arbeitsspeicher, weil ihre Daten in 64-Bit-Strukturen abgelegt werden. Die Ablage von 32-BitDaten in 64-Bit-Datenstrukturen ist deutlich speicherintensiver als die Ablage in 32-BitDatenstrukturen.
Das Gleiche gilt für 64-Bit-Anwendungen. Deren Daten sind intern in 64-Bit-Strukturen
organisiert, und die erfordern mehr Platz als die gleichen Daten in 32-Bit-Strukturen. So
benötigt beispielsweise die 32-Bit-Version von Notepad üblicherweise 2,5 MB Arbeitsspeicher
auf x86-Windows, während die 64-Bit-Version auf x64-Windows 4,8 MB Arbeitsspeicher
belegt.
Der höhere Speicherbedarf ist der Grund, warum die Ressourcen des 64-Bit-Systems früher
erschöpft sind als die des 32-Bit-Systems. Auf beiden Systemen wird der verfügbare Speicher
so weit wie möglich durch den Memory Manager optimiert, aber ab einem gewissen Zeitpunkt
ist physikalisch kein Speicher mehr verfügbar, wodurch das Paging in hohem Maße auf der
Festplatte erfolgt.
Bei den wichtigsten Leistungsindikatoren zeigen sich im Vergleich der beiden Systeme keine
wesentlichen Unterschiede.
3.2
Testserver mit AMD CPUs und 16 GB RAM
Bei diesem Test wurden die 64- und 32-Bit-Versionen von Windows Server 2003 auf einem
Fujitsu Siemens Primergy BX630-A mit 2 AMD 2.8 GHz Dual-Core Prozessoren und 16 GB
Arbeitsspeicher miteinander verglichen. Wie bei dem vorherigen Test wurden auf jedem
System solange 10 weitere Benutzer angemeldet bis die Systemressourcen erschöpft waren.
www.visionapp.com
14
www.visionapp.com
% Processor Time
100
90
80
70
60
50
40
30
20
10
0
11:40:21
11:37:21
11:34:21
11:31:21
11:40:21
11:37:21
11:34:21
11:31:21
11:28:21
11:28:21
% Processor Time
11:25:02
0
11:21:31
5,000,000,000
0
11:18:31
10,000,000,000
5,000,000,000
11:25:02
15,000,000,000
10,000,000,000
11:15:31
20,000,000,000
15,000,000,000
11:21:31
25,000,000,000
20,000,000,000
11:12:31
30,000,000,000
25,000,000,000
11:18:31
30,000,000,000
11:09:31
Working Set
11:15:31
11:40:21
11:37:21
11:34:21
11:31:21
11:28:21
11:25:02
11:21:31
11:18:31
11:15:31
11:12:31
0
11:09:31
0
11:06:31
4,000
2,000
11:12:31
4,000
2,000
11:06:31
8,000
6,000
11:03:31
8,000
6,000
11:09:31
12,000
10,000
11:03:31
Available MBytes
11:00:31
12,000
10,000
10:57:31
16,000
14,000
11:40:21
11:37:21
11:34:21
11:31:21
11:28:21
11:25:02
11:21:31
11:18:31
11:15:31
11:12:31
11:09:31
11:06:31
11:03:31
11:00:31
Active Sessions
11:06:31
18,000
16,000
14,000
11:00:31
18,000
10:54:31
0
10:57:31
50
0
10:57:31
100
50
11:03:31
10:51:31
150
100
11:00:31
200
150
10:54:31
250
200
10:54:31
10:51:31
19:06:17
19:03:17
19:00:17
18:56:27
18:53:08
18:50:04
18:47:04
18:44:04
18:41:04
18:38:04
18:35:04
18:32:04
18:29:04
300
250
10:57:31
100
90
80
70
60
50
40
30
20
10
0
10:51:31
19:06:17
19:03:17
19:00:17
18:56:27
18:53:08
18:50:04
18:47:04
18:44:04
18:41:04
18:38:04
18:35:04
18:32:04
18:29:04
18:26:04
18:23:04
350
300
10:54:31
19:06:17
19:03:17
19:00:17
18:56:27
18:53:08
18:50:04
18:47:04
18:44:04
18:41:04
18:38:04
18:35:04
18:32:04
18:29:04
18:26:04
18:23:04
18:26:04
18:23:04
350
10:51:31
19:06:17
19:03:17
19:00:17
18:56:27
18:53:08
18:50:04
18:47:04
18:44:04
18:41:04
18:38:04
18:35:04
18:32:04
18:29:04
18:26:04
18:23:04
64-Bit – Windows Server 2003 x64
4 AMD CPU-Kerne, 16 GB RAM
32-Bit – Windows Server 2003
4 AMD CPU-Kerne, 16 GB RAM
Active Sessions
Available MBytes
Working Set
15
www.visionapp.com
Page Reads/sec
350
350
300
300
250
250
200
200
150
150
100
100
50
50
0
0
11:37:21
11:40:21
11:40:21
11:40:21
11:34:21
11:37:21
11:37:21
11:37:21
11:40:21
11:31:21
11:34:21
11:34:21
11:34:21
11:28:21
11:28:21
11:25:02
11:21:31
11:18:31
11:15:31
11:12:31
11:09:31
11:06:31
11:31:21
11:25:02
11:21:31
11:18:31
11:15:31
11:12:31
11:09:31
11:06:31
11:03:31
11:00:31
10:57:31
11:31:21
Page Reads/sec
11:31:21
Avg. Disk Queue Length
11:28:21
0
11:03:31
Page Faults/sec
11:28:21
1
0
11:25:02
2
1
11:25:02
3
2
11:21:31
4
3
11:21:31
5
4
11:18:31
6
5
11:18:31
6
11:15:31
Avg. Disk Queue Length
11:15:31
0
11:12:31
5,000
0
11:12:31
10,000
5,000
11:09:31
15,000
10,000
11:09:31
20,000
15,000
11:06:31
25,000
20,000
11:00:31
Page Faults/sec
11:06:31
30,000
25,000
11:03:31
35,000
30,000
11:03:31
40,000
35,000
10:57:31
0
11:00:31
50
0
11:00:31
100
50
10:54:31
150
100
10:54:31
200
150
10:57:31
10:51:31
250
200
10:57:31
40,000
10:51:31
19:06:17
19:03:17
19:00:17
18:56:27
18:53:08
18:50:04
18:47:04
18:44:04
18:41:04
18:38:04
18:35:04
18:32:04
18:29:04
18:26:04
18:23:04
300
250
10:54:31
19:06:17
19:03:17
19:00:17
18:56:27
18:53:08
18:50:04
18:47:04
18:44:04
18:41:04
18:38:04
18:35:04
18:32:04
18:29:04
18:26:04
18:23:04
350
300
10:54:31
10:51:31
19:06:17
19:03:17
19:00:17
18:56:27
18:53:08
18:50:04
18:47:04
18:44:04
18:41:04
18:38:04
18:35:04
18:32:04
18:29:04
18:26:04
18:23:04
350
10:51:31
19:06:17
19:03:17
19:00:17
18:56:27
18:53:08
18:50:04
18:47:04
18:44:04
18:41:04
18:38:04
18:35:04
18:32:04
18:29:04
18:26:04
18:23:04
Processor Queue Length
Processor Queue Length
16
www.visionapp.com
20,000,000
0
0
% Interrupt Time
5
5
4
4
3
3
2
2
1
1
0
0
11:39:01
40,000,000
20,000,000
11:36:41
60,000,000
40,000,000
11:34:21
80,000,000
60,000,000
11:32:01
80,000,000
11:29:41
120,000,000
100,000,000
11:27:21
140,000,000
120,000,000
100,000,000
11:24:38
160,000,000
140,000,000
11:21:51
180,000,000
160,000,000
11:19:31
200,000,000
180,000,000
11:17:11
11:34:51
11:37:41
11:40:31
11:35:01
11:37:41
11:40:21
11:29:11
11:26:21
11:22:42
11:19:51
11:17:01
11:14:11
11:11:21
11:08:31
11:05:41
11:02:51
11:00:01
11:32:01
Pool Nonpaged Bytes
11:32:21
11:29:41
11:27:01
11:23:53
11:20:51
11:18:11
11:15:31
11:12:51
Pool Nonpaged Bytes
11:10:11
0
11:14:51
200,000,000
0
11:07:31
400,000,000
200,000,000
11:12:31
600,000,000
400,000,000
11:10:11
800,000,000
600,000,000
11:04:51
1,000,000,000
800,000,000
11:02:11
1,200,000,000
1,000,000,000
10:57:11
Pool Paged Bytes
11:07:51
1,400,000,000
1,200,000,000
11:05:31
1,600,000,000
1,400,000,000
10:59:31
1,800,000,000
1,600,000,000
10:56:51
1,800,000,000
11:03:11
200,000,000
11:40:21
11:37:21
11:34:21
11:31:21
11:28:21
11:25:02
11:21:31
11:18:31
11:15:31
11:12:31
11:09:31
11:06:31
11:03:31
11:00:31
10:57:31
10:54:31
16,400,000
10:54:21
16,450,000
10:54:11
16,500,000
11:00:51
10:51:31
16,550,000
10:51:31
16,600,000
10:51:31
16,650,000
10:58:31
19:06:17
19:03:17
19:00:17
18:56:27
18:53:08
18:50:04
18:47:04
18:44:04
18:41:04
18:38:04
18:35:04
18:32:04
18:29:04
18:26:04
18:23:04
16,700,000
10:56:11
19:06:17
19:03:57
19:01:37
18:58:27
18:56:02
18:53:28
18:51:05
18:48:44
18:46:24
18:44:04
18:41:44
18:39:24
18:37:04
18:34:44
18:32:24
18:30:04
18:27:44
18:25:24
18:23:04
16,750,000
10:53:51
19:06:17
19:03:57
19:01:37
18:58:27
18:56:02
18:53:28
18:51:05
18:48:44
18:46:24
18:44:04
18:41:44
18:39:24
18:37:04
18:34:44
18:32:24
18:30:04
18:27:44
18:25:24
18:23:04
16,800,000
10:51:31
19:06:17
19:04:17
19:02:17
19:00:17
18:57:27
18:55:22
18:53:08
18:51:05
18:49:04
18:47:04
18:45:04
18:43:04
18:41:04
18:39:04
18:37:04
18:35:04
18:33:04
18:31:04
18:29:04
18:27:04
18:25:04
18:23:04
Free System PTEs
Free System PTEs
200,000
180,000
160,000
140,000
120,000
100,000
80,000
60,000
40,000
20,000
0
Pool Paged Bytes
% Interrupt Time
17
Interrupts/sec
Interrupts/sec
20,000
20,000
15,000
322 aktive Sitzungen
2.900 Prozesse
264 x Command Shell
261 x Notepad
256 x Acrobat Reader
252 x Microsoft Word
11:39:51
11:37:21
11:34:51
11:32:21
11:29:51
11:27:21
11:24:28
11:21:31
11:19:01
11:16:31
11:14:01
11:11:31
11:09:01
11:06:31
11:04:01
11:01:31
10:59:01
10:56:31
10:51:31
19:05:27
19:03:17
19:01:07
18:58:07
18:55:52
18:53:28
18:51:15
18:49:04
18:46:54
18:44:44
18:42:34
18:40:24
18:38:14
18:36:04
18:33:54
0
18:31:44
0
18:29:34
5,000
18:27:24
5,000
18:25:14
10,000
18:23:04
10,000
10:54:01
15,000
319 aktive Sitzungen
2.800 Prozesse
243 x Command Shell
243 x Notepad
243 x Acrobat Reader
237 x Microsoft Word
Hier wurde auf beiden Systemen eine annähernd gleiche Anzahl von aktiven Sitzungen
gestartet, jedoch auf dem x86-Windows-System rund 10% weniger Anwendungen.
Bei den Leistungsindikatoren zeigen sich deutliche Unterschiede hinsichtlich des verfügbaren
Speichers. Auf dem x64-Windows-System war der Speicher fast vollständig aufgebraucht,
während x86-Windows nur etwas mehr als die Hälfte des verfügbaren Speichers nutzen
konnte. In dem Augenblick (11:15:31), als es für x86-Windows schwieriger wurde, den
verfügbaren Speicher zu nutzen, wiesen auch die durchschnittliche Länge der
Festplattenwarteschlange (Avg. Disk Queue Length) und die Zahl der Seitenlesevorgänge
(Page Reads/sec) einen deutlichen Anstieg auf. Gleichzeitig konnte auf x86-Windows eine
deutliche Leistungsverschlechterung für den Benutzer beobachtet werden, die dazu führte,
dass Anwendungsfenster nur sehr langsam geöffnet werden.
Sobald auf dem 32-Bit-System keine freien Seitentabelleneinträge (System PTEs) mehr zur
Verfügung stehen, können sich keine Benutzer mehr anmelden. Diesen Begrenzungsfaktor
gibt es bei 64-Bit-Systemen nicht mehr. Aber mit "nur" 16 GB RAM erzeugt dies keinen
wirklich entscheidenden Unterschied hinsichtlich der Anzahl der Benutzer, die sich anmelden
können – auch wenn die letzten 20-30% der auf dem 32-Bit-Rechner angemeldeten Benutzer
nicht viel mit ihrer Sitzung anfangen können. Für diese Benutzer wird in der Regel noch nicht
einmal die Shell geladen.
3.3
Testserver mit Intel CPUs und 16 GB RAM
Bei diesem Test wurden die 64- und 32-Bit-Versionen von Windows Server 2003 auf einem
Fujitsu Siemens Primergy RX300S2-A mit 2 Intel 2.8 GHz Dual-Core Prozessoren und 16 GB
Arbeitsspeicher miteinander verglichen. Während des eines Testlaufs war das HyperThreading der CPU deaktiviert, während des anderen Testlaufs aktiviert. Wie bei dem
vorherigen Test wurden auf jedem System solange 10 weitere Benutzer angemeldet bis die
Systemressourcen erschöpft waren.
64-Bit – Windows Server 2003 x64
4 Intel CPU-Kerne, 16 GB RAM
www.visionapp.com
64-Bit – Windows Server 2003
4 Intel CPU-Kerne, HT, 16 GB RAM
18
4
www.visionapp.com
270 aktive Sitzungen
2.500 Prozesse
228 x Command Shell
223 x Notepad
222 x Acrobat Reader
214 x Microsoft Word
60
40
20
0
15:12:14
15:12:14
15:04:38
15:04:38
15:10:24
15:02:20
15:02:20
15:10:24
14:58:29
14:58:29
15:06:30
14:56:13
14:56:13
15:06:30
14:54:18
14:50:38
14:48:48
14:46:58
14:45:08
14:43:18
14:41:28
14:39:38
14:37:48
14:35:58
14:34:08
14:32:18
14:30:28
14:54:18
140
120
100
80
60
40
20
0
14:52:28
Page Reads/sec
14:52:28
14:50:38
80
14:48:48
100
14:46:58
120
14:45:08
Page Reads/sec
14:43:18
140
14:41:28
0
14:28:38
Avg. Disk Queue Length
14:39:38
2
0
14:37:48
4
2
14:35:58
6
4
14:34:08
8
6
14:32:18
10
8
14:30:28
12
10
14:26:48
12
14:28:38
16:38:57
16:36:57
16:34:57
16:32:57
16:30:57
16:28:57
16:26:57
16:24:36
16:22:35
16:20:35
16:18:35
16:16:35
16:14:35
16:12:35
16:10:35
16:08:35
16:06:35
16:04:35
16:02:35
16:00:35
15:58:35
15:56:35
341 aktive Sitzungen
2.900 Prozesse
252 x Command Shell
241 x Notepad
238 x Acrobat Reader
231 x Microsoft Word
Die Ergebnisse weisen gewisse Unterschiede zwischen aktiviertem und deaktiviertem HyperThreading auf. Die allgemeine Tendenz hinsichtlich der Skalierbarkeit von x64-Windows ist
aber die gleiche.
Fazit
Der ursprüngliche Zweck der Tests bestand darin, das Verhalten einer 64-Bit-Serverhardware
bei starker Beanspruchung durch Terminalserver-Benutzersitzungen zu überprüfen – unter
der 32-Bit-Version und unter der 64-Bit-Version von Windows Server 2003. Aus den Tests
haben wir die nachfolgenden Schlüsse gezogen.
19
15:12:04
15:10:14
15:06:20
15:04:28
15:02:10
14:58:19
14:56:03
14:54:08
14:52:18
14:50:28
14:48:38
14:46:48
14:44:58
14:43:08
14:41:18
14:39:28
14:37:38
14:35:48
14:33:58
14:32:08
14:30:18
14:28:28
14:26:38
16:38:47
16:36:47
16:34:47
16:32:47
16:30:47
16:28:47
16:26:47
16:24:26
16:22:25
16:20:25
16:18:25
16:16:25
16:14:25
16:12:25
16:10:25
16:08:25
16:06:25
16:04:25
16:02:25
16:00:25
15:58:25
15:56:25
18,000
16,000
14,000
12,000
10,000
8,000
6,000
4,000
2,000
0
14:26:48
16:38:47
16:36:47
16:34:47
16:32:47
16:30:47
16:28:47
16:26:47
16:24:26
16:22:25
16:20:25
16:18:25
16:16:25
16:14:25
16:12:25
16:10:25
16:08:25
16:06:25
16:04:25
16:02:25
16:00:25
15:58:25
15:56:25
Available MBytes
Available MBytes
18,000
16,000
14,000
12,000
10,000
8,000
6,000
4,000
2,000
0
Avg. Disk Queue Length
4.1
Speicherbedarf steigt bei 64-Bit-Betriebssystemen
Bei einem Einsatz der 64-Bit-Version von Terminal Server kann der Speicherbedarf insgesamt
bis zu doppelt so hoch ausfallen wie bei gleicher Arbeitslast unter einer 32-Bit-Version von
Microsoft Windows Server 2003. Die Datenstrukturen sind umfangreicher, weil insbesondere
die Pointer doppelt so groß sind und der Dateicache des Systems mehr Speicher belegt. Auf
einem 4-GB-System hat x64-Windows schlechter abgeschnitten als x86-Windows.
4.2
PTEs sind nicht die einzige speicherrelevante WindowsEinschränkung
Eine der Sitzungsengpässe in Terminal Services ist die Verfügbarkeit von
Seitentabelleneinträgen (Page Table Entries - PTEs). PTEs bilden den Paged Pool
(Arbeitsspeicherbereich für Objekte, die seitenweise auf die Festplatte ausgelagert werden
können) im Adressraum ab. Wenn dem Betriebssystem die PTEs ausgehen, kann es keine
Prozesse mehr erstellen und wird instabil. Da das 32-Bit-Windows nur 900 MB Speicher für
PTEs reserviert und ein Terminalserver naturgemäß prozessintensiv ist, sind PTEs ein knapp
bemessenes Gut. Das 64-Bit-Windows löst diesen Engpass, indem es für PTEs 128 GB
Speicher zuweist.
Davon abgesehen konnten wir auch mit 16 GB Arbeitspeicher keine entscheidenden
Unterschiede in der Anzahl der Sitzungen beobachten, die ein Terminalserver erstellen kann.
Möglicherweise war der 64-Bit-Server in der Lage, mehr verwendbare Sitzungen zu erstellen,
da für die letzten 20-30% der auf der 32-Bit-Plattform erstellten Sitzungen mangels
Ressourcen ggf. noch nicht einmal die Shell geladen wurde. Leider ist dies aber reine
Spekulation, da Windows keine Performance Counter für das Testen der Benutzerantwortzeit
bietet. Aber auch ohne diese Daten zeigt die Studie, dass die PTEs nur ein Faktor von
mehreren sind, die eine Beschränkung der Anzahl der Sitzungen bewirken.
4.3
Bei aktuellen Hardwarepreisen sind 64-Bit-Betriebssysteme
nicht unbedingt rentabel
Wie bereits festgestellt, konnten wir bezüglich der Anzahl der verwendbaren Sitzungen keine
nennenswerten Unterschiede zwischen einem 32-Bit-Server und einem 64-Bit-Server
beobachten, auch nicht mit 16 GB Arbeitsspeicher. (Zwar konnte der 64-Bit-Server mit 16 GB
Arbeitsspeicher mehr Sitzungen – 341 gegenüber 270 – öffnen als der 32-Bit-Server, aber bei
den rund letzten 100 Sitzungen war er nicht mehr in der Lage, Microsoft Word, Adobe Acrobat
und Notepad aufzurufen.) Es muss klar gesagt werden, dass eine reine Aufrüstung des
Arbeitsspeichers eines Servers allein nicht ausreicht, um ein 64-Bit-Bietriebssystem
leistungsfähiger zu machen.
Die Leistungsvorteile eines 64-Bit-Windows-Systems lassen sich voraussichtlich nur mit neuer
Hardware erzielen. Laut Untersuchungen, die von Microsoft durchgeführt wurden und in ihrem
Whitepaper über 64-Bit-Skalierbarkeit beschrieben werden, zeigen sich die Leistungsvorteile
eines 64-Bit-Betriebssystems auf einem 64-Bit-System mit 24 GB oder mehr Arbeitsspeicher,
und da wird es auch langsam kostspielig. Die Hardwarepreise werden aber - wie sonst auch
nach der Einführung einer neuen Technologie - voraussichtlich fallen. Dann werden 64-BitBetriebssysteme auch in finanzieller Hinsicht sinnvoller sein. Während die Server sehr teuer
sind, wird die Anwenderbasis durch die Zusammenfassung vieler Benutzer auf einem einzigen
Server zudem einem höheren Risiko (da die Gesamtzahl der Server mit Lastverteilung
geringer ist) und höheren Kosten für die Bereithaltung von Reservekapazitäten ausgesetzt.
www.visionapp.com
20
Obgleich sich mit einem 64-Bit-Betriebssystem mehr Benutzer gleichzeitig an einem einzelnen
Anwendungsserver anmelden können (eine IBM-Studie geht davon aus, dass sich
möglicherweise über 600 Benutzer an einen einzelnen Server mit 64 GB Arbeitsspeicher
anmelden können), ist es wichtig zu erkennen, dass die Risiken der Serverkonsolidierung in
einer Serverfarm nicht verschwunden sind. Eine geringere Anzahl von Servern bedeutet auch,
dass bei einem Ausfall eines Servers ein größerer Anteil der Rechnerkapazität verloren geht.
Folglich könnte es sinnvoller sein, 64-Bit-Server dazu einzusetzen, die Anzahl der möglichen
Benutzer in Ihrer Farm zu erhöhen – und nicht, um die Farm entsprechend der aktuellen
Benutzerzahl zu verkleinern.
5
5.1
Anhang
Ausgewertete Leistungsindikatoren
Terminal Services\Active Sessions: (Terminaldienste\Aktive Sitzungen). Anzahl der
aktiven Terminaldienstsitzungen.
Memory\Committed Bytes: (Speicher\Zugesicherte Bytes). Zugesicherter virtueller
Speicher in Bytes. Zugesicherter Speicher ist physikalischer Speicher, für den in
Auslagerungsdateien Speicherplatz reserviert wurde. Es können eine oder mehrere
Auslagerungsdateien auf jedem physikalischem Laufwerk vorhanden sein. Dieser Indikator
zeigt nur den letzten Wert an, keinen Durchschnittswert.
Memory\Available MBytes: (Speicher\Verfügbare MBytes). Für Prozesse oder für die
Systemverwendung verfügbarer physikalischer Speicher in MB. Dies ist gleich der
Speichersumme, die Standby- (zwischengespeichert), freien und Nullseitenlisten (Standby
Page List, Free Page List, Zero Page List) zugeordnet ist.
Process\Working Set: (Prozessor\Arbeitsmenge) Gibt die aktuelle Größe (in Bytes) des
Working Set dieses Prozesses an. Der Working Set enthält alle nicht ausgelagerten
Speicherseiten, auf die der Prozess in letzter Zeit zugegriffen hat. Wenn der freie Speicher im
Rechner über einem Schwellwert liegt, bleiben die Seiten im Working Set eines Prozesses,
auch wenn sie nicht verwendet werden. Wenn der freie Speicher unter den Schwellwert fällt,
werden aus den Working Sets Seiten entfernt. Bei Bedarf werden sie über ein Soft Page Fault
wieder dem Working Set zugeordnet, bevor sie den Hauptspeicher verlassen.
Processor\% Processor Time: (Prozessor\% Prozessorzeit). Prozentuale Angabe der
vergangenen Prozessorzeit, die zum Ausführen eines Threads benötigt wird, der sich nicht im
Leerlauf befindet. Dieser Leistungsindikator ist die primäre Anzeige der Prozessoraktivität. Die
Zeitspanne, die der Prozessor benötigt, um den Thread des Leerlaufprozesses in jedem
Abtastintervall auszuführen, wird von 100% subtrahiert. (Jeder Prozessor besitzt einen
Leerlaufthread, der Zyklen belegt, wenn keine anderen Threads ausgeführt werden können.)
Der Leistungsindikator zeigt die durchschnittliche prozentuale Belegung während des
Abtastintervalls an, indem die Zeitspanne, die der Dienst nicht aktiv war, von 100%
subtrahiert wird.
System\Processor Queue Length: (System\Prozessor Warteschlangenlänge). Die
Anzahl der Threads in der Prozessorwarteschlange. Im Gegensatz zu den
Datenträgerindikatoren werden mit diesem Leistungsindikator nur abgeschlossene und keine
noch ausgeführten Threads gezählt. Auch wenn mehrere Prozessoren vorhanden sind, wird
eine einzelne Warteschlange für die Prozessorzeit verwendet. Wenn ein Computer über
mehrere Prozessoren verfügt, müssen Sie folglich diesen Wert durch die Anzahl der mit der
www.visionapp.com
21
Arbeitslast beschäftigten Prozessoren teilen. Eine anhaltende Prozessorwarteschlange von
weniger als 10 Threads pro Prozessor ist je nach Arbeitslast akzeptabel.
System\Context Switches/sec: (System\Kontextwechsel/s). Die Rate, mit der alle
Prozessoren von einem Thread zum anderen umgeschaltet werden. Kontextwechsel treten
auf, wenn ein ausgeführter Thread den Prozessor freiwillig aufgibt, bzw. von einem Prozess
höherer Priorität verdrängt wurde oder vom Benutzer- in der Kernelmodus wechselt, um eine
Exekutive oder einen Teilsystemdienst zu verwenden. Dies ist die Summe von
Thread\\Context Switches/sec (Thread\Kontextwechsel/s) für alle Threads, die auf
allen Prozessoren des Computers ausgeführt werden und wird in der Anzahl der Wechsel
gemessen. Es gibt Kontextwechselindikatoren für die Objekte 'System' und 'Thread'. Dieser
Leistungsindikator zeigt die Differenz zwischen den Werten in den letzten beiden
Abtastintervallen dividiert durch die Intervalldauer an.
5.2
Hintergrundinformationen
Der Prozessleistungsindikator Working Set, der auf die Instanz _Total angewendet wird, um
alle Prozesse des Systems auf einmal zu überwachen, zählt die Bytes, auf die von Threads im
Prozess zugegriffen wird. Wenn aber genügend freier Speicher im Rechner vorhanden ist,
bleiben die Seiten im Working Set eines Prozesses, auch wenn sie nicht verwendet werden.
Wenn der freie Speicher unter einen Schwellwert fällt, werden nicht verwendete Seiten aus
Working Sets entfernt.
Die präziseste Methode für die Berechnung des Speicherbedarfs pro Benutzer ist eine
Auswertung mehrerer Leistungsindikatoren (Speicher\Pages Input/sec, Speicher\Pages
Output/sec, Speicher\Available Bytes und Prozess\Working Set(Total_)) in einem Szenario mit
beschränktem Speicher. Wenn ein System über reichlich physikalischen Arbeitsspeicher
verfügt, wird die Arbeitsmenge (Working Set) anfangs schnell wachsen und im Working Set
eines Prozesses bleiben auch nicht verwendete Seiten stehen. Sobald die Größe des gesamten
Working Set an die Grenzen des physikalischen Arbeitsspeichers stößt, ist das Betriebssystem
gezwungen, die nicht verwendeten Teile des Working Sets auszulagern, bis wieder genügend
freie Seiten verfügbar sind. Diese Auslagerung der nicht verwendeten Teile des Working Sets
erfolgt, wenn die laufenden Anwendungen zusammen mehr physikalischen Arbeitsspeicher
benötigen als verfügbar ist; in dieser Situation muss das System ständig Seiten ein- und
auslagern, um die Working Sets aller Prozesse aufrecht zu erhalten. In der Terminologie der
Betriebssystemtheorie wird dies Thrashing (Seitenflattern) genannt.
5.3
5.3.1
Schrittweise Beschreibung eines Testlaufs
Steuerungsrechner einrichten
1. Installieren Sie visionapp Remote Desktop (vRD).
2. Geben Sie die notwendigen Anmeldedaten für jeden Lasterzeuger-Client und Testserver
im vRD ein: Name, Benutzername, Passwort und Domäne (= IP-Adresse des Testservers).
3. Fügen Sie die Lasterzeuger-Clients dem Ordner Connections im vRD hinzu: Name,
Servername (IP-Adresse) und clientspezifische Anmeldedaten. Lassen Sie alle anderen
Einstellungen unverändert.
4. Fügen Sie die Testserver dem Ordner Connections im vRD hinzu: Name, Servername
(IP-Adresse) und clientspezifische Anmeldedaten. Lassen Sie alle anderen Einstellungen
unverändert.
www.visionapp.com
22
5.3.2
Clients (Lastgeneratoren) einrichten
1. Installieren Sie vRD Load Edition (vRDLoad) durch Ausführung von vRDLoadSetup.msi.
2. Passen Sie die Einstellungen von .vrd XML-Dateien so an, dass sie Ihrer Testumgebung
entsprechen: Domäne (IP-Adresse des Testservers), Benutzername und Passwort.
3. Kopieren Sie die benötigten .vrd-Dateien auf die Clients.
4. Führen Sie vRD auf dem Steuerungsrechner aus und melden Sie sich auf allen Clients an.
5. Führen Sie vRD Load Edition auf den Clients aus und importieren Sie die entsprechende
.vrd-Datei.
6. Ändern Sie die Einstellungen in der vRD Load Edition, darunter das Intervall zwischen
automatischen Benutzeranmeldungen.
5.3.3
Server einrichten
1. Installieren Sie Windows Server 2003 Standard oder Enterprise Edition (English).
2. Installieren Sie Windows Server 2003 SP1 oder R2.
3. Stellen Sie die Terminaldienste auf Applikationsservermodus um und erlauben Sie
Remote-Verbindungen.
4. Führen Sie aus der Kommandozeile cscript nuser.vbs aus. Die Erstellung von 400
Benutzerkonten inklusive Eintragung in die lokale Benutzergruppe und die Gruppe
"Remote Desktop Users" kann bis zu einer Stunde dauern.
5. Installieren Sie Adobe Acrobat Reader 7.0.5.
6. Führen Sie Adobe_wisptis__Service_Uninstall.reg aus, um den Prozess Wisptis.exe
zu deaktivieren.
7. Führen Sie AcrobatDisableEulaSplashScreen.reg aus, um den Splash-Screen zu
deaktivieren.
8. Löschen Sie die Verknüpfung für den Adobe Acrobat Reader Schnellstart aus dem
Autostart-Ordner unter All Users.
9. Installieren Sie Microsoft Office Professional Edition 2003 einschließlich Service Pack 2.
10. Entfernen Sie den Word-Dialog zur Abfrage der Benutzerinitialen: als Administrator
anmelden und in den Installationsmodus wechseln. Microsoft Word starten und Fragen in
der Dialogbox beantworten. Word beenden und in den Ausführungsmodus
zurückwechseln.
11. Ctfmon.exe entfernen – Schritt 1:Rufen Sie Systemsteuerung|Software auf und
wählen Sie in der Liste der installierten Softwareprodukte Microsoft Office Professional
Edition 2003 aus. Klicken Sie auf Ändern. Im Dialogfeld Wartungsmodus|Optionen
wählen Sie Features hinzufügen oder entfernen und klicken auf Weiter. Wählen Sie
Erweiterte Anpassung von Anwendungen und klicken Sie auf Weiter. Hierdurch wird
das Dialogfeld Wählen Sie die Installationsoptionen für alle Office-Anwendungen
und -Tools aufgerufen. Klicken Sie auf das Pluszeichen (+) neben Gemeinsam
genutzte Office-Features, um diesen Eintrag zu erweitern. Klicken Sie auf das Symbol
neben Alternative Benutzereingabe, und wählen Sie dann die Option Nicht verfügbar
aus. Klicken Sie auf Aktualisieren.
12. Ctfmon.exe entfernen – Schritt 2: Öffnen Sie in der Systemsteuerung die Regions- und
Sprachoptionen. In der Registerkarte Sprachen klicken Sie auf Details… Dies ruft den
Dialog Textdienste und Eingabesprachen auf. Wählen Sie die Registerkarte Erweitert
und dort die Option Alle erweiterten Textdienste deaktivieren.
www.visionapp.com
23
13. Ctfmon.exe entfernen – Schritt 3: Führen Sie “Regsvr32 /u msimtf.dll” und “Regsvr32
/u Msctf.dll” aus der Kommandozeile aus.
14. Ctfmon.exe entfernen – Schritt 4: Starten Sie Regedit und laden Sie NTUSER.dat aus
dem Standardbenutzerprofil in die Struktur HKEY_USERS. Entfernen Sie den Eintrag
HKCU\Software\Microsoft\Windows \CurrentVersion\Run\ctfmon.exe.
15. Kopieren Sie den Ordner Dokumente auf das lokale Laufwerk C.
16. Kopieren Sie bigiron.cmd vom lokalen Ordner Dokumente nach C:\Dokumente und
Einstellungen\All Users\Startmenü\Programme\Autostart.
HINWEIS: Für 32- und 64-Bit-Plattformen existieren unterschiedliche Versionen von
bigiron.cmd.
17. Kopieren Sie die sleep.exe vom lokalen Dokumente-Ordner in den Windows-Ordner.
5.3.4
Testen
1. Führen Sie MSinfo32.exe aus und sichern Sie die Daten in einer Datei.
WICHTIG: Dies ist ein notwendiges Testergebnis!
2. Führen Sie pslist –m > C:\before.txt auf dem Server aus.
WICHTIG: Dies ist ein notwendiges Testergebnis!
3. Richten Sie das Leistungsprotokoll ein. Passen Sie zunächst den Servernamen in der Datei
LogSettings.htm im Ordner Dokumente an. Dann wählen Sie Leistung im Menü
Verwaltung. Im Leistungsmonitor rufen Sie das Kontextmenü und wählen
Leistungsprotokolle und Warnungen|Leistungsindikatorenprotokolle und dann
Neue Protokolleinstellungen von. Im Dialogfeld Öffnen wählen Sie LogSettings.htm.
Starten Sie nun das Protokoll.
4. Starten Sie die Testreihe in der vRD Load Edition auf einem Client nach dem anderen (von
vRD auf dem Steuerungsrechner).
5. Nun läuft die Testreihe. Auf dem Server sollten Sie nichts außer der Beobachtung des
Task Managers unternehmen. Sie können den Testablauf jederzeit manuell unterbrechen,
indem Sie in der vRD Load Edition auf die Schaltfläche Stopp klicken. Wenn der Test
beendet ist, werden alle Start-Schaltflächen in der vRD Load Edition wieder aktiv.
6. Stoppen Sie das Leistungsprotokoll und kopieren Sie die Protokolldatei an einen sicheren
Ort. WICHTIG: Dies ist ein notwendiges Testergebnis!
7. Führen Sie pslist –m > C:\after.txt auf dem Server aus.
WICHTIG: Dies ist ein notwendiges Testergebnis!
8. Speichern Sie die Leistungsprotokolle aller Instanzen der vRD Load Edition aus dem
Ordner Programme\visionapp\.
5.3.5
Aufräumen
1. Verwenden Sie die Terminaldienstverwaltung, um alle Benutzersitzungen vom Testserver
zu entfernen.
2. Falls die Terminaldienstverwaltung wegen Speicherbeschränkungen nicht gestartet werden
kann, zwingen Sie mit Hilfe des Task Managers einen Benutzer nach dem anderen zur
Abmeldung.
3. Wenn Sie den Server für einen weiteren Test verwenden wollen, müssen Sie alle
Benutzerprofile entfernen. Dazu rufen Sie System aus der Systemsteuerung auf. In der
Registerkarte Erweitert wählen Sie Einstellungen unter Benutzerprofile. Löschen Sie
www.visionapp.com
24
alle Benutzerprofile, die mit "v" gefolgt von einer Ziffer beginnen.
HINWEIS: Verwenden Sie Tastaturkürzel (Alt+D und Alt+Y) statt der Maus.
Impressum
Weitergabe und Gewährleistung
Die in diesem Dokument enthaltenen Informationen, Konzepte und Ideen sind Eigentum der
visionapp GmbH. Eine Weitergabe, auch in Auszügen, ohne die Zustimmung der visionapp
GmbH ist nicht gestattet und führt in jedem Falle zu rechtlichen Konsequenzen.
Alle in diesem Dokument erwähnten Marken- und Produktnamen sind Warenzeichen der
jeweiligen Rechteinhaber und werden hiermit anerkannt.
Alle Produktbeschreibungen haben lediglich allgemeinen und beschreibenden Charakter und
sind nicht als Zusicherung bestimmter Eigenschaften oder als Gewährleistungs- oder
Garantieerklärung zu verstehen. visionapp übernimmt keine ausdrückliche oder
stillschweigende Gewähr für Dokumentation.
Alle Rechte vorbehalten ©visionapp Oktober 06
Über visionapp
Die visionapp GmbH ist spezialisiert auf die Planung, Implementierung und den Betrieb von
serverbasierten Infrastruktur- und Portal-Lösungen auf Basis von Microsoft- und CitrixTechnologien. Das Unternehmen verfügt über im Markt derzeit einzigartige Produkte und
Dienstleistungen, die es ermöglichen, Windows Terminal Server-Infrastruktur zu optimieren
und kostengünstiger zu administrieren. Im Mittelpunkt stehen automatisierte Deployment
Tools (visionapp Platform Management Suite), das Zugangsportal visionapp Access Portal
sowie Consulting- und ASP-Dienstleistungen.
Das Lösungsangebot ist auf die Bedürfnisse großer und mittelständischer Unternehmen aus
den Bereichen Finanzdienstleistung, Industrie, Handel und öffentliche Verwaltungen
zugeschnitten.
Weitere Informationen
visionapp GmbH
Head Office Frankfurt
Theodor-Heuss-Allee 110
D-60486 Frankfurt am Main
web: www.visionapp.com
www.visionapp.com
25