Performance Report PRIMERGY BX620 S4

Transkript

1 Performance Report PRIMERGY BX620 S4 Version 2.1 Juni 2008 Seiten 26 Abstract In diesem Dokument sind alle Benchmarks, die für die PRIMERGY BX620 S4 durchgeführt wurden, zusammengefasst. Ferner werden die Leistungsdaten der PRIMERGY BX620 S4 mit denen anderer PRIMERGY Modelle verglichen und diskutiert. Neben den Benchmark-Ergebnissen als solchen wird jeder Benchmark und die Umgebung, in der der Benchmark durchgeführt wurde, kurz erläutert. Inhalt Technische Daten...2 SPECcpu SPECjbb StorageBench...11 OLTP SAP SD...16 Terminal Server...19 Literatur...26 Kontakt...26

2 Technische Daten PRIMERGY BX600 S3 Blade Server sind hoch skalierbare 19-Zoll Rack Systeme in 7 Höheneinheiten (HE) zur Aufnahme von bis zu 10 kompakten Dual Server Blades. Sie erfüllen in idealer Form die Anforderungen von Unternehmensrechenzentren und Internet bzw. Application Service Providern. Neben den hot-plug-fähigen Server Blades sind in eine PRIMERGY BX600 S3 zwei redundante Lüftereinheiten mit je zwei Lüftern, bis zu vier Stromversorgungsmodule mit je drei zusätzlichen Lüftern, ein KVM-Switch, zwei redundante Management Blades sowie optional bis zu vier GBit Ethernet Pass-Thru-Blades oder GBit Ethernet Switch-Blades oder GBit Ethernet Intelligent Blades sowie optional bis zu zwei FibreChannel Pass-Thru-Blades oder FibreChannel Switch- Blades oder FibreChannel Access Gateways integrierbar. Die PRIMERGY BX620 S4 Dual Server Blades verfügen über einen Intel 5000P Chipsatz, zwei Intel Xeon Prozessoren,(Dual-Core oder Quad-Core), acht DIMM-Slots für bis zu 32 GB PC2-5300F DDR2-SDRAM, einen abhängig vom verwendeten Prozessor mit 1067 oder 1333 MHz getakteten Front-Side-Bus, drei 2-Kanal GBit LAN- Controller, einen 2-Kanal SATA- oder SAS-Controller und zwei Einschübe für 2.5 Hot-plug SATA- oder SAS- Festplatten. Die PRIMERGY Server Management Lösung ServerView (optional mit Deploment Manager und Remote Management) erleichtert die Installation, Administration und das Monitoring der Server. Detaillierte technische Informationen finden Sie unter Fujitsu Technology Solutions 2009 Seite 2 (26)

3 SPECcpu2006 Benchmark-Beschreibung SPECcpu2006 ist ein Benchmark, der die Systemeffizienz bei Integer- und Fließkomma-Operationen misst. Er besteht aus einer Integer-Testsuite (SPECint2006), die 12 Applikationen enthält, und einer Fließkomma-Testsuite (SPECfp2006), die 17 Applikationen enthält. Beide Testsuiten sind extrem rechenintensiv und konzentrieren sich auf die CPU und den Speicher. Andere Komponenten, wie Disk-I/O und Netzwerk, werden von diesem Benchmark nicht vermessen. SPECcpu2006 ist nicht an ein spezielles Betriebssystem gebunden. Der Benchmark ist als Source-Code verfügbar und wird vor der eigentlichen Messung kompiliert. Daher beeinflussen auch die verwendete Compiler-Version und deren Optimierungseinstellungen das Messergebnis. SPECcpu2006 beinhaltet zwei verschiedene Methoden der Performance-Messung: Die erste Methode (SPECint2006 bzw. SPECfp2006) ermittelt die Zeit, die für die Bearbeitung einer einzelnen Aufgabe benötigt wird. Die zweite Methode (SPECint_rate2006 bzw. SPECfp_rate2006) ermittelt den Durchsatz, d.h. wie viele Aufgaben parallel erledigt werden können. Beide Methoden werden zusätzlich noch in zwei Messläufe unterteilt, base und peak, die sich in der Verwendung der Compiler-Optimierung unterscheiden. Bei der Publikation von Ergebnissen werden immer base -Werte verwendet, peak -Werte sind optional. Benchmark Arithmetik Typ Compiler- Optimierung SPECint2006 Integer peak aggressiv SPECint_base2006 Integer base konservativ SPECint_rate2006 Integer peak aggressiv SPECint_rate_base2006 Integer base konservativ SPECfp2006 Fließkomma peak aggressiv SPECfp_base2006 Fließkomma base konservativ SPECfp_rate2006 Fließkomma peak aggressiv SPECfp_rate_base2006 Fließkomma base konservativ Messergebnis Geschwindigkeit Durchsatz Geschwindigkeit Durchsatz Anwendung Singlethreaded Multithreaded Singlethreaded Multithreaded Bei den Messergebnissen handelt es sich um das geometrische Mittel aus normalisierten Verhältniswerten, die für die Einzel-Benchmarks ermittelt wurden. Das geometrische Mittel führt gegenüber dem arithmetischen Mittel dazu, dass bei unterschiedlich hohen Einzelergebnissen eine Gewichtung zugunsten der niedrigeren Einzelergebnisse erfolgt. Normalisiert heißt, dass gemessen wird, wie schnell das Testsystem verglichen mit einem Referenzsystem ist. Der Wert 1 wurde für die SPECint_base2006-, SPECint_rate_base2006, SPECfp_base2006 und SPECfp_rate_base2006- Ergebnisse des Referenzsystems festgelegt. So bedeutet beispielsweise ein SPECint_base2006-Wert von 2, dass das Messsystem diesen Benchmark etwa doppelt so schnell wie das Referenzsystem bewältigt hat. Ein SPECfp_rate_base2006-Wert von 4 bedeutet, dass das Messsystem diesen Benchmark etwa 4/[# base copies] mal so schnell wie das Referenzsystem bewältigt hat. # base copies gibt hierbei an, wie viele parallele Instanzen des Benchmarks ausgeführt worden sind. Nicht alle SPECcpu2006-Messungen werden von uns zur Veröffentlichung bei SPEC eingereicht. Daher erscheinen auch nicht alle Ergebnisse auf den Web-Seiten von SPEC. Da wir für alle Messungen die Protokolldateien archivieren, können wir jederzeit den Nachweis für die korrekte Durchführung der Messungen erbringen. Benchmark-Ergebnisse Die PRIMERGY BX620 S4 wurde mit vier verschiedenen Prozessorvarianten der Xeon-Reihe vermessen: Xeon 5110 und 5148 (G0) (Woodcrest, 2 Cores pro Chip, 4 MB L2-Cache pro Chip) Xeon E5205, L5240 und X5260 (Wolfdale, 2 Cores pro Chip, 6 MB L2-Cache pro Chip) Xeon L5310, L5335 und X5365 (Clovertown, 4 Cores pro Chip, 8 MB L2-Cache pro Chip) Xeon E5405, L5410, L5420, E5420, E5430, E5440, E5450 und X5460 (Harpertown, 4 Cores pro Chip, 12 MB L2-Cache pro Chip) SPEC, SPECint, SPECfp und das SPEC-Logo sind eingetragene Warenzeichen der Standard Performance Evaluation Corporation (SPEC). Fujitsu Technology Solutions 2009 Seite 3 (26)

4 Alle Benchmark-Programme wurden mit dem Intel C++/Fortran-Compiler 10.1 kompiliert und unter SUSE Linux Enterprise Server 10 SP1 (64-bit) ausgeführt. Prozessor Cores GHz L2-Cache FSB TDP SPECint_rate_base2006 SPECint_rate Chip 2 Chips 1 Chip 2 Chips Xeon MB pro Chip 1067 MHz 65 Watt n/a 37.3 n/a 42.4 Xeon MB pro Chip 1333 MHz 65 Watt n/a n/a n/a n/a Xeon MB pro Chip 1333 MHz 65 Watt n/a n/a n/a n/a Xeon MB pro Chip 1333 MHz 40 Watt n/a n/a n/a n/a Xeon 5148 (G0) MB pro Chip 1333 MHz 40 Watt n/a 51.1 n/a 58.4 Xeon MB pro Chip 1333 MHz 65 Watt n/a n/a n/a n/a Xeon MB pro Chip 1333 MHz 80 Watt n/a n/a n/a n/a Xeon E MB pro Chip 1067 MHz 65 Watt n/a 44.7 n/a 51.9 Xeon L MB pro Chip 1333 MHz 40 Watt n/a 65.3 n/a 76.4 Xeon X MB pro Chip 1333 MHz 80 Watt n/a 69.4 n/a 81.3 Xeon E MB pro Chip 1067 MHz 80 Watt n/a 63.1 (est.) n/a 73.0 (est.) Xeon L5310 (G0) MB pro Chip 1067 MHz 50 Watt n/a 63.5 n/a 73.3 Xeon L MB pro Chip 1067 MHz 50 Watt n/a 68.9 (est.) n/a 79.6 (est.) Xeon E MB pro Chip 1067 MHz 80 Watt n/a 68.9 (est.) n/a 79.6 (est.) Xeon E MB pro Chip 1333 MHz 80 Watt n/a 78.5 (est.) n/a 90.7 (est.) Xeon L5335 (G0) MB pro Chip 1333 MHz 50 Watt n/a 78.9 n/a 91.1 Xeon E MB pro Chip 1333 MHz 80 Watt n/a 85.2 (est.) n/a 98.5 (est.) Xeon X MB pro Chip 1333 MHz 120 Watt n/a 91.9 (est.) n/a 107 (est.) Xeon X5365 (G0) MB pro Chip 1333 MHz 120 Watt n/a 98.2 n/a 115 Xeon E MB pro Chip 1333 MHz 80 Watt Xeon L MB pro Chip 1333 MHz 50 Watt 50.4 (est.) (est.) 111 Xeon L MB pro Chip 1333 MHz 50 Watt 52.7 (est.) (est.) 116 Xeon E MB pro Chip 1333 MHz 80 Watt 52.7 (est.) (est.) 115 (est.) Xeon E MB pro Chip 1333 MHz 80 Watt (est.) Xeon E MB pro Chip 1333 MHz 80 Watt 57.0 (est.) (est.) 124 (est.) Xeon E MB pro Chip 1333 MHz 80 Watt 58.8 (est.) (est.) 129 Xeon X MB pro Chip 1333 MHz 120 Watt Alle fett gedruckten Ergebnisse sind veröffentlicht bei Die SPECint_rate_2006-Ergebnisse liegen beim Woodcrest-Prozessor 14%, bei den Wolfdale-Prozessoren 16-17%, bei den Clovertown-Prozessoren 15-17% und bei den Harpertown-Prozessoren 17-20% über den SPECint_rate_base2006- Ergebnissen. Fujitsu Technology Solutions 2009 Seite 4 (26)

5 SPECfp_rate_base2006 SPECfp_rate2006 Prozessor Cores GHz L2-Cache FSB TDP 1 Chip 2 Chips 1 Chip 2 Chips Xeon MB pro Chip 1067 MHz 65 Watt n/a n/a n/a n/a Xeon MB pro Chip 1333 MHz 65 Watt n/a n/a n/a n/a Xeon MB pro Chip 1333 MHz 65 Watt n/a n/a n/a n/a Xeon MB pro Chip 1333 MHz 40 Watt n/a n/a n/a n/a Xeon 5148 (G0) MB pro Chip 1333 MHz 40 Watt n/a 40.1 n/a 43.7 Xeon MB pro Chip 1333 MHz 65 Watt n/a n/a n/a n/a Xeon MB pro Chip 1333 MHz 80 Watt n/a n/a n/a n/a Xeon E MB pro Chip 1067 MHz 65 Watt n/a 34.8 n/a 38.6 Xeon L MB pro Chip 1333 MHz 40 Watt n/a 48.3 n/a 54.0 Xeon X MB pro Chip 1333 MHz 80 Watt n/a 50.6 n/a 56.6 Xeon E MB pro Chip 1067 MHz 80 Watt n/a 42.7 (est.) n/a 46.3 (est.) Xeon L5310 (G0) MB pro Chip 1067 MHz 50 Watt n/a 43.0 n/a 46.5 Xeon L MB pro Chip 1067 MHz 50 Watt n/a 45.2 (est.) n/a 48.8 (est.) Xeon E MB pro Chip 1067 MHz 80 Watt n/a 45.2 (est.) n/a 48.8 (est.) Xeon E MB pro Chip 1333 MHz 80 Watt n/a 53.1 (est.) n/a 57.6 (est.) Xeon L5335 (G0) MB pro Chip 1333 MHz 50 Watt n/a 53.5 n/a 57.8 Xeon E MB pro Chip 1333 MHz 80 Watt n/a 56.1 (est.) n/a 61.1 (est.) Xeon X MB pro Chip 1333 MHz 120 Watt n/a 59.2 (est.) n/a 64.6 (est.) Xeon X5365 (G0) MB pro Chip 1333 MHz 120 Watt n/a 62.0 n/a 67.7 Xeon E MB pro Chip 1333 MHz 80 Watt Xeon L MB pro Chip 1333 MHz 50 Watt 36.0 (est.) (est.) 67.9 Xeon L MB pro Chip 1333 MHz 50 Watt 37.1 (est.) (est.) 69.9 Xeon E MB pro Chip 1333 MHz 80 Watt 37.1 (est.) (est.) 69.2 (est.) Xeon E MB pro Chip 1333 MHz 80 Watt (est.) Xeon E MB pro Chip 1333 MHz 80 Watt 39.2 (est.) (est.) 73.2 (est.) Xeon E MB pro Chip 1333 MHz 80 Watt 40.1 (est.) (est.) 75.2 Xeon X MB pro Chip 1333 MHz 120 Watt Alle fett gedruckten Ergebnisse sind veröffentlicht bei Fujitsu Technology Solutions 2009 Seite 5 (26)

6 Die SPECfp_rate_2006-Ergebnisse liegen beim Woodcrest-Prozessor 9%, bei den Wolfdale-Prozessoren 11-12%, bei den Clovertown-Prozessoren 8-9% und bei den Harpertown-Prozessoren 10-11% über den SPECfp_rate_base2006- Ergebnissen. Fujitsu Technology Solutions 2009 Seite 6 (26)

7 Vergleicht man die PRIMERGY BX620 S4 mit ihrem Vorgänger, der PRIMERGY BX620 S3, in jeweils performantester Ausstattung, so ergibt sich in der Integer-Testsuite eine Steigerung von +21% bei SPECint_rate_base2006 und +33% bei SPECint_rate2006. In der Fließkomma-Testsuite beträgt der Zuwachs +20% bei SPECfp_rate_base2006 und +28% bei SPECfp_rate2006. Benchmark-Umgebung Alle SPECcpu2006-Messungen wurden auf einer PRIMERGY BX620 S4 mit folgender Hard- und Software-Ausstattung vorgenommen: Hardware Modell CPU PRIMERGY BX620 S4 Xeon 5110 und 5148 (G0) Xeon E5205, L5240 und X5260 Xeon L5310, L5335 und X5365 Xeon E5405, L5410, L5420, E5420, E5430, E5440, E5450 und X5460 Anzahl CPUs 1, 2 Primary Cache 32 KB instruction + 32 KB data on chip, pro Core Xeon 5110, 5148 (G0): 4 MB (I+D) on chip, pro Chip Xeon E5205, L5240, X5260: 6 MB (I+D) on chip, pro Chip Secondary Cache Xeon L5310, L5335, X5365: 8 MB (I+D) on chip, pro Chip Xeon E5405, L5410, L5420, E5420, E5430, E5440, E5450, X5460: 12 MB (I+D) on chip, pro Chip Other Cache nein Memory 8 x 2 GB PC2-5300F DDR2-SDRAM Software Betriebssystem SUSE Linux Enterprise Server 10 SP1 (64-bit) Compiler Intel C++/Fortran Compiler 10.1 Fujitsu Technology Solutions 2009 Seite 7 (26)

8 SPECjbb2005 Benchmark-Beschreibung SPECjbb2005 ist ein Java Business Benchmark, dessen Fokus auf der Leistung von Java Server Plattformen liegt. Im Wesentlichen ist SPECjbb2005 ein modernisierter SPECjbb2000. Die Hauptunterschiede sind: Die Transaktionen sind komplexer geworden, um einen größeren Bereich an Funktionalität abzudecken. Der Working Set des Benchmarks ist vergrößert worden, so dass die Systemlast insgesamt gestiegen ist. SPECjbb2000 erlaubt nur eine aktive Java Virtual Machine Instanz (JVM), während SPECjbb2005 mehrere Instanzen zulässt, was eine größere Realitätsnähe insbesondere bei großen Systemen bewirkt. Softwareseitig misst SPECjbb2005 die Effizienz der Implementierungen der JVM, Just-In-Time (JIT) Compilers, Garbage Collection, Threads sowie einige Aspekte des Betriebssystems. Hardwareseitig wird die Effizienz der CPUs und Caches, des Speichersubsystems und die Skalierbarkeit von Shared Memory Systemen (SMP) gemessen. Disk- und Netzwerk- I/O spielen keine Rolle. SPECjbb2005 emuliert ein für moderne Geschäftsprozess-Applikationen typisches Three-Tier Client/Server System mit Augenmerk auf das Middle-Tier System: Clients erzeugen die Last, bestehend aus Driver Threads, die angelehnt an den TPC-C Benchmark OLTP Zugriffe auf eine Datenbank ohne Denkzeiten generieren. Das Middle-Tier System implementiert die Geschäftsprozesse und Aktualisierung der Datenbank. Die Datenbank übernimmt die Datenverwaltung und wird emuliert durch Java-Objekte, die im Memory liegen. Transaktions-Logging ist implementiert auf XML Basis. Der große Vorteil dieses Benchmarks ist, dass er alle drei Tiers beinhaltet, die gemeinsam auf einem Single-Host laufen. Gemessen wird die Performance des Middle-Tier. So werden große Hardware-Installationen vermieden und direkte Vergleiche von SPECjbb2005-Ergebnissen unterschiedlicher Systeme sind möglich. Client- und Datenbank-Emulation sind ebenfalls in Java geschrieben. SPECjbb2005 benötigt nur das Betriebssystem sowie eine Java Virtual Machine mit J2SE 5.0 Eigenschaften. Die Skalierungseinheit ist ein Warenhaus mit ca. 25 MB Java Objekten. Genau ein Java-Thread pro Warenhaus führt die Operationen auf diesen Objekten aus. Die Geschäftsoperationen sind von TPC-C übernommen: New Order Entry Payment Order Status Inquiry Delivery Stock Level Supervision Customer Report Das sind aber auch die einzigen Gemeinsamkeiten von SPECjbb2005 und TPC-C. Die Ergebnisse beider Benchmarks sind nicht vergleichbar. SPECjbb2005 besitzt 2 Performance-Metriken: bops (business operations per second) ist die Gesamtrate aller Geschäftsoperationen, die pro Sekunde durchgeführt werden. bops/jvm ist der Quotient der ersten Metrik und der Anzahl der aktiven JVM Instanzen. In Vergleichen verschiedener SPECjbb2005-Ergebnisse müssen beide Metriken angegeben werden. Grundlage für diese Metriken sind die folgenden Regeln, nach denen ein konformer Benchmark-Lauf durchgeführt werden muss: Ein konformer Benchmarklauf besteht aus einer Sequenz von Messpunkten mit wachsender Anzahl von Warenhäusern (und damit von Threads), wobei die Anzahl jeweils um ein Warenhaus erhöht wird. Gestartet wird mit einem Warenhaus bis zu 2*MaxWH, mindestens aber 8 Warenhäusern. MaxWh ist die Anzahl Warenhäuser, bei der der Benchmark die höchste Operationsrate pro Sekunde erwartet. Standardmäßig setzt der Benchmark MaxWH mit der Anzahl vom Betriebssystem erkannter CPUs gleich. Die Metrik bops ist das arithmetische Mittel aller gemessenen Operations-Raten mit MaxWh Warenhäusern bis 2*MaxWh Warenhäusern. SPEC, SPECjbb und das SPEC-Logo sind eingetragene Warenzeichen der Standard Performance Evaluation Corporation (SPEC). Fujitsu Technology Solutions 2009 Seite 8 (26)

9 Benchmark-Ergebnisse Im Januar 2008 wurde die PRIMERGY BX620 S4 mit zwei Xeon E5450 Prozessoren bei einem Speicherausbau mit 16 GB PC2-5300F DDR2-SDRAM vermessen. Die Messung wurde unter Windows Server 2003 Enterprise x64 Edition R2 SP2 durchgeführt. Als JVM wurden vier Instanzen von JRockit(R) 6.0 P (build P _ windows-x86_64) von BEA verwendet. Im Februar 2008 wurde die PRIMERGY BX620 S4 mit zwei Xeon X5460 Prozessoren vermessen. Als JVM wurden vier Instanzen von JRockit(R) 6.0 R build R _ windows-x86_64) von BEA verwendet. Alle anderen Hard- und Softwarekomponenten entsprachen der Messung vom Januar Bei der Messung der PRIMERGY BX620 S3 flossen alle Messwerte von 4 bis 8 Warenhäusern, bei den Messungen der PRIMERGY BX620 S4 alle Messwerte von 2 bis 4 Warenhäusern in das Benchmark-Ergebnis ein. Vergleicht man die PRIMERGY BX620 S4 mit ihrem Vorgänger, der PRIMERGY BX620 S3, in jeweils performantester Ausstattung, so ergibt sich eine Durchsatzsteigerung von +33%. Fujitsu Technology Solutions 2009 Seite 9 (26)

10 Benchmark-Umgebung Die SPECjbb2005-Messungen wurden auf einer PRIMERGY BX620 S4 mit folgender Hard- und Software-Ausstattung vorgenommen: Hardware Modell CPU Anzahl Chips Primary Cache Secondary Cache Other Cache Memory Software Betriebssystem JVM Version PRIMERGY BX620 S4 Xeon E5450, X Chips, 8 Cores, 4 Cores pro Chip 32 KB instruction + 32 KB data on chip, pro Core 12 MB (I+D) on chip, pro Chip nein 8 x 2 GB PC2-5300F DDR2-SDRAM Windows Server 2003 Enterprise x64 Edition R2 SP2 Xeon E5450: BEA JRockit(R) 6.0 P (build P _ windows-x86_64) Xeon X5460: JRockit(R) 6.0 R build R _ windows-x86_64) Fujitsu Technology Solutions 2009 Seite 10 (26)

11 StorageBench Benchmark-Beschreibung Um die Leistungsfähigkeit von Disk-Subsystemen zu beurteilen, wurde von Fujitsu Technology Solutions ein Benchmark mit dem Namen StorageBench definiert, mit dem ein Vergleich der verschiedenen Storage-Anbindungen möglich ist. StorageBench nutzt zu diesem Zweck das von der Firma Intel entwickelte Programm Iometer mit einem definierten Satz von in der Praxis vorkommenden Zugriffsmustern. Seit Ende 2001 ist Iometer ein Projekt bei und wird von einer Gruppe internationaler Entwickler auf verschiedene Plattformen portiert und weiterentwickelt. Iometer besteht aus einer Bedieneroberfläche für Windows- Systeme und dem so genannten dynamo, der auf dem Zielsystem zum Ablauf gebracht wird. Diese beiden Komponenten können seit einigen Jahren unter Intel Open Source License von oder herunter geladen werden. Mit Iometer hat man die Möglichkeit, das Verhalten realer Anwendungen bezüglich der Zugriffe auf I/O-Subsysteme nachzubilden. Dazu kann man unter anderem die zu verwendenden Blockgrößen, die Art des Zugriffs wie sequentielles Lesen oder Schreiben, wahlfreies Lesen oder Schreiben und auch Mischungen davon konfigurieren. Als Ergebnis liefert Iometer eine Textdatei mit durch Komma separierten Werten (.csv) mit wesentlichen Kenngrößen wie z.b. Durchsatz pro Sekunde, Transaktionen pro Sekunde und durchschnittliche Antwortzeit für das jeweilige Zugriffsmuster. Auf diese Weise kann man die Leistungsfähigkeit verschiedener Subsystem bei bestimmten Zugriffsmustern vergleichen. Iometer ist in der Lage, sowohl auf Subsysteme mit einem Dateisystem als auch auf so genannte Raw-Devices zuzugreifen. Da Festplatten zu den fehleranfälligsten Komponenten eines Computersystems gehören, werden in Serversystemen RAID-Controller eingesetzt um dem Datenverlust durch den Ausfall von Festplatten vorzubeugen. Das Betriebssystem sieht die über einen RAID-Controller zur Verfügung gestellten logischen Laufwerke wie eine einzelne Festplatte. Informationen zu den Grundlagen verschiedener RAID-Verbände sind im Papier Performance Report - Modular RAID für PRIMERGY zu finden. Bei der Beurteilung der Leistungsfähigkeit von I/O-Subsystemen spielen bei heutigen Systemen die Prozessorleistung und der Speicherausbau des Systems in den meisten Fällen keine Rolle ein evtl. vorhandener Engpass betrifft in der Regel eher die Festplatten und den RAID-Controller als CPU und Memory. Von erheblichem Einfluss auf die Performance eines Speichersystems ist die Art, wie Anwendungen auf den Massenspeicher zugreifen. In der Hauptsache unterscheidet man folgende Zugriffsmuster: Sequential read Sequential write Random read/write Beispiele für verschiedene Zugriffsmuster einiger Anwendungen: Anwendung Datenbank (Datentransfer) Datenbank (Log File) Backup Restore Video streaming File Server Zugriffsmuster Random, 67% read, 33% write (SQL Server 8 KB) Sequential write, bei Recover: read Sequential read (Windows: 64 KB) Sequential write (Windows: 64 KB) Sequential read (128 KB) Random, 30% read, 70% write (>= 4 KB) Da in realen Kundenkonfigurationen nur in Ausnahmefällen mit Raw-devices gearbeitet wird, sind bei den Untersuchungen zur Leistungsfähigkeit der internen Festplatten diese immer mit NTFS formatiert. Außerdem betreiben Kunden in den meisten Fällen die internen Festplatten als RAID 1, RAID 5 oder RAID 10, daher werden für die Untersuchungen auch die je nach Plattenanzahl möglichen RAID-Konfigurationen verwendet. Benchmark-Ergebnisse Aktuell sind für die PRIMERGY BX620 S4 als interne Festplatten 2½" SAS-Platten freigegeben. Es können 2 verschiedene SAS Controller konfiguriert werden: ein auf dem LSI 1068 basierender SAS Controller (SAS IME) die als RAID On MotherBoard (SAS ROMB), Codename Brockton, bezeichnete Lösung mit 256 MB batteriegepuffertem Cache Fujitsu Technology Solutions 2009 Seite 11 (26)

12 Im folgenden Diagramm sind die Durchsätze der in der Realität häufig vorkommenden Blockgrößen 4 KB, 8 KB sowie 64 KB dargestellt. Bei den schreibenden Zugriffen mit 4 KB bzw. 8 KB bewirkt die Konfiguration von WriteBack, d.h. mit Nutzung des batteriegepufferten Cache, beim SAS ROMB eine deutliche Erhöhung des Durchsatzes von mehr als 900%. Bei den lesenden Zugriffen sind alle drei Konfigurationsvarianten (SAS IME, ROMB im WriteThrough und WriteBack Modus) nahezu gleichwertig. Aus dem Diagramm wird deutlich, dass der Einsatz des ROMB ohne Nutzung des Cache (d.h. WriteThrough) keinen Sinn macht. Der Vergleich der Durchsatzwerte von random und von sequentiellen Zugriffen ist nicht sinnvoll. Man verwendet bei Zugriffsmustern wie sie beispielsweise Datenbanken benutzen (random) oft den Begriff Transaktionsrate. Bei so genannten transaktionsorientierten Anwendungen kommt es in der Hauptsache auf erreichbare Transaktionsraten und nicht auf den Durchsatz in MB/sec an. Wie im Diagramm erkennbar, lässt die Nutzung des batteriegepufferten Cache bei SAS ROMB (WriteBack) sowohl bei 4 KB als auch bei 8 KB Blöcken deutlich höhere IO-Raten zu als die beiden Varianten ohne Cache. Benchmark-Umgebung Alle Messungen wurden mit Windows Server 2003 Standard Edition mit Service Pack 1 und Seagate ST973401SS Platten (2½", 73 GB, 10 krpm) durchgeführt. Das Dateisystem wurde mit NTFS formatiert, die Messdatei hatte eine Größe von 8 GB. Fujitsu Technology Solutions 2009 Seite 12 (26)

13 OLTP-2 Benchmark-Beschreibung OLTP steht für Online Transaction Processing. Dem OLTP-2-Benchmark liegt das typische Anwendungsszenario einer Datenbank-Lösung zugrunde. Es werden bei OLTP-2-Zugriffe auf eine Datenbank simuliert und die Anzahl erreichter Transaktionen pro Sekunde (tps) als Maß für die Leistungsfähigkeit des vermessenen Systems ermittelt. Im Gegensatz zu Benchmarks, wie beispielsweise SPECint und TPC-E, die von unabhängigen Gremien standardisiert wurden und bei denen die Einhaltung des jeweiligen Reglements überwacht wird, ist OLTP-2 ein interner Benchmark von Fujitsu Technology Solutions. Im Gegensatz zu anderen Datenbank-Benchmarks, die zum Teil einen enormen Hardware- und Zeit-Aufwand für die Simulation erfordern, wurde dies bei OLTP-2 auf ein vertretbares Maß reduziert, sodass eine Vielzahl von Konfigurationen in akzeptabler Zeit vermessen werden kann. Auch wenn die beiden Benchmarks OLTP-2 und TPC-E ähnliche Anwendungsszenarien simulieren, so sind die Ergebnisse nicht vergleichbar oder gar gleichzusetzen, da die beiden Benchmarks unterschiedliche Methoden zur Simulation der Benutzerlast verwenden. Typischerweise sind OLTP-2-Werte TPC-E-Werten ähnlich. Ein direkter Vergleich oder gar die Bezeichnung des OLTP-2-Ergebnisses als TPC-E-Ergebnis ist nicht zulässig. Benchmark-Ergebnisse Die PRIMERGY BX620 S4 wurde mit dem Dual-Core Xeon Prozessor X5260 sowie den Quad-Core Xeon Prozessoren L5335, E5335, X5365, L5410 und X5460 bei Speicherausbauten von 16, 24 und 32 GB vermessen. Alle Ergebnisse wurden basierend auf dem Betriebssystem Microsoft Windows Server 2003 Enterprise x64 Edition SP2 und der Datenbank SQL Server 2005 Enterprise x64 Edition SP2 ermittelt. OLTP-Benchmark-Ergebnisse sind in hohem Maße abhängig von den Ausbaumöglichkeiten eines Systems mit Festplatten und deren Controllern. Das System wurde daher mit einem 2-Kanal Fibre Channel I/O-Modul und einem 2-Kanal Fibre Channel Controller ausgestattet, über die vier FibreCAT CX500 mit insgesamt 315 Festplatten angeschlossen waren. Weitere Informationen über die Systemkonfiguration können dem Abschnitt Benchmark-Umgebung entnommen werden. Die folgenden Grafiken zeigen die OLTP-2-Leistungsdaten der PRIMERGY BX620 S4 mit ein und zwei Prozessoren. Fujitsu Technology Solutions 2009 Seite 13 (26)

14 Fujitsu Technology Solutions 2009 Seite 14 (26)

15 Betrachtet man die Skalierung bzgl. der Anzahl Prozessoren gemeinsam mit der Speicherskalierung (z.b. 2 Xeon X5460 mit 32 GB RAM im Vergleich zu 1 Xeon X5460 mit 16 GB RAM), so ergibt sich je nach verwendetem Prozessor ein Performance-Zuwachs von 81-98%. Benchmark-Umgebung Microsoft Windows Server 2003 Enterprise x64 Edition SP2 und SQL Server 2005 Enterprise x64 Edition SP2 Clients: 2 x PRIMERGY Econel 200 with 2 x Xeon 3.40 GHz, 2 MB SLC 2 GB RAM onboard LAN Server: PRIMERGY BX620 S4 1, 2 Xeon X5260, L5335, E5335, X5365, L5410 and X GB RAM 1 x LSI MegaRAID 1068E controller 3 log disks (72 GB, 15 krpm) 1 x 2-channel FC I/O module 1 x 2-channel FC controller QLE2462 onboard LAN Storage: 4 x FibreCAT CX data disks (36 GB, 15 krpm) 90 data disks (72 GB, 15 krpm) 45 log disks (36 GB, 15 krpm) LAN Switch Fujitsu Technology Solutions 2009 Seite 15 (26)

16 System R/3 Standard Application Benchmark Benchmark-Beschreibung Die Anwendungssoftware SAP System R/3 besteht aus sieben betriebswirtschaftlichen Modulen zur Verwaltung aller Standard-Geschäftsprozesse: FI MM SD PP WM PS HR Finanzen Materialwirtschaft Vertrieb (Sales und Distribution) Produktion und Planung Warenwirtschaft (Warehouse Management) Projektsystem Personalwesen (Human Resources) Diese Applikationssoftware basiert wiederum auf einer Datenbank, so dass eine R/3-Konfiguration neben der tragenden Hardware aus den Software-Komponenten Betriebssystem, Datenbank und letztendlich der R/3-Software selbst besteht. Zur Verifikation der Konfiguration und Performance eines R/3-Applikationssystems hat die SAP AG den System-R/3- Standard-Application-Benchmark entwickelt. Der Benchmark analysiert die Performance des Gesamtsystems und ist somit ein Maß für die Qualität der Integration der Einzelkomponenten. Bei dem Benchmark wird zwischen einer Two-Tier- und einer Three-Tier-Konfiguration unterschieden. Bei der Two-Tier- Konfiguration sind die R/3-Applikation und die Datenbank auf einem Server installiert. Bei einer Three-Tier-Konfiguration können die einzelnen Komponenten der R/3-Applikation über mehrere Server verteilt sein und ein weiterer Server übernimmt die Datenbank. Eine komplette Spezifikation des von der SAP AG, Walldorf Deutschland entwickelten Benchmarks ist unter zu finden. Benchmark-Ergebnisse Mit der Zertifikationsnummer belegt SAP, dass die PRIMERGY BX620 S4, ausgestattet mit 2 Xeon X5355 Prozessoren, mit SAP ECC 6.0 und MS SQL Server 2005 (64-bit) unter Windows Server 2003 Enterprise x64 Edition SP1 am 25. April 2007 folgendes Ergebnis erzielte: Number of benchmark users Average dialog response time 1870 SD (Sales & Distribution) 1.95 seconds Throughput Fully Processed Order Line items / hour Dialog steps / hour SAPS 9400 Average DB request time (dia/upd) sec / sec CPU utilization central server 98% Operating System central server RDBMS Windows Server 2003 Enterprise Edition (64-bit) SQL Server 2005 (64-bit) SAP ECC Release 6.0 Configuration Central Server PRIMERGY BX620 S4 2 Xeon X5355, 2.67 GHz, 8 MB L2 cache per chip, 32 GB RAM Fujitsu Technology Solutions 2009 Seite 16 (26)

17 Mit der Zertifikationsnummer belegt SAP, dass die PRIMERGY BX620 S4, ausgestattet mit 2 Xeon X5365 Prozessoren, mit SAP ECC 6.0 und MS SQL Server 2005 (64-bit) unter Windows Server 2003 Enterprise x64 Edition SP1 am 23. Juli 2007 folgendes Ergebnis erzielte: Number of benchmark users Average dialog response time 1940 SD (Sales & Distribution) 1.99 seconds Throughput Fully Processed Order Line items / hour Dialog steps / hour SAPS 9700 Average DB request time (dia/upd) sec / sec CPU utilization central server 97% Operating System central server RDBMS Windows Server 2003 Enterprise Edition (64-bit) SQL Server 2005 (64-bit) SAP ECC Release 6.0 Configuration Central Server PRIMERGY BX620 S4 2 Xeon X5365, 3 GHz, 8 MB L2 cache per chip, 32 GB RAM Die folgende Grafik verdeutlicht die Performance der PRIMERGY BX620 S4 im Vergleich zu ihren Vorgängern. Fujitsu Technology Solutions 2009 Seite 17 (26)

18 Benchmark-Umgebung Zertifikationsnummer : 2-Tier-Umgebung Last-Generator PRIMERGY RX600 4 Xeon MP 2.50 GHz, 512 KB L2 cache, 1 MB L3 cache 8 GB RAM Linux 2.6 R/3 & Database Server PRIMERGY BX620 S4 2 Xeon X5355, 2.67 GHz, 8 MB L2 cache per chip 32 GB PC2-5300F DDR2-SDRAM 1 x LSI SAS IME 1068 controller 1 SAS hard disks, 36 GB, 10 krpm 1 SAS hard disks, 73 GB, 10 krpm 1 x Fibre Channel module 1 x FibreCAT CX600 5 FC hard disks, 73 GB, 10 krpm Windows Server 2003 Enterprise x64 Edition MS SQL Server 2005 (64-bit) SAP ECC 6.0 SR1 Zertifikationsnummer : 2-Tier-Umgebung Last-Generator PRIMERGY RX600 4 Xeon MP 2.50 GHz, 512 KB L2 cache, 1 MB L3 cache 8 GB RAM Linux 2.6 R/3 & Database Server PRIMERGY BX620 S4 2 Xeon X5365, 2.67 GHz, 8 MB L2 cache per chip 32 GB PC2-5300F DDR2-SDRAM 1 x LSI SAS IME 1068 controller 1 SAS hard disks, 36 GB, 10 krpm 1 SAS hard disks, 73 GB, 10 krpm 1 x Fibre Channel module 1 x FibreCAT CX300 5 FC hard disks, 73 GB, 10 krpm Windows Server 2003 Enterprise x64 Edition MS SQL Server 2005 (64-bit) SAP ECC 6.0 SR1 Fujitsu Technology Solutions 2009 Seite 18 (26)

19 Terminal Server Benchmark-Beschreibung Für die Messungen von Terminal Server gibt es verschiedene Lastsimulationswerkzeuge, deren Messergebnisse nicht miteinander vergleichbar sind, aber keinen Standard-Benchmark. Die existierenden Lastsimulatoren sind nicht in der Lage, Microsoft Terminal Services und Citrix Presentation Server unter den gleichen Bedingungen zu vermessen oder haben andere Einschränkungen. Fujitsu Technology Solutions setzt daher ein selbst entwickeltes Programm namens T4US, Tool for User Simulation, ein. Dieses flexible Werkzeug, das beliebige Terminal Server-artige Szenarien simulieren kann, ist unabhängig vom verwendeten Betriebssystem und von der Anwendersoftware und kann eine detaillierte Messwerterfassung von Antwortzeiten und Auslastung unterschiedlichster Systemkomponenten vornehmen. Benutzer bei der Arbeit T4US-Control steuert und überwacht den gesamten Simulationslauf zentral und ermittelt Messwerte bereits während der Messung. Auf jedem der Lastgeneratoren laufen mehrere Instanzen des T4US- Playback. Jedes T4US-Playback füttert einen Terminal Server Client in Echtzeit mit Tastatur- und Mauseingaben anhand der mit T4US-Record aufgezeichneten Skripte und überwacht die Bildschirminhalte des Terminal Server Clients. Durch hoch auflösende Timer wird so die Antwortzeit des Terminal Servers T4US- Record Controller T4US- Control T4US- Skript Benutzeraktivitäten wie Tastatur- und Mauseingaben sowie Bildschirmausgaben können mit Hilfe des Aufzeichnungswerkzeugs T4US-Record in Echtzeit aufgezeichnet und in einem T4US-Skript gespeichert werden. T4US-Skripte werden während der Messung als Lastprofil verwendet. Der Lastsimulator von T4US besteht aus drei Komponenten. Lastgenerator T4US- Playback T4US- Agent T4US- Playback T4US- Playback System under Test (SUT) TS-Client TS-Client TS-Client SUT Terminal Server ermittelt. Auf jedem der Lastgeneratoren läuft ein T4US-Agent, der für die Kommunikation mit dem Controller zuständig ist, die Instanzen von T4US-Playback steuert und überwacht und die ermittelten Antwortzeiten zum Controller überträgt. Bei der Messung wird die Anzahl der Benutzer, die mit dem Terminal Server arbeiten, kontinuierlich erhöht. Die Antwortzeiten des Terminal Servers werden vom T4US-Controller überwacht und mit gespeicherten Referenzwerten, die in einer vorhergehenden Referenzmessung mit nur fünf Benutzern ermittelt worden sind, verglichen. Wenn sich die Antwortzeit der Anwendung so weit verschlechtert, dass sie den vorgegebenen Regeln nicht mehr genügt, wird die Messung beendet und man erhält die Benutzeranzahl als Resultat der Messung. Als Lastprofil dient ein Medium User, der nur mit einer Anwendung arbeitet und Daten zügig eingibt. In unserem Medium Lastprofil dient Microsoft Word als Anwendung und der Benutzer schreibt einen bebilderten Text mit einer durchschnittlichen Eingaberate von 230 Anschlägen pro Minute. Da die Benutzer versetzt gestartet werden, finden während der gesamten Messdauer kontinuierlich An- und Abmeldungen sowie Applikationsstarts statt. Es hat sich gezeigt, dass viele Messtools, z.b. das früher verwendete CSTK von Citrix, im Vergleich zur Realität zu hohe Benutzerzahlen liefern. In unseren neuen Messreihen haben wir dies berücksichtigt und können daher davon ausgehen, dass die ermittelten Benutzerzahlen denen aus realen Produktionsumgebungen nahe kommen. Bei einer Aussage von absoluten Benutzerzahlen auf einem Server muss trotzdem der kundenspezifische Last-Mix analysiert und mit den Leistungsdaten in diesem Papier in Relation gesetzt werden. Obgleich das Resultat der Messungen Anzahl Benutzer pro Server ist, sollte man die Ergebnisse in erster Linie relativ betrachten, also beispielsweise ein PRIMERGY System A ist doppelt so leistungsfähig wie ein PRIMERGY System B oder die Verdopplung des Arbeitsspeichers resultiert in x% Leistungssteigerung. Die hier gemessene Anzahl Benutzer pro Server gilt für Medium Benutzer, die mit diesem Lastprofil arbeiten. Dieser synthetische Benutzer muss nicht in allen Fällen mit einem realen Benutzer korrelieren. Nähere Informationen über die T4US-Messumgebung, das Medium Lastprofil und die Resultate der anderen PRIMERGY Modelle findet man im Terminal Server Sizing Guide. Fujitsu Technology Solutions 2009 Seite 19 (26)

20 Benchmark-Ergebnisse Die PRIMERGY BX620 S4 ist mit unterschiedlichen Prozessoren verschiedener Intel Xeon Reihen lieferbar: 51xx (Codename: Woodcrest), x52xx (Codename: Wolfdale), x53xx (Codename: Clovertown) und x54xx (Codename: Harpertown). Da auf diesen Prozessoren sowohl 32-bit- als auch und 64-bit-Betriebssysteme ablauffähig sind, erfolgten zusätzliche Untersuchungen auf einem ausgewählten Woodcrest-Prozessor zu Windows Server 2003 R2 als 32-bit- und 64-bit-Version. Bei den anderen Prozessoren wurde auf Messungen mit der 32-bit-Version verzichtet. Die 32-bit- und 64-bit-Versionen von Windows Server 2003 R2 basieren dabei auf der gleichen Code-Basis und sind daher direkt vergleichbar. Des Weiteren ist Windows Server 2003 R2 bis auf einige zusätzliche Dienste und Tools identisch mit Windows Server 2003 Service Pack 1. Für die 64-bit-Messungen wurden die gleichen Randbedingungen verwendet wie für die 32-bit-Messungen. Die simulierten Benutzer arbeiteten mit dem Medium Lastprofil unter Verwendung von Microsoft Office Für die Harpertown Messungen wurde zum einen das Medium Lastprofil verwendet und ferner eine Abwandlung des Medium Lastprofils mit einer Reduzierung der An- und Abmeldevorgänge. Des Weiteren wurde auch das unterschiedliche Verhalten von Microsoft Terminal Services und Citrix Presentation Server untersucht. Alle Installationen sind Standard. Für die Messungen wurden keine Optimierungen an Server oder Client durchgeführt bis auf: Die Page-Datei des Betriebssystems wurde auf eine feste Größe von 4 GB, bei den Messungen mit den Quad- Core Prozessoren auf 16 GB eingestellt. Bei Citrix musste die Grenze von 100 Benutzern pro Server, die durch das eingebaute Load Balancing vorgegeben wird, aufgehoben werden. Für ein Terminal Server-System sind die folgenden Performance-relevanten Faktoren maßgeblich: Rechenleistung Arbeitsspeicher Disk-Subsystem Netzwerk Netzwerk Einen erheblichen Einfluss auf eine Infrastruktur, die auf Terminal Server basiert, hat die zugrunde liegende Netzwerkinfrastruktur. Da wir hier die Leistungsfähigkeit eines einzelnen Terminal Servers diskutieren, wurde das Netzwerk so dimensioniert, dass es keinen Engpass darstellt. Disk-Subsystem Eine weitere Performance-relevante Komponente ist das Disk-Subsystem. In der hier verwendeten Messumgebung wird das Betriebssystem inklusive Swap-File auf einer Partition und die Daten der Benutzer auf einer zweiten Partition des Terminal Servers gespeichert. Die Partitionen lagen dabei entweder jeweils auf einer einzelnen Festplatte oder wie bei Messungen mit den Quad-Core Prozessoren, die eine höhere Benutzeranzahl erlauben auf je einem RAID 0 Verbund von zwei Festplatten. Diese Konfiguration wird verwendet, damit die Messergebnisse zwischen den verschiedenen PRIMERGY Systemen vergleichbar sind und das Disk-Subsystem nicht zum Engpass bei der Messung wird. Dies entspricht jedoch nicht zwingend der realen Kundenkonfiguration, denn dort wird man die Benutzerdaten typischerweise auf entsprechende Disk-Subsysteme oder externe File Server legen. Bei der PRIMERGY BX620 S4 können nur zwei interne Festplatten betrieben werden. Für den Betrieb zweier RAID-0 Verbände mit mehr physikalischen Platten ist daher ein externes SAN Subsystem notwendig. Um einen maximalen Durchsatz zu erreichen, wurden alle Caches, auch die Write- Caches, eingeschaltet. Write-Caches der Festplatten tragen erheblich zur Performance-Steigerung bei, und es empfiehlt sich, diese bei allen Festplatten vorhandene Funktionalität auch im produktiven Einsatz zu nutzen. Dabei ist die Verwendung einer USV zum Schutz gegen Stromausfälle und damit verbundenem Datenverlust empfehlenswert. Rechenleistung Die PRIMERGY BX620 S4 kann nach Bedarf mit verschiedenen Prozessoren ausgestattet werden, die sich hinsichtlich Taktfrequenz, Front-Side-Bus-Geschwindigkeit, Cache und Anzahl Kerne unterscheiden: Xeon 5110, 1.60 GHz, 1067 MHz Front-Side-Bus, 4 MB L2-Cache, 65 Watt Xeon 5130, 2 GHz, 1333 MHz Front-Side-Bus, 4 MB L2-Cache, 65 Watt Xeon 5140, 2.33 GHz, 1333 MHz Front-Side-Bus, 4 MB L2-Cache, 65 Watt Xeon 5148, 2.33 GHz, 1333 MHz Front-Side-Bus, 4 MB L2-Cache, 40 Watt Xeon GHz, 1333 MHz Front-Side-Bus, 4 MB L2-Cache, 65 Watt Xeon 5160, 3 GHz, 1333 MHz Front-Side-Bus, 4 MB L2-Cache, 80 Watt Xeon E5205, 1.87 GHz, 1067 MHz Front-Side-Bus, 6 MB L2-Cache, 65 Watt Xeon L5240, 3 GHz, 1333 MHz Front-Side-Bus, 6 MB L2-Cache, 40 Watt Xeon X5260, 3.33 GHz, 1333 MHz Front-Side-Bus, 6 MB L2-Cache, 80 Watt Fujitsu Technology Solutions 2009 Seite 20 (26)

21 Xeon E5310, 1.60 GHz, 1067 MHz Front-Side-Bus, 2 x 4 MB L2-Cache, 80 Watt Xeon L5310, 1.60 GHz, 1067 MHz Front-Side-Bus, 2 x 4 MB L2-Cache, 50 Watt Xeon E5320, 1.87 GHz, 1067 MHz Front-Side-Bus, 2 x 4 MB L2-Cache, 80 Watt Xeon L5320, 1.87 GHz, 1067 MHz Front-Side-Bus, 2 x 4 MB L2-Cache, 50 Watt Xeon L5335, 2 GHz, 1333 MHz Front-Side-Bus, 2 x 4 MB L2-Cache, 50 Watt Xeon E5335, 2 GHz, 1333 MHz Front-Side-Bus, 2 x 4 MB L2-Cache, 80 Watt Xeon E5345, 2.33 GHz, 1333 MHz Front-Side-Bus, 2 x 4 MB L2-Cache, 80 Watt Xeon X5355, 2.67 GHz, 1333 MHz Front-Side-Bus, 2 x 4 MB L2-Cache, 120 Watt Xeon X5365, 3 GHz, 1333 MHz Front-Side-Bus, 2 x 4 MB L2-Cache, 120 Watt Xeon E5405, 2 GHz, 1333 MHz Front-Side-Bus, 2 x 6 MB L2-Cache, 80 Watt Xeon L5410, 2.33 GHz, 1333 MHz Front-Side-Bus, 2 x 6 MB L2-Cache, 50 Watt Xeon E5420, 2.5 GHz, 1333 MHz Front-Side-Bus, 2 x 6 MB L2-Cache, 80 Watt Xeon L5420, 2.5 GHz, 1333 MHz Front-Side-Bus, 2 x 6 MB L2-Cache, 50 Watt Xeon E5430, 2.67 GHz, 1333 MHz Front-Side-Bus, 2 x 6 MB L2-Cache, 80 Watt Xeon E5440, 2.83 GHz, 1333 MHz Front-Side-Bus, 2 x 6 MB L2-Cache, 80 Watt Xeon E5450, 3 GHz, 1333 MHz Front-Side-Bus, 2 x 6 MB L2-Cache, 80 Watt Die Prozessoren der Reihe 51xx (Woodcrest) und der Reihe x52xx (Wolfdale) haben zwei Kerne pro Chip (Dual-Core), die Prozessoren der Reihe x53xx (Clovertown) und der Reihe x54xx (Harpertown) dagegen haben vier Kerne pro Chip (Quad-Core). Der L2-Cache beträgt bei dem Woodcrest 4 MB bzw. 6 MB bei dem Wolfdale und ist beiden Kernen zugeordnet. Bei den Clovertown-Prozessoren beträgt die Größe des L2-Cache 2 4 MB pro Chip, d.h. 4 MB für jeweils zwei Kerne. Der Harpertown-Prozessor hat mit 2 6 MB, d.h. 6 MB für jeweils zwei Kerne, einen im Vergleich zum Clovertown vergrößerten L2-Cache. Hyper-Threading wird bei den aktuellen Xeon Prozessoren nicht angeboten. Bei der Betrachtung der Rechenleistung waren alle Systeme mit genügend Arbeitsspeicher ausgebaut, damit diese Komponente keinen Engpass darstellt. Die Messungen erfolgten unter 64-bit Windows 2003 R2. Die folgende Grafik stellt alle Messergebnisse der verschiedenen Prozessoren unter Microsoft Terminal Server dar. Das mit dem Medium User Lastprofil gemessene Leistungsspektrum erstreckt sich von 177 Benutzern (zwei Xeon 5110) bis zu 279 Benutzern (zwei Xeon X5460). Dabei erreicht die PRIMERGY BX620 S4 mit zwei Wolfdale-Prozessoren Xeon E5205 (2 2 Kerne, 2 6 MB L2-Cache) die Leistung von 219 Benutzern. Das liegt nur wenig unterhalb der 235 Benutzer, die mit einem kleinen Harpertown-Prozessor Xeon E5405 (vier Kerne, 2 6 MB L2-Cache) gemessen wurden. Interessant ist auch der Vergleich zwischen den Clovertown-Prozessoren Xeon E5335 bzw. L5335 und den kleinen Harpertown-Prozessoren Xeon E5405. Bei gleicher Taktfrequenz und gleicher Frequenz des Front-Side-Busses schlägt sich der größere L2-Cache des Xeon E5405 in den Messergebnissen positiv nieder. Auffallend bei den Messergebnissen ist, dass in dem oberen Leistungsspektrum der Prozessoren, insbesondere bei den Harpertown-CPUs, die Leistungssteigerung durch höhere Taktfrequenz oder einen zweiten Prozessor kaum noch in eine größere Benutzeranzahl umgesetzt werden kann. Eine Verdopplung der Anzahl Prozessoren führte bei den Messungen mit Microsoft Terminal Server zu einer Leistungssteigerung im Bereich von etwa 10% - 80%. Die leistungsschwächeren Dual-Core Prozessoren profitierten bei diesem Benchmark stärker von dem zweiten Prozessor. Bei den Clovertown-Prozessoren betrug der Leistungszuwachs nur noch ca. 20% - 30%, bei den Harpertown-Prozessoren nur noch ca. 7% - 14%. Das liegt zum einen daran, dass eine Steigerung von vier auf acht Prozessorkerne weniger effektiv ist als von zwei auf vier. Eine genauere Analyse zeigte darüber hinaus, dass bei den Messungen mit zwei Prozessoren deren Kerne nur zu ca. 50% - 60% ausgelastet waren, obwohl weder ein Netzwerk- noch ein Plattenengpass vorlag, d.h. der Benchmark konnte die CPU-Leistung des Systems nicht nutzen. Eine Begründung für dieses Verhalten ist in dem Lastprofil des Benchmarks zu finden: Als Lastprofil dient ein Medium User, der nur mit einer Anwendung arbeitet und Daten zügig eingibt. In unserem Medium Lastprofil dient Microsoft Word als Anwendung und der Benutzer schreibt einen bebilderten Text mit einer durchschnittlichen Eingaberate von 230 Anschlägen pro Minute. Dies dauert ca. 15 Minuten. Dann loggt sich der Benutzer aus und wieder ein und bearbeitet erneut einen Text. Da die Benutzer versetzt gestartet werden, finden während der gesamten Messdauer kontinuierlich An- und Abmeldungen sowie Applikationsstarts statt. Genau diese vielen An- und Abmeldungen führen dazu, dass die CPU-Leistung nicht voll genutzt werden kann. Fujitsu Technology Solutions 2009 Seite 21 (26)

22 Deshalb wurden Messungen auf einem Harpertown-Prozessortyp mit einem leicht modifizierten Lastprofil durchgeführt. Jeder Benutzer schreibt nun zweimal einen bebilderten Text, meldet sich also nur ca. alle halbe Stunde ab und wieder an, was zu einer Halbierung der An- und Abmeldevorgänge führt. Die geänderte Last bewirkt natürlich auch andere maximale Benutzeranzahlen. Interessant ist aber, dass durch die geänderte Last die Prozessoren bei den Messungen mit zwei Prozessoren besser ausgelastet werden konnten (ca. 70% - 80%) und sich damit bei den Prozessoren der höheren Leistungsklasse auch die gemessene Skalierung von einer auf zwei CPUs von ca. 14% auf ca. 30% verbesserte. Dies konnte sowohl bei Microsoft Terminal Server als auch bei Messungen mit dem Citrix Presentation Server beobachtet werden. 32- und 64-bit-Betriebssystem In der nebenstehenden Grafik sind die Ergebnisse von Microsoft Terminal Server Vergleichsmessungen mit 32-bit und 64-bit Windows Server 2003 R2 Betriebssystem aufgeführt. Die Messungen erfolgten mit dem T4US Medium User Profil auf einer PRIMERGY BX620 S4 mit einem Woodcrest-Prozessor. Die durch den Benchmark ermittelte maximale Benutzerzahl lag bei den 64- bit-messungen etwa 5% unter der Benutzerzahl, die mit einem 32-bit-Betriebssystem ermittelt wurde. Das 64-bit-Betriebssystem benötigt durch seine breiteren Adresszeiger mehr Rechenzeit als das 32-bit-Betriebssystem, da durch die breiteren Adresszeiger mehr Daten transportiert werden müssen. Die Vorteile des 64-bit-Betriebssystems, die größeren Betriebssystemtabellen und die Vergrößerung des Adressraums, kamen hier nicht zum tragen, da diese bei den 32-bit-Messungen nicht der begrenzende Faktor waren. Daraus darf jedoch nicht abgeleitet werden, dass eine PRIMERGY BX620 S4 als Terminal Server unter 64-bit generell weniger Leistung liefert. Das hängt stark von dem verwendeten Lastprofil und daraus resultierenden Engpässen ab. Ausführlich behandelt wird dieser Aspekt in dem Dokument Terminal Server Sizing Guide - 64-bit Technologie (siehe Literaturverzeichnis). Ein etwas anderes Verhalten zeigt der Terminal Server mit dem Citrix Presentation Server 4.0 auf einer PRIMERGY BX620 S4 wiederum mit Xeon 5160 Prozessoren. Bei den 32-bit-Messungen brachte die Skalierung von einem nach zwei physikalischen Prozessoren nur eine Leistungssteigerung von ca. 23%. Unter dem 64-bit-Betriebssystem wurde bei Verdoppelung der physikalischen Prozessoren eine Leistungssteigerung von ca. 50% gemessen. Das ist etwa die gleiche Größenordnung wie unter dem Microsoft Terminal Server. Die Erklärung liegt in dem erhöhten Speicherverbrauch eines Citrix Presentation Server für eine Benutzersession im Vergleich zum Microsoft Terminal Server. Dieser größere Speicherverbrauch und der unter einem 32-bit-Betriebssystem kleinere Systemcache führen dazu, dass ab einer bestimmten Anzahl Benutzer die Trefferrate im Systemcache sinkt und damit die Antwortzeiten länger werden. Damit wird bei unserem Messszenario die über die Antwortzeiten ermittelte maximale Anzahl Benutzer früher er- dies bei 187 Benutzern. reicht, beim Xeon 5160 Prozessor geschah Bei den leistungsfähigeren Prozessoren in der Quad-Core Leistungsklasse kann der Engpass im Systemcache durch CPU-Leistung teilweise kompensiert werden, jedoch existiert in diesem Messszenario auch eine Grenze von etwa 200 Citrix-Benutzern durch das 32-bit-Betriebssystem. Das Betriebssystem hat dann nicht mehr die benötigten Resourcen im Paged Pool und bei den Page Table Entries, so dass ein Login der Benutzer bereits zu einem Zeitpunkt mit einer Fehlermeldung quittiert wird, an dem die Antwortzeiten des Terminal Servers für die bereits angemeldeten Benutzer noch im erlaubten Rahmen liegen. Das erklärt, weshalb unter dem 64-bit-Betriebssystem bei zwei Prozessoren die gemessen Anzahl Citrix Benutzer höher lag als bei dem 32-bit-Betriebssystem. Diese Messergebnisse verdeutlichen noch einmal, dass die Frage Wie viel Leistungssteigerung erreicht man durch eine zweite CPU? immer nur im Zusammenhang mit der detaillierten Betrachtung des Benutzerprofils und damit erfolgender Engpassanalyse beantwortet werden kann. Fujitsu Technology Solutions 2009 Seite 22 (26)

23 Arbeitsspeicher Den stärksten Einfluss auf die Leistungsfähigkeit eines Terminal Servers übt der Arbeitsspeicher aus. Dabei spiegelt sich dies insbesondere in der Antwortzeit wider, denn Windows verschafft sich bei Bedarf weiteren virtuellen Speicher durch Auslagern (Swappen) von momentan nicht benötigten Daten aus dem Arbeitsspeicher (RAM) in die Auslagerungsdatei (Swap-File) auf Festplatte. Da Plattenzugriffe aber mindestens um die Größenordnung 1000 langsamer sind als Speicherzugriffe, führt dies unmittelbar zum Zusammenbruch der Leistung und zu einem rapiden Anstieg der Antwortzeiten. Bei Terminal Server wächst der Speicherbedarf bei allen PRIMERGY Systemen linear mit der Anzahl der Benutzer, dies ist auch bei der PRIMERGY BX620 S4 der Fall, wie die zwei Grafiken zum 32-bit- und 64-bit-System veranschaulichen. Trägt man den belegten Speicher, den Committed Speicher und das Working Set grafisch auf, so erkennt man einen linearen Verlauf, der mit steigender Benutzeranzahl wächst. Der Anstieg der Geraden beim 64-bit-Betriebssystem ist jedoch steiler. Das 32-bit-Betriebssystem (Windows Server 2003 Enterprise Edition mit Microsoft Terminal Services) hat einen Grundbedarf von 128 MB, und pro Benutzer bzw. Client werden weitere 20 MB benötigt. Der Grundbedarf des 64-bit-Systems erhöht sich auf ca. 150 MB. In dem Messszenario arbeiten allerdings alle Benutzer mit der gleichen Applikation, daher zeigen alle Benutzergruppen den gleichen Speicherbedarf. Der Speicherbedarf ist jedoch von den verwendeten Applikationen abhängig und muss kundenspezifisch ermittelt werden. Hierbei sollte man beachten, dass die Gesamtleistung des Systems durch die schwächste Komponente bestimmt wird. Hinzu kommt, dass durch die Architektur des 32-bit-Betriebssystems die internen Strukturen und der virtuelle Adressraum eingeschränkt sind, so dass man den maximalen Speicherausbau der PRIMERGY BX620 S4 von 32 GB für Terminal Server unter 32-bit nicht ausnutzen kann. Insbesondere Anwendungen, die Speicher- und nicht CPU-limitiert sind, profitieren von der 64-bit-Architektur. Dabei sollte aber auch nicht verschwiegen werden, dass 64-bit-Betriebssysteme und 64-bit-Anwendungen in der Regel mehr Arbeitsspeicher benötigen als die 32-bit- Versionen, denn alle Adresszeiger sind bei 64- bit doppelt so breit. Im Extremfall führt das bei 64-bit zu einem doppelten Speicherbedarf im Vergleich zu 32-bit. Wie die nebenstehende Grafik zeigt, belegt der gleiche Benutzer, der den Desktop gestartet hat und mit Microsoft Word 2003 arbeitet, auf dem 64-bit-System ca. 60% mehr Arbeitsspeicher. Die Anwendung, mit der der Terminal Server Benutzer arbeitet, ist in beiden Fällen Microsoft Word, welches heute nur als 32-bit-Version existiert. Die Microsoft Terminal Services liegen als Bestandteil des Betriebssystems in einer 64-bit- (Medium Lastprofil, Microsoft Office 2003, Microsoft Terminal Services) Version vor. Fujitsu Technology Solutions 2009 Seite 23 (26)