Performance Report PRIMERGY RX330 S1

Transkript

1 Performance Report PRIMERGY RX330 S1 Version 3.1 Februar 2009 Seiten 37 Abstract In diesem Dokument sind alle Benchmarks, die für die PRIMERGY RX330 S1 durchgeführt wurden, zusammengefasst. Ferner werden die Leistungsdaten der PRIMERGY RX330 S1 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 SPECcpu SPECjbb SPECpower_ssj OLTP...18 OLTP SAP SD...22 Terminal Server...25 vservcon...31 Literatur...36 Kontakt...37

2 Technische Daten Die PRIMERGY RX330 S1 ist ein mit nur zwei Höheneinheiten besonders Platz sparender Dual-Socket Rack-Server mit BroadCom HT2100/HT1000 Chipsatz, AMD Dual-Core oder Quad-Core Opteron Prozessoren, 4 Speicherbänken mit je 2 Slots für 2-way interleaved registered ECC DDR2-SDRAM, HyperTransport Bus-Technologie, einem onboard 8-Port SAS Controller für sechs interne Festplatten (RAID 0, RAID 1 oder RAID 1E), einem onboard dual 1-GBit Ethernet- Controller, einem PCIe x8 Steckplatz und einem Steckplatz für eine Riser-Karte. PRIMERGY Server Management Lösungen (ServerStart, ServerView, RemoteView) erleichtern die Installation, Administration und das Monitoring des Servers. Detaillierte technische Informationen finden Sie im Datenblatt PRIMERGY RX330 S1. Fujitsu Technology Solutions 2009 Seite 2 (37)

3 SPECcpu2000 Benchmark-Beschreibung SPECcpu2000 ist ein Benchmark, der die Systemeffizienz bei Integer- und Fließkomma-Operationen misst. Er besteht aus einer Integer-Testsuite (SPECint2000), die 12 Applikationen enthält, und einer Fließkomma-Testsuite (SPECfp2000), die 14 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. SPECcpu2000 ist nicht an ein spezielles Betriebssystem gebunden. Der Benchmark ist als Source-Code verfügbar und wird vor der eigentlichen Messung kompiliert. Daher gehen die verwendete Compiler-Version und -Optimierungseinstellungen in die Messung mit ein. SPECcpu2000 beinhaltet zwei verschiedene Methoden der Performance-Messung: Die erste Methode (SPECint2000 bzw. SPECfp2000) ermittelt die Zeit, die für die Bearbeitung einer bestimmten Aufgabe benötigt wird. Die zweite Methode (SPECint_rate2000 bzw. SPECfp_rate2000) ermittelt den Durchsatz, d.h. wie oft eine Aufgabe in einer vorgegebenen Zeit erledigt werden kann. 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 SPECint2000 Integer peak aggressiv SPECint_base2000 Integer base konservativ SPECint_rate2000 Integer peak aggressiv SPECint_rate_base2000 Integer base konservativ SPECfp2000 Fließkomma peak aggressiv SPECfp_base2000 Fließkomma base konservativ SPECfp_rate2000 Fließkomma peak aggressiv SPECfp_rate_base2000 Fließkomma base konservativ Messergebnis Geschwindigkeit Durchsatz Geschwindigkeit Durchsatz Anwendung Monoprozessor Mono- und Multiprozessor Monoprozessor Mono- und Multiprozessor Bei den Messergebnissen handelt es sich um das geometrische Mittel aus normalisierten Verhältniswerten, die für die Einzel-Benchmarks ermittelt wurden. Normalisiert heißt, dass gemessen wird, wie schnell das Testsystem verglichen mit einem Referenzsystem ist. Für das Referenzsystem wurde als SPECint_2000- und SPECfp_2000-Wert 100 festgelegt. Im Falle der rate-messergebnisse liegt dieser Wert bei So bedeutet beispielsweise ein SPECint_base2000-Wert von 200 für das Messsystem, dass es diesen Benchmark mindestens doppelt so schnell wie das Referenzsystem bewältigt hat. Die ungenaue Bezeichnung mindestens deshalb, weil bei der Berechnung des Ergebnisses das geometrische Mittel angewandt wird. Gegenüber dem arithmetischen Mittel führt dies dazu, dass bei unterschiedlich hohen Einzelergebnissen eine Gewichtung zugunsten der niedrigeren Einzelergebnisse erfolgt. Benchmark-Ergebnisse Die PRIMERGY RX330 S1 wurde mit ein und zwei Opteron Prozessoren 2210, 2212, 2214, 2216, 2218 und 2220 vermessen. Die SPECint-Benchmark-Programme wurden mit dem Intel C++ Compiler 9.1 kompiliert. Die Messungen erfolgten unter Windows Server 2003 Enterprise Edition SP1 (32-bit). Die SPECfp-Benchmark-Programme wurden mit dem PathScale EKOPath Compiler Rel. 2.5 kompiliert. Die Messungen erfolgten unter SUSE Linux Enterprise Server 10 (64-bit). Alle Ergebnisse sind unter veröffentlicht. Prozessor GHz SPECint_rate_base2000 SPECint_rate Chip 2 Chips 1 Chip 2 Chips Opteron Opteron Opteron Opteron Opteron Opteron Opteron n/a n/a n/a n/a SPEC, SPECint, SPECfp und das SPEC-Logo sind eingetragene Warenzeichen der Standard Performance Evaluation Corporation (SPEC). Fujitsu Technology Solutions 2009 Seite 3 (37)

4 Die SPECint_rate_2000-Ergebnisse liegen 8-10% über den SPECint_rate_base2000-Ergebnissen. Die Skalierung vom Mono- zum Dualprozessorsystem ist optimal. Bei den Messungen wurde mit zwei Chips gegenüber einem Chip ein Zuwachs von % erreicht. Prozessor GHz SPECfp_rate_base2000 SPECfp_rate Chip 2 Chips 1 Chip 2 Chips Opteron Opteron Opteron Opteron Opteron Opteron Opteron n/a n/a n/a n/a Die SPECfp_rate_2000-Ergebnisse liegen 6-9% über den SPECfp_rate_base2000-Ergebnissen. Die Skalierung vom Mono- zum Dualprozessorsystem ist optimal. Bei den Messungen wurde mit 2 Chips gegenüber einem Chip ein Zuwachs von 97-99% erreicht. Fujitsu Technology Solutions 2009 Seite 4 (37)

5 Vergleicht man die PRIMERGY RX330 S1 mit der PRIMERGY RX220 in jeweils performantester Ausstattung, so ergibt sich in der Integer-Testsuite eine Durchsatzsteigerung von 9% (base) bzw. 8% (peak) und in der Fließkomma-Testsuite eine Durchsatzsteigerung von 23% (1 Chip, base) und 24% (2 Chips, base) bzw. 25% (1 Chip, peak) und 26% (2 Chips, peak). Benchmark-Umgebung Alle SPECcpu2000 Messungen wurden auf einer PRIMERGY RX330 S1 mit folgender Hard- und Software-Ausstattung vorgenommen: Hardware Modell PRIMERGY RX330 S1 CPU Opteron 2210, 2212, 2214, 2216, 2218 und 2220 Anzahl CPUs 1, 2 Primary Cache 64 kb instruction + 64 kb data on chip, pro Core Secondary Cache 1 MB (I+D) on chip, pro Core weitere Caches nein Memory 1 Chip: 4 x 4 GB PC DDR2-SDRAM 2 Chips: 8 x 4 GB PC DDR2-SDRAM Software Betriebssystem SPECint: Windows Server 2003 Enterprise Edition SP1 (32-bit) SPECfp: SUSE Linux Enterprise Server 10 (64-bit) Compiler SPECint: Intel C++ Compiler 9.1 SPECfp: PathScale EKOPath Compiler Rel. 2.5 Fujitsu Technology Solutions 2009 Seite 5 (37)

6 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 Zwischen April und Mai 2007 wurde die PRIMERGY RX330 S1 mit ein und zwei Opteron Prozessoren 2210, 2212, 2214, 2216, 2218, 2220 und 2222 vermessen. Alle Benchmark-Programme wurden mit dem PathScale EKOPath Compiler Rel. 3.0 kompiliert. Die Messungen erfolgten unter SUSE Linux Enterprise Server 10 (64-bit). Alle Ergebnisse sind unter veröffentlicht. SPEC, SPECint, SPECfp und das SPEC-Logo sind eingetragene Warenzeichen der Standard Performance Evaluation Corporation (SPEC). Fujitsu Technology Solutions 2009 Seite 6 (37)

7 Prozessor GHz SPECint_rate_base2000 SPECint_rate Chip 2 Chips 1 Chip 2 Chips Opteron Opteron Opteron Opteron Opteron Opteron Opteron Die SPECint_rate_2006-Ergebnisse liegen 10-12% über den SPECint_rate_base2006-Ergebnissen. Die Skalierung vom Mono- zum Dualprozessorsystem ist optimal. Bei den Messungen wurde mit zwei Chips gegenüber einem Chip ein Zuwachs von 97-99% erreicht. Prozessor GHz SPECfp_rate_base2000 SPECfp_rate Chip 2 Chips 1 Chip 2 Chips Opteron Opteron Opteron Opteron Opteron Opteron Opteron Die SPECfp_rate_2006-Ergebnisse liegen 5-6% über den SPECfp_rate_base2006-Ergebnissen. Die Skalierung vom Mono- zum Dualprozessorsystem ist optimal. Bei den Messungen wurde mit zwei Chips gegenüber einem Chip ein Zuwachs von % erreicht. Fujitsu Technology Solutions 2009 Seite 7 (37)

8 Zwischen November 2008 und Januar 2009 wurde die PRIMERGY RX330 S1 mit zwei Quad-Core Opteron Prozessoren 2356, 2372 HE, 2376 HE, 2376, 2380 und 2384 vermessen. Alle Benchmark-Programme wurden mit dem PGI Compiler 7.2 und dem PathScale Compiler 3.2 kompiliert und die Messungen unter SUSE Linux Enterprise Server 10 SP2 (64-bit) durchgeführt. Prozessor Cores GHz L2-Cache L3-Cache TDP SPECint_rate_base2006 SPECint_rate chips 2 chips Opteron 2344 HE ½ MB pro Core 2 MB pro Chip 55 Watt n/a n/a Opteron 2346 HE ½ MB pro Core 2 MB pro Chip 55 Watt n/a n/a Opteron 2347 HE ½ MB pro Core 2 MB pro Chip 55 Watt n/a n/a Opteron 2350 HE 4 2 ½ MB pro Core 2 MB pro Chip 55 Watt 75.3 (est.) 86.5 (est.) Opteron ½ MB pro Core 2 MB pro Chip 75 Watt n/a n/a Opteron ½ MB pro Core 2 MB pro Chip 75 Watt Opteron 2372 HE ½ MB pro Core 6 MB pro Chip 55 Watt Opteron 2376 HE ½ MB pro Core 6 MB pro Chip 55 Watt Opteron ½ MB pro Core 6 MB pro Chip 75 Watt Opteron ½ MB pro Core 6 MB pro Chip 75 Watt Opteron ½ MB pro Core 6 MB pro Chip 75 Watt Die SPECint_rate_2006-Ergebnisse liegen rund 15% über den SPECint_rate_base2006-Ergebnissen. Prozessor Cores GHz L2-Cache L3-Cache TDP SPECint_rate_base2006 SPECint_rate chips 2 chips Opteron 2344 HE ½ MB pro Core 2 MB pro Chip 55 Watt n/a n/a Opteron 2346 HE ½ MB pro Core 2 MB pro Chip 55 Watt n/a n/a Opteron 2347 HE ½ MB pro Core 2 MB pro Chip 55 Watt n/a n/a Opteron 2350 HE 4 2 ½ MB pro Core 2 MB pro Chip 55 Watt 68.7 (est.) 75.4 (est.) Opteron ½ MB pro Core 2 MB pro Chip 75 Watt n/a n/a Opteron ½ MB pro Core 2 MB pro Chip 75 Watt Opteron 2372 HE ½ MB pro Core 6 MB pro Chip 55 Watt Opteron 2376 HE ½ MB pro Core 6 MB pro Chip 55 Watt Opteron ½ MB pro Core 6 MB pro Chip 75 Watt Opteron ½ MB pro Core 6 MB pro Chip 75 Watt Opteron ½ MB pro Core 6 MB pro Chip 75 Watt Die SPECfp_rate_2006-Ergebnisse liegen 10-13% über den SPECfp_rate_base2006-Ergebnissen. Fujitsu Technology Solutions 2009 Seite 8 (37)

9 Benchmark-Umgebung Die mit den Dual-Core Prozessoren durchgeführten SPECcpu2006-Messungen wurden auf einer PRIMERGY RX330 S1 mit folgender Hard- und Software-Ausstattung vorgenommen: Hardware Modell PRIMERGY RX330 S1 CPU Opteron 2210, 2212, 2214, 2216, 2218, 2220 und 2222 Anzahl CPUs 1, 2 Primary Cache 64 kb instruction + 64 kb data on chip, pro Core Secondary Cache 1 MB (I+D) on chip, pro Core weitere Caches nein Memory 1 Chip: 4 x 4 GB PC DDR2-SDRAM 2 Chips: 8 x 4 GB PC DDR2-SDRAM Software Betriebssystem SUSE Linux Enterprise Server 10 (64-bit) Compiler PathScale EKOPath Compiler Rel. 3.0 Die mit den Quad-Core Prozessoren durchgeführten SPECcpu2006-Messungen wurden auf einer PRIMERGY RX330 S1 mit folgender Hard- und Software-Ausstattung vorgenommen: Hardware Modell PRIMERGY RX330 S1 CPU Opteron 2356, 2376, 2380 und 2384 Anzahl CPUs 2 Primary Cache 64 kb instruction + 64 kb data on chip, pro Core Secondary Cache ½ MB (I+D) on chip, pro Core weitere Caches Opteron 2356: 2 MB (I+D) on chip, pro Chip andere: 6 MB (I+D) on chip, pro Chip Memory 8 x 4 GB PC DDR2-SDRAM Software Betriebssystem SUSE Linux Enterprise Server 10 SP2 (64-bit) Compiler PGI Compiler Rel. 7.2 and PathScale Compiler Rel. 3.2 Fujitsu Technology Solutions 2009 Seite 9 (37)

10 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 10 (37)

11 Benchmark-Ergebnisse Im April 2007 wurde die PRIMERGY RX330 S1 mit zwei Opteron 2220 Prozessoren bei einem Speicherausbau von 16 GB vermessen. Die Messung wurde unter Windows Server 2003 Enterprise x64 Edition SP1 durchgeführt. Als JVM wurden zwei Instanzen von JRockit(R) 5.0 P (build P _ windows-x86_64) von BEA verwendet. JVM Scores JVM run PRIMERGY RX220 2 x Opteron 285 Tyan Thunder h2000m 2 x Opteron 2220 PRIMERGY RX330 S1 2 x Opteron bops/jvm = bops/jvm = bops/jvm = bops = bops = bops = Im Vergleich zur PRIMERGY RX220 erzielte die PRIMERGY RX330 S1 ein 34% höheres Ergebnis. Im Vergleich zur Thunder h2000m von Tyan erzielte die PRIMERGY RX330 S1 mit den gleichen Prozessoren ein 1% höheres Ergebnis. 1 Im August 2007 wurde die PRIMERGY RX330 S1 mit zwei Opteron 2222 Prozessoren vermessen. Gegenüber der Messung vom April 2007 wurde eine neuere JVM-Version verwendet. Es kam eine Instanz von JRockit(R) 5.0 P (build P _ windows-x86_64) von BEA zum Einsatz. JVM run Dell PowerEdge x Opteron 2222SE (120 Watt) JVM Scores PRIMERGY RX330 S1 2 x Opteron 2222 (95 Watt) bops/jvm = bops/jvm = bops = bops = Im Vergleich zur PRIMERGY RX220 erzielte die PRIMERGY RX330 S1 ein 50% höheres Ergebnis. Im Vergleich zur PowerEdge 2970 von Dell erzielte die PRIMERGY RX330 S1 mit Prozessoren gleicher Geschwindigkeit bei geringerem Stromverbrauch ein 1% höheres Ergebnis. 2 Bei allen Messungen flossen die Ergebnisse von 2 bis 4 Warenhäusern in das Benchmark-Ergebnis ein. Quelle: Stand: Die oben genannten Vergleichswerte zu Wettbewerbsprodukten geben den Stand vom 30. August 2007 wieder. Der vorgestellte Vergleich basiert auf den SPECjbb2005-Ergebnissen für Server mit zwei Opteron 2220 Prozessoren. Es werden die zu diesem Zeitpunkt besten verfügbare Systeme von Tyan und Fujitsu Siemens Computers, heute firmierend unter Fujitsu, verglichen. Die aktuellen SPECjbb2005-Ergebnisse sind zu finden unter Die oben genannten Vergleichswerte zu Wettbewerbsprodukten geben den Stand vom 30. August 2007 wieder. Der vorgestellte Vergleich basiert auf den SPECjbb2005-Ergebnissen für Server mit zwei Opteron 2222 Prozessoren. Es werden die zu diesem Zeitpunkt besten verfügbare Systeme von Dell und Fujitsu Siemens Computers, heute firmierend unter Fujitsu, verglichen. Die aktuellen SPECjbb2005-Ergebnisse sind zu finden unter Fujitsu Technology Solutions 2009 Seite 11 (37)

12 Quelle: Stand: Im Dezember 2008 wurde die PRIMERGY RX330 S1 mit den Opteron Prozessoren 2380 und 2384 bei einem Speicherausbau von 16 GB vermessen. Die beiden Messungen wurden unter Windows Server 2008 Enterprise x64 Edition durchgeführt. Als JVM wurden zwei Instanzen von JRockit(R) 6.0 P (build P _o_CR371811_CR _ windows-x86_64) von Oracle verwendet. Bei allen Messungen mit Dual-Core Prozessoren flossen die Ergebnisse von 2 bis 4 Warenhäusern in das Benchmark- Ergebnis ein, bei der Messung mit Quad-Core Prozessoren die Ergebnisse von 4 bis 8 Warenhäusern. Fujitsu Technology Solutions 2009 Seite 12 (37)

13 Im Vergleich zur PRIMERGY RX220 erzielte die PRIMERGY RX330 S1 ein 345% höheres Ergebnis. Benchmark-Umgebung Die SPECjbb2005 Messungen wurden auf einer PRIMERGY RX330 S1 mit folgender Hard- und Software-Ausstattung vorgenommen: Hardware Modell PRIMERGY RX330 S1 CPU Opteron 2220, 2222, 2380, 2384 Anzahl Chips Opteron 2220, 2222: 2 Chips, 4 Cores, 2 Cores pro Chip Opteron 2380, 2384: 2 Chips, 8 Cores, 4 Cores pro Chip Primary Cache 64 KB instruction + 64 KB data on chip, pro Core Secondary Cache Opteron 2220, 2222: 1 MB (I+D) on chip, pro Core Opteron 2380, 2384: ½ MB (I+D) on chip, pro Core weitere Caches Opteron 2220, 2222: keine Opteron 2380, 2384: 6 MB (I+D) on chip, pro Chip Memory Opteron 2220, 2222: 8 x 2 GB PC DDR2-SDRAM Opteron 2380, 2384: 8 x 2 GB PC DDR2-SDRAM Software Betriebssystem Opteron 2220, 2222: Windows Server 2003 Enterprise x64 Edition SP1 Opteron 2380, 2384: Windows Server 2008 Enterprise x64 Edition Opteron 2220: BEA JRockit(R) 5.0 P (build P _ windows-x86_64) Opteron 2222: BEA JRockit(R) 5.0 P JVM Version (build P _ windows-x86_64) Opteron 2380, 2384: Oracle JRockit(R) 6.0 P (build P _o_CR371811_CR _ windows-x86_64) Fujitsu Technology Solutions 2009 Seite 13 (37)

14 SPECpower_ssj2008 Benchmark-Beschreibung SPECpower_ssj2008 ist der erste Industriestandard-Benchmark von SPEC zur Beurteilung des Stromverbrauchs eines Servers im Verhältnis zu dessen Durchsatz. Mit SPECpower_ssj2008 hat SPEC in ähnlicher Weise wie auch für Durchsatzmessungen Standards auf dem Gebiet der elektrischen Leistungsmessung definiert. Der Workload des Benchmarks basiert auf typischen serverseitigen Java Business Applikationen. Er ist skalierbar, multithreaded, auf eine große Anzahl von Plattformen portierbar und leicht auszuführen. Der Benchmark testet CPUs, Caches, die Speicherhierarchie und die Skalierbarkeit von symmetrischen Multiprozessorsystemen (SMPs), wie auch die Implementationen der Java Virtual Machine (JVM), Just In Time (JIT) Compiler, Garbage Collection, Threads und einige weitere Betriebssystemaspekte. SPECpower_ssj2008 zeichnet den Stromverbrauch von Servern bei unterschiedlichen Belastungsstufen in 10%-Schritten von 100% bis Active Idle während einer festgesetzten Zeitspanne auf. Der abgestufte Workload ist der Tatsache geschuldet, dass Auslastung und Stromverbrauch von Servern im Verlauf von Tagen oder Wochen deutlich variieren. Zur Berechnung der Power-Performance-Metrik über alle Stufen werden die gemessenen Transaktionsdurchsätze jedes Messintervalls aufsummiert und dann durch die Summe der während jedes Messintervalls durchschnittlich aufgenommenen elektrischen Leistung geteilt. Das Ergebnis ist ein "overall ssj_ops/watt" genannter Wert. Diese Kennzahl gibt Aufschluss über die Energie-Effizienz des gemessenen Servers. Der definierte Messstandard ermöglicht es einem Kunden Vergleiche anzustellen zwischen verschiedenen Konfigurationen und Servern, die mit SPECpower_ssj2008 vermessen wurden. Das nebenstehende Diagramm zeigt einen typischen Graphen eines SPECpower_ssj2008-Ergebnisses. Der Benchmark läuft auf den unterschiedlichsten Betriebssystemen und Hardware-Architekturen und stellt dabei keine besonderen Anforderungen an die Client- und Storage-Infrastruktur. Die Minimalausstattung für einen SPEC-konformen Test besteht aus zwei vernetzten Computern sowie einem Power Analyser und einem Temperatursensor. Der eine Computer ist das System Under Test (SUT), auf dem eines der unterstützten Betriebssysteme und die JVM installiert sind. Die JVM stellt die Umgebung bereit, die für den Ablauf des in Java implementierten SPECpower_ssj2008-Workloads benötigt wird. Der zweite Computer ist das sogenannte Collect and Control System (CCS), das die Ausführung des Benchmarks kontrolliert und die elektrische Leistungsaufnahme sowie die Durchsatz- und Temperaturwerte aufnimmt und protokolliert. Das nebenstehende Diagramm gibt Ihnen einen Überblick über die Grundstruktur der Benchmark-Konfiguration mit den dazugehörigen Komponenten. SPEC, SPECpower_ssj2008 und das SPEC-Logo sind eingetragene Warenzeichen der Standard Performance Evaluation Corporation (SPEC). Fujitsu Technology Solutions 2009 Seite 14 (37)

15 Benchmark-Ergebnisse Im Januar 2009 wurde die PRIMERGY RX330 S1 mit einem AMD Opteron 2376 HE Prozessor und einem Speicherausbau von 8 GB PC2-6400P DDR2-SDRAM vermessen. Die Messung erfolgte unter Windows Server 2008 Enterprise x64 Edition. Als JVM wurde JRockit(R) 6.0 P von Oracle eingesetzt. In der Konfiguration mit der höchsten Energieeffizienz wurde ein Ergebnis von 833 overall ssj_ops/watt erreicht. Das nebenstehende Diagramm zeigt die Ergebnisse der oben beschriebenen Konfiguration, gemessen mit der PRIMERGY RX330 S1. Die roten horizontalen Balken geben für jeden Ziellastbereich (an der y- Achse des Diagramms abgebildet) das Verhältnis zwischen Durchsatz und Stromverbrauch (Performance to Power Ratio) in ssj_ops/watt (obere x-achse) wieder. Die mit kleinen Rauten versehene blaue Linie zeigt den Verlauf der durchschnittlichen elektrischen Leistungsaufnahme (untere x-achse) in jedem Ziellastbereich. Das Diagramm zeigt, wie die Effizienz des Servers mit jedem Ziellastbereich in 10%- Schritten von 100% bis Active Idle abnimmt. Die schwarze, vertikale Linie gibt das Benchmark-Ergebnis der PRIMERGY RX330 S1 von 833 overall ssj_ops/watt wieder. Dieses ist der Quotient aus der Summe der Transaktionsdurchsätze aller Messintervalle und der Summe der gemessenen elektrischen Leistungen aller Messintervalle. In der folgenden Tabelle sind die Benchmark-Ergebnisse bezüglich des Durchsatzes in ssj_ops, der elektrischen Leistungsaufnahme in Watt und des daraus resultierenden Energie-Effizienz-Werts für jede einzelne Laststufe aufgelistet. Performance Power Energy Efficiency Target Load ssj_ops Average Power (W) ssj_ops/watt 100% 280, ,361 90% 255, ,261 80% 225, ,143 70% 199, ,055 60% 171, % 142, % 114, % 86, % 57, % 27, Active Idle ssj_ops / power = 833 Die Konfiguration war getunt, um das für diesen Server bestmögliche Resultat bezüglich Durchsatz pro Watt zu erzielen. Die Speicherkonfiguration von 4 x 2 GB wurde gewählt, um die Kriterien für eine maximale Performance bei geringstem Energieverbrauch zu erfüllen; so wurde pro verfügbarem Speicherkanal jeweils nur ein Steckplatz bestückt. Mit dieser Konfiguration kann der Benchmark die volle Kapazität der verfügbaren Speicherbandbreite nutzen und verbraucht dabei weniger Energie als eine im Durchsatz ähnliche Konfiguration mit 8 DIMMs. Der wichtigste Faktor bei der Hardwarekonfiguration ist aber die richtige Wahl des Prozessors. Prozessoren sind der Teil eines Servers, der neben dem Speichersubsystem am meisten Energie verbraucht. Für die PRIMERGY RX330 S1 erbrachte der Quad-Core AMD Opteron 2376 HE Prozessor mit einer Thermal Design Power (TDP) von 55 Watt die Ergebnisse mit dem höchsten Effizienzgrad. Fujitsu Technology Solutions 2009 Seite 15 (37)

16 Das nächste Diagramm zeigt den Vergleich zwischen den AMD Opteron 2376 HE und den Opteron 2384 Prozessoren, gemessen auf der PRIMERGY RX330 S1. Alle anderen Konfigurationsdetails blieben während der Messungen unverändert. Der Durchsatz ist direkt abhängig von der Taktfrequenz der jeweiligen CPUs. Diese Tatsache geben die Balken im Diagramm wieder. Die Messung mit der leistungsstärksten AMD Opteron 2384 (2.70 GHz) CPU liefert die höchsten Durchsatzwerte, die Messung mit der AMD Opteron 2376 HE CPU mit der geringsten Frequenz (2.30 GHz) die geringsten Durchsatzwerte in ssj_ops (linke y-achse). Wenn man sich die Kurven der durchschnittlichen elektrischen Leistungsaufnahme anschaut (rechte y-achse 1 ), dann fällt auf, dass sich das Verhältnis zwischen den Energieverbrauchswerten der verschiedenen CPUs mit jedem weiteren 10%- Schritt bei der Ziellast ändert. Während Active Idle und in den unteren Laststufen ist der Unterschied marginal. Die Ursache dafür sind die Power Management Funktionen der CPUs und des Betriebssystems, die es den CPUs ermöglichen, im Niedriglastbereich die Frequenz und die Grundspannung auf ein Niveau zu verringern, bei dem sie möglichst wenig Energie verbrauchen. In höheren Lastbereichen dagegen verringert sich der Einfluss der Power Management Features. Hier spielen die AMD Opteron 2376 HE CPUs ihre Stärken aus. Wegen ihres niedrigeren TDP von 55 Watt im Vergleich zu 75 Watt beim Opteron 2384 verbrauchen die AMD Opteron 2376 HE Prozessoren in höheren Lastbereichen deutlich weniger Energie. Bei 100% Last wird im Vergleich zwischen den AMD Opteron 2376 HE und den AMD Opteron 2384 Prozessoren 55 Watt weniger Strom verbraucht. Die deutlich geringere elektrische Leistungsaufnahme der AMD Opteron 2376 HE Prozessoren überwiegt dem im Verhältnis kleineren Performance-Nachteil und macht sie bei SPECpower_ssj2008-Messungen zur besten Wahl. Hinweis: Fujitsu reicht nicht alle SPECpower_ssj2008-Messergebnisse zur Veröffentlichung bei SPEC ein. Daher erscheinen nicht alle der hier vorgestellten Ergebnisse auf den Webseiten von SPEC. Da die Ergebnisse und Log-Dateien aller Messungen jedoch archiviert werden, kann die den SPECpower Run Rules entsprechende Ausführung der Messungen jederzeit belegt werden. Fujitsu Technology Solutions 2009 Seite 16 (37)

17 Das Energie-Effizienz-Diagramm zeigt das Verhältnis zwischen Durchsatz und Energieverbrauch (Energie-Effizienz) der zwei unterschiedlichen AMD Opteron Prozessoren. Es gibt einen Überblick über die Benchmark-Ergebnisse jeder Konfiguration in overall ssj_ops/watt (linke y-achse 1 ) und wie viel elektrische Leistung in Watt (rechte y-achse 1 ) während des Benchmark-Laufs verbraucht wurde. Wie zu erkennen, erreicht die Konfiguration mit dem AMD Opteron 2376 HE im Vergleich zu dem Opteron 2384 ein besseres Ergebnis. Diese Prozessoren haben eine niedrigere Leistungsaufnahme und sind deshalb um 1,45% energieeffizienter. Obwohl die AMD Opteron 2376 HE Prozessoren wegen der geringeren Prozessortaktfrequenz den geringeren Durchsatz in ssj_ops liefern, erreichen sie das höhere Benchmark-Ergebnis von 833 overall ssj_ops/watt. Benchmark-Umgebung Die hier vorgestellte SPECpower_ssj2008-Messung wurde unter Verwendung des ZES Zimmer LMG95 Leistungsmessgerätes auf einer PRIMERGY RX330 S1 mit folgender Hard- und Software-Ausstattung vorgenommen: Hardware Model PRIMERGY RX330 S1 Processor (TDP) AMD Opteron 2376 HE (55 W), AMD Opteron 2384 (75 W) Number of chips 2 chips, 4 cores per chip Primary Cache 64 KB instruction + 64 KB data on chip, per core Secondary Cache 512 KB (I+D) on chip, per core Tertiary Cache 6 MB I+D on chip, per chip Memory 4 x 2 GB 1Rx4 PC2-6400P CL5 DDR2-SDRAM Network Interface 1 x 1 GBit LAN Broadcom NetXtreme Gigabit Ethernet (onboard) Disk Subsystem 1 LSI Adapter, SAS 3000 series, 8-port with SATA disk, 250 GB, 7,2 krpm, JBOD Power Supply Unit 1 x 625 W ASTEC DS Software Operating System Windows Server 2008 Enterprise x64 Edition JVM Version Oracle JRockit(R) 6.0 P (build P _o_CR371811_CR _ windows-x86_64) JVM options -Xms3300m -Xmx3300m -Xns2700m -XXaggressive -Xlargepages -Xgc:genpar -XXcallprofiling -XXgcthreads=4 -XXtlasize:min=4k,preferred=1024k -XXthroughputcompaction 1 Bei einigen Grafiken wurde die Skalierung der y-achsen angepasst. Aus Darstellbarkeitsgründen fangen diese nicht bei 0 an, sondern sind an den jeweiligen Wertebereich zwischen Active Idle und 100% Last angepasst. Fujitsu Technology Solutions 2009 Seite 17 (37)

18 OLTP Benchmark Beschreibung OLTP steht für Online Transaction Processing. Dem OLTP-Benchmark liegt das typische Anwendungsszenario einer Datenbank-Lösung zugrunde. Es werden bei OLTP Zugriffe auf eine Datenbank simuliert und die Anzahl erreichter Transaktionen pro Minute (tpm) als Maß für die Leistungsfähigkeit des vermessenen Systems ermittelt. Im Gegensatz zu Benchmarks, wie SPECint und TPC-C, die von unabhängigen Gremien standardisiert wurden und bei denen die Einhaltung des jeweiligen Reglements überwacht wird, ist OLTP 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 auf ein vertretbares Maß reduziert, sodass eine Vielzahl von Konfigurationen in akzeptabler Zeit vermessen werden kann. Auch wenn die beiden Benchmarks OLTP- und TPC-C ä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-Werte TPC-C-Werten ähnlich. Ein direkter Vergleich oder gar die Bezeichnung des OLTP-Ergebnisses als TPC-C-Ergebnis ist nicht zulässig. Benchmark-Ergebnisse Die PRIMERGY RX330 S1 wurde mit ein und zwei Opteron Prozessoren 2210, 2214, 2218 und 2222 bei Speicherausbauten von 8 bis 32 GB vermessen. OLTP-Benchmark-Ergebnisse sind in hohem Maße abhängig von den Ausbaumöglichkeiten eines Systems mit Festplatten und deren Controllern. Die PRIMERGY RX330 S1 war mit drei 2-Kanal Fibre Channel Controllern ausgestattet, über die acht FibreCAT CX500 mit insgesamt 660 Festplatten angeschlossen waren. Alle Ergebnisse wurden basierend auf dem Betriebssystem Microsoft Windows Server 2003 Enterprise x64 Edition SP1 und der Datenbank SQL Server 2005 Enterprise x64 Edition SP1 ermittelt. Die folgende Grafik zeigt die OLTP-Leistungsdaten der PRIMERGY RX330 S1. Gemessen wurden alle Werte der Opteron Prozessoren 2210 und 2222 sowie die Werte der Opteron Prozessoren 2214 und 2218 bei 32 GB RAM. Alle anderen Werte wurden auf Basis der Messwerte berechnet. Eine Verdopplung von 1 auf 2 Prozessoren bei gleichzeitiger Verdopplung der Speichermenge von 16 auf 32 GB bewirkt einen Performance-Zuwachs von 73-79%. Speicherengpässe ergaben sich bei Verwendung von 8 GB RAM und bei Messungen mit 2 Opteron 2220 und 2222 auch bei 16 GB RAM. Diese äußerten sich dadurch, dass performantere Prozessoren (z.b. Opteron 2222 im Vergleich zu Fujitsu Technology Solutions 2009 Seite 18 (37)

19 Opteron 2220) keine nennenswerte zusätzliche Performance generierten. Zu beachten ist, dass solche Engpässe stark vom verwendeten Workload abhängen. Die hier festgestellten Engpässe sind OLTP-spezifisch. Die folgende Grafik setzt die PRIMERGY RX330 S1 in Relation zur PRIMERGY RX220, jeweils in leistungsstärkster Ausbaustufe. Die PRIMERGY RX330 S1 erzielte einen 20% höheren Durchsatz. Benchmark-Umgebung Microsoft Windows Server 2003 Enterprise x64 Edition SP1 und SQL Server 2005 Enterprise x64 Edition SP1 Clients: 5 x PRIMERGY Econel 200 with 2 x Xeon 3.40 GHz, 2 MB SLC 2 GB RAM onboard LAN Server: PRIMERGY RX330 S1 1, 2 Opteron 2210, 2214, 2218 and GB RAM 2 x 2-channel FC controllers QLA x 2-channel FC controllers QLE2362 onboard LAN Storage: 8 x FibreCAT CX data disks (36 GB, 15 krpm) 1 x FibreCAT CX log disks (36 GB, 15 krpm) LAN Switch Fujitsu Technology Solutions 2009 Seite 19 (37)

20 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 RX330 S1 wurde mit ein und zwei Opteron Prozessoren 2210, 2214, 2218 und 2222 bei Speicherausbauten von 8 bis 32 GB vermessen. OLTP-2-Benchmark-Ergebnisse sind in hohem Maße abhängig von den Ausbaumöglichkeiten eines Systems mit Festplatten und deren Controllern. Die PRIMERGY RX330 S1 war mit drei 2-Kanal Fibre Channel Controllern ausgestattet, über die acht FibreCAT CX500 mit insgesamt 660 Festplatten angeschlossen waren. 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. Die folgende Grafik zeigt die OLTP-2-Leistungsdaten der PRIMERGY RX330 S1. Die Werte der Opteron Prozessoren 2212, 2216 und 2220 wurden nicht gemessen, sondern auf Basis der Messwerte der anderen Prozessoren berechnet. Eine Verdopplung der Anzahl Prozessoren bei gleichzeitiger Verdopplung der Speichermenge bewirkt einen Performance-Zuwachs von 82-88%. Fujitsu Technology Solutions 2009 Seite 20 (37)

21 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 RX330 S1 1, 2 Opteron 2210, 2214, 2218 and GB RAM 2 x 2-channel FC controllers QLA x 2-channel FC controllers QLE2362 onboard LAN Storage: 8 x FibreCAT CX data disks (36 GB, 15 krpm) 1 x FibreCAT CX log disks (36 GB, 15 krpm) LAN Switch Fujitsu Technology Solutions 2009 Seite 21 (37)

22 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 RX330 S1, ausgestattet mit zwei Opteron 2220 Prozessoren, mit SAP ECC Release 6.0 und MS SQL Server 2005 unter Windows Server 2003 Enterprise Edition am 13. März 2007 folgendes Ergebnis erzielte: Number of benchmark users Average dialog response time 1060 SD (Sales & Distribution) 1.93 seconds Throughput Processed Order Line items / hour Dialog steps / hour SAPS 5330 Average DB request time (dia/upd) sec / sec CPU utilization central server 99% Operating System central server Windows Server 2003 Enterprise Edition RDBMS SQL Server 2005 SAP ECC Release 6.0 Configuration Central Server PRIMERGY RX330 S1 2 Opteron 2220, 32 GB RAM Fujitsu Technology Solutions 2009 Seite 22 (37)

23 Mit der Zertifikationsnummer belegt SAP, dass die PRIMERGY RX330 S1, ausgestattet mit zwei Opteron 2356 Prozessoren, mit SAP ECC Release 6.0 und MS SQL Server 2005 unter Windows Server 2003 Enterprise Edition am 23. April 2008 folgendes Ergebnis erzielte: Number of benchmark users Average dialog response time 1910 SD (Sales & Distribution) 1.96 seconds Throughput Processed Order Line items / hour Dialog steps / hour SAPS 9580 Average DB request time (dia/upd) sec / sec CPU utilization central server 98% Operating System central server Windows Server 2003 Enterprise Edition RDBMS SQL Server 2005 SAP ECC Release 6.0 Configuration Central Server PRIMERGY RX330 S1 2 Opteron 2350, 32 GB RAM Im Vergleich zur gleichfalls auf Opteron Prozessortechnologie basierenden PRIMERGY RX220 erzielte die PRIMERGY RX330 S1 ein 120% besseres Ergebnis. Fujitsu Technology Solutions 2009 Seite 23 (37)

24 Benchmark-Umgebung Zertifikationsnummer Tier-Environment Load-Generator PRIMERGY RX600 4 Xeon MP 2.50 GHz, 512 KB SLC, 1 MB TLC 8 GB RAM Linux 2.6 R/3 & Database Server PRIMERGY RX330 S1 2 Opteron GB RAM 1 x LSI MegaRAID U320-2 with 128 MB cache 1 x LSI MegaRAID SAS 8344 ELP with 256 MB cache 1 x FibreCAT SX40 2 x PRIMERGY SX30 1 hard disk, 146 GB, 15 krpm, SAS 6 hard disks, 73 GB, 15 krpm, SAS 10 hard disks, 18 GB, 15 krpm, SCSI Windows Server 2003 Enterprise x64 Edition SP2 MS SQL Server 2005 (64-bit) SAP ECC Release 6.0 Zertifikationsnummer Tier-Environment Load-Generator PRIMERGY RX600 4 Xeon MP 2.50 GHz, 512 KB SLC, 1 MB TLC 8 GB RAM Linux 2.6 R/3 & Database Server PRIMERGY RX330 S1 2 Opteron GB RAM 1 hard disk, 146 GB, 15 krpm, SAS 4 hard disks, 300 GB, 15 krpm, SAS Windows Server 2003 Enterprise x64 Edition SP2 MS SQL Server 2005 (64-bit) SAP ECC Release 6.0 Fujitsu Technology Solutions 2009 Seite 24 (37)

25 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 vorneh- wer- men. Benutzeraktivitäten wie Tastatur- und Mauseingaben sowie Bildschirmausgaben können mit Hilfe des Aufzeichnungswerkzeugs T4US-Record in Echtzeit aufgezeichnet und in Benutzer bei T4US- T4USder Arbeit Record Skript einem T4US-Skript gespeichert werden. T4US-Skripte den während der Messung als Lastprofil verwendet. Der Lastsimulator von T4US besteht aus drei Komponenten. T4US-Control steuert und überwacht den gesamten System under Test (SUT) Simulationslauf zentral und ermittelt Messwerte bereits Controller Lastgenerator SUT während der Messung. Auf T4USjedem der Lastgeneratoren Playback laufen mehrere Instanzen des TS-Client T4US-Playback. Jedes T4US- Playback füttert einen T4US- Terminal Server Client in Playback Echtzeit mit Tastatur- und TS-Client Mauseingaben anhand der mit T4US-Record aufgezeichneten Skripte und überwacht die T4US- T4US- Bildschirminhalte des Terminal T4US- Agent Playback Server Terminal Server Clients. Durch hoch Control TS-Client auflösende Timer wird so die Antwortzeit des Terminal Servers 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 arbeitet, 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 been- werden, finden während det 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 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 25 (37)

26 Benchmark-Ergebnisse Die PRIMERGY RX330 S1 ist mit Prozessoren der AMD Opteron Reihe 22xx ausgestattet. Auf diesen Prozessoren sind sowohl 32-bit- als auch 64-bit-Betriebssysteme ablauffähig. Die Messungen erfolgten mit Windows Server 2003 R2 als 64-bit-Version. Auf Messungen mit der 32-bit-Version wurde verzichtet, da es nicht mehr opportun ist einen Terminal Server von der Leistungsfähigkeit einer PRIMERGY RX330 S1 unter 32-bit zu betreiben. Denn unter der 32-bit-Version ist die Leistungsfähigkeit eines Terminal Servers durch Engpässe in den System-Ressourcen limitiert. Siehe Terminal Server Sizing Guide - 64-bit Technologie. Die 32-bit- und 64-bit-Versionen von Windows Server 2003 R2 basieren 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. Die simulierten Benutzer arbeiteten mit dem Medium-Lastprofil unter Verwendung von Microsoft Office Das unterschiedliche Verhalten von Microsoft Terminal Services und Citrix Presentation Server wurde ebenfalls untersucht. Für alle Messungen wurden die gleichen Randbedingungen verwendet. 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 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 auf einem RAID 0 von vier 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 und nicht auf lokale Festplatten eines Terminal Servers. 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 RX330 S1 ist ein Dualprozessorsystem und kann nach Bedarf mit verschiedenen AMD Dual-Core Opteron Prozessoren ausgestattet werden, die sich hinsichtlich der Taktfrequenz unterscheiden. Die Bandbreite reicht vom Opteron 2210 mit 1.80 GHz bis zum Opteron 2222 mit 3 GHz. Bei diesen Prozessoren sind zwei physikalische Prozessoren in einem Chip vorhanden. Der Second Level Cache (SLC) ist jedem CPU-Kern direkt zugeordnet und hat bei den derzeit verfügbaren Prozessoren eine Größe von 1 MB pro CPU-Kern. Durch die Verwendung von Dual-Core Prozessoren kann ein Dualprozessorsystem heute die Leistungsfähigkeit früherer 4-Wege-Systeme erreichen. Mit dem AMD Opteron Prozessor werden 32-bit- und 64-bit-Betriebssysteme unterstützt. Bei der Betrachtung der Rechenleistung waren alle Systeme mit genügend Arbeitsspeicher ausgebaut, damit die Komponente bei diesem Vergleich keinen Engpass darstellt. Architekturbedingt kann bei der PRIMERGY RX330 S1 nur die Hälfte der Speicherbänke bestückt werden, wenn lediglich eine CPU zum Einsatz kommt. In der PRIMERGY RX330 S1 kommen ein oder zwei Dual-Core Prozessoren mit unterschiedlichen Frequenzen zum Einsatz. Die Leistungsfähigkeit der Prozessoren wurde hinsichtlich ihrer Taktfrequenz und Skalierbarkeit unter Terminal Server untersucht. Die 64-bit-Version von Windows Server 2003 Enterprise Edition R2 diente hierbei als Betriebssystem. Die simulierten Benutzer arbeiteten mit dem Medium Lastprofil unter Verwendung von Microsoft Office Fujitsu Technology Solutions 2009 Seite 26 (37)

27 In der folgenden Grafik sind alle Messergebnisse der verschiedenen Prozessoren für die PRIMERGY RX330 S1 sowohl mit einem als auch mit zwei Prozessoren aufgeführt. Die Palette der Prozessoren für die PRIMERGY RX330 S1 reicht vom AMD Opteron 2210 mit 1.80 GHz bis zum AMD Opteron 2222 mit 3 GHz, in Schritten von 0.2 GHz. Mit höherer Taktfrequenz steigt auch die bedienbare Benutzeranzahl. Eine Frequenzsteigerung von 8% wird beispielsweise in eine um ca. 4% höhere Benutzeranzahl umgesetzt. Dass die Taktsteigerung nicht komplett in eine Steigerung der bedienbaren Benutzer umgesetzt werden kann, erklärt sich aus der gleich bleibenden Geschwindigkeit des HyperTransport Busses und der somit unveränderten Geschwindigkeit bei I/O- Zugriffen. Kommt ein zweiter Dual-Core Prozessor hinzu, kann die Benutzeranzahl im Bereich von 46% bis 69% gesteigert werden, wobei die Steigerung bei höheren Frequenzen generell geringer ausfällt. Da mit dem zweiten Dual-Core Prozessor gleich zwei Prozessorkerne hinzukommen, ist dies ein guter Skalierungsfaktor, weil mit der Anzahl der Prozessoren der Synchronisationsaufwand seitens der Hardware und des Betriebssystems ansteigt. Bei Terminal Server Systemen wurden in der Vergangenheit beim Aufrüsten von zwei auf vier Prozessoren oft kleinere Skalierungsfaktoren beobachtet. Mit dem AMD Opteron 2222 Prozessor wurden auch Messungen mit dem Citrix Presentation Server x64 durchgeführt. Im Vergleich zu den Microsoft Terminal Services erreicht das System mit Citrix eine etwas geringere Leistung mit ca.5% weniger Benutzern bei einer CPU und ca. 8% weniger Benutzern beim Ausbau mit zwei Prozessoren. Die Citrix Terminal Server Lösung bietet mehr Funktionalität und nutzt daher pro Benutzer mehr Systemressourcen. Dieser größere Speicherverbrauch führt 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 erreicht. Der im Vergleich zu Microsoft Terminal Server höhere Verbrauch an Systemressourcen durch den Citrix Presentation Server führt auch dazu, dass unter einem 32-bit Windows Betriebssystem die Kernel-Speicherbereiche eher zum Engpass werden können. Unter dem 64-bit Windows gibt es diese Limitierungen nicht. Ausführlich behandelt wird dieser Aspekt in dem Dokument Terminal Server Sizing Guide - 64-bit Technologie (siehe Literaturverzeichnis). Fujitsu Technology Solutions 2009 Seite 27 (37)

28 Arbeitsspeicher Den stärksten Einfluss auf die Leistungsfähigkeit des 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 RX330 S1 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 ist beim 64-bit Betriebssystem 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 RX330 S1 von 32 GB für Terminal Server unter 32-bit nicht ausnutzen kann. Insbesondere Anwendungen, die Speicherund 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 (Medium Lastprofil, Microsoft Office 2003, Microsoft Terminal Services) Services liegen als Bestandteil des Betriebssystems in einer 64-bit Version vor. Fujitsu Technology Solutions 2009 Seite 28 (37)

29 Da meist der Arbeitsspeicher der limitierende Faktor ist, kann mit der Formel der benötigte Arbeitsspeicher bei einer vorgegeben Anzahl Benutzer, bzw. die Anzahl Benutzer bei einer vorgegeben Speichermenge berechnet werden. Die PRIMERGY RX330 S1 ist ein AMD Opteron Prozessorsystem mit der dafür typischen direkten Zuordnung des Speichers zu den Prozessoren. Jeder Prozessor hat seinen Speicher direkt angebunden, woraus ein schneller Zugriff resultiert. Speicher, der anderen Prozessoren zugeordnet ist, wird über den Memory-Controller der anderen CPU angesprochen, hierbei ist der Zugriff langsamer. Um die Vorteile dieser Architektur optimal nutzen zu können, ist ein Betriebssystem mit nonuniform memory access (NUMA) Unterstützung notwendig, das die einzelnen Gruppen aus Prozessor und Speicher erkennt und, wenn möglich, den Zugriff eines Prozesses auf den schnell angebundenen Speicher durchführt. Bei dem hier verwendeten Betriebssystem Windows Server 2003 R2 in der 32-bit- und 64-bit-Version wird die Systemarchitektur erkannt und NUMA automatisch verwendet. Aus dieser Systemarchitektur folgt umgekehrt, dass eine PRIMERGY RX330 S1, die lediglich mit einem Prozessor bestückt ist, auch nur die Hälfte der Speicherbänke nutzen kann, da der zweite CPU-interne Memory-Controller zur Ansteuerung fehlt. Resümee Die PRIMERGY RX330 S1 ist als Dual-Socket-System mit bis zu vier CPU-Kernen ideal für Terminal Server Anwendungen geeignet. In der Praxis hat sich gezeigt, dass kurzfristig auftretende Lastspitzen bei der Benutzerlast von einem Server mit zwei oder mehr Prozessoren generell besser abgefangen werden können als bei einem Monoprozessorsystem und einen harmonischeren subjektiven Leistungseindruck des Terminal Server Systems vermitteln. Durch die Verwendung mehrerer Systeme (Scale-Out-Szenario) erreicht man eine gute Skalierung. Auch im Einsatzszenario Terminal Server ist durch die Software Citrix Presentation Server Enterprise Edition oder Microsoft Terminal Services mit Load Balancing eine Skalierung gegeben, und die Terminal Server Farm skaliert nahezu linear. Folgende Grafik zeigt die PRIMERGY RX330 S1 im Vergleich zu anderen PRIMERGY Systemen. In dieser Darstellung wird die höchste erreichbare Benutzeranzahl jedes PRIMERGY Systems als Maximalwert verwendet, die mit einer optimalen Hardwarekonfiguration und dem jeweils besten Betriebssystem (32-bit oder 64-bit) erreicht wurde. Es gibt keine scharfe Grenze, wo die Leistung eines Modells endet und die des nächst leistungsfähigeren beginnt. Jedes PRIMERGY System deckt eine gewisse Bandbreite ab, wobei es Überlappungen zwischen den Systemen gibt. Fujitsu Technology Solutions 2009 Seite 29 (37)

30 Benchmark-Umgebung Unten stehende Grafik zeigt die Umgebung, in der die Terminal Server Performance Messungen durchgeführt wurden. Ein Lastgenerator kann eine Vielzahl von Benutzern simulieren, da die Anwendungen auf dem Server ablaufen. Es werden bei den Terminal Server Protokollen nur Tastatureingaben und Mausklicks zum Server und Änderungen des Bildschirminhalts zum Client übertragen. Daher wird keine große Netzwerk-Bandbreite benötigt. Die Anbindung der Lastsimulatoren an den Terminal Server (auch System Under Test (SUT) genannt) erfolgte über ein 100-MBit-Ethernet-Netzwerk, wobei der Terminal Server über den Gigabit-Uplink angeschlossen war. Die Benutzerprofile wurden auf dem Terminal Server gespeichert. Auch die Dateien der Benutzer, die während der Messung gelesen und geschrieben wurden, lagen lokal auf dem Terminal Server. Der sich auch im SUT-Netzwerk befindende Infrastruktur-Server stellt dem zu vermessenden Terminal Server Basisdienste wie Active Directory, DNS und Terminal Services Licensing zur Verfügung. Ein Login der simulierten Benutzer fand immer gegen das Active Directory statt. Controller für die Simulation Lastgeneratoren System under Test (SUT) Infrastruktur- Server Simulationsnetzwerk SUT- Netzwerk switched 100 Mbit switched 100 Mbit PRIMERGY C200 T4US-Control > 20 PRIMERGY Dual Server Windows Server 2003 TS-Client T4US-Agent, T4US-Playback Jeder simuliert bis zu 30 Benutzer PRIMERGY Windows Server 2003 Enterprise Edition PRIMERGY C200 Windows Server 2003 Active Directory Terminal Server Licensing Service System Under Test (SUT): Der Terminal Server wurde mit den Microsoft Terminal Services betrieben, die im Windows Betriebssystem enthalten sind. Als Terminal Server Anwendung wurde Microsoft Office 2003 verwendet. Auf dem Terminal Server wurde keine weitere Software installiert. Hardware Modell PRIMERGY RX330 S1 Prozessor 1 2 AMD Dual-Core Opteron 2210, 2212, 2214, 2216, 2218, 2220 und 2222 Speicher bis 16 GB Netzwerk-Interface 1 Broadcom NetXtreme Gigabit Ethernet (onboard) Disk Subsystem LSI 1068 SAS controller (onboard), IME 4 ST336754SS (36 GB), 15 krpm Software Betriebssystem Windows Server 2003 Enterprise x64 Edition R2 Version Service Pack 1 (Build 1830) Netzwerkprotokoll TCP/IP Disk Organisation 1 Volume für das Betriebssystem 1 Volume für die Daten Terminal Server Software Anwendung Microsoft Terminal Services Citrix Presentation Server 4.0 x64 Microsoft Office 2003 (32-bit) T4US Messumgebung: Die Lastgeneratoren simulieren eine Vielzahl von Benutzern, die mit dem Terminal Server arbeiten. Ein T4US-Controller steuert und überwacht den gesamten Simulationslauf. Der Infrastruktur-Server stellt Basisdienste zur Verfügung. Lastgenerator-Hardware Modell PRIMERGY L200/P200 # Lastgeneratoren 23 Prozessor 2 Pentium III 1.27 GHz Memory 1 GB Netzwerk-Interface MBit LAN T4US Controller- und Infrastrukturserver-Hardware Model PRIMERGY C200 Prozessor 2 Pentium III 1.40 MHz Memory 1.5 GB Netzwerk-Interface MBit LAN Software Betriebssystem Windows Server 2003 Standard Edition SP1 Netzwerkprotokoll TCP/IP RDP Client ICA Client , 32-bit T4US Version 3.3 T4US Lastprofil Medium Lastprofil Fujitsu Technology Solutions 2009 Seite 30 (37)

31 vservcon Benchmark-Beschreibung vservcon ist ein bei Fujitsu Technology Solutions verwendeter Benchmark zum Vergleich von Serverkonfigurationen mit Hypervisor in Bezug auf ihre Eignung für Server-Konsolidierung. Hiermit ist sowohl der Vergleich von Systemen, Prozessoren und I/O-Technologien möglich, wie auch der Vergleich von Hypervisor-en, Virtualisierungsformen und zusätzlichen Treibern für virtuelle Maschinen. Bei vservcon handelt es sich um ein Framework, das bereits etablierte Benchmarks zusammenfasst, um die Last einer konsolidierten und virtualisierten Serverumgebung nachzubilden. Es kommen drei bewährte Benchmarks zum Einsatz, die die Anwendungsszenarien Datenbank, Applikationsserver und Webserver abdecken: Anwendungsszenario Benchmark Anzahl logische CPU-Cores Memory Database Sysbench (angepasst) GB Java-Applikationsserver SPECjbb (angepasst, mit 50% - 60% Last) 2 2 GB Webserver WebBench GB Jeder der drei Standard-Benchmarks wird jeweils einer dedizierten virtuellen Maschine (VM) zugeordnet. Hinzu kommt eine vierte, so genannte Idle-VM. Diese vier VMs bilden eine»tile«(engl. Kachel). Je nach Leistungsfähigkeit der zugrunde liegenden Server-Hardware kann es notwendig sein, dass im Rahmen einer Messung auch mehrere identische Tiles parallel gestartet werden müssen, um eine maximale Performance-Bewertungszahl (Score) zu erreichen. Jedes der drei vservcon-anwendungsszenarien ergibt für jede VM ein spezifisches Benchmark-Ergebnis in Form von applikationsspezifischen Transaktionsraten. Um hieraus einen Score für eine gegebene Tile-Anzahl zu bilden, werden die einzelnen Benchmark-Ergebnisse in Relation zu den jeweiligen Ergebnissen eines definierten Referenzsystems gesetzt, einer PRIMERGY RX300 S3. Die daraus resultierenden dimensionslosen Performance-Werte werden dann unter Berücksichtigung der Anzahl der virtuellen CPUs und der Memory-Größe gewichtet und über alle VMs und Tiles aufsummiert. Das Ergebnis ist der vservcon-score für die betrachtete Tile-Anzahl. VM Web Loadgen. Load Loadgen. Web Web Web System Under Test VM Database Tile Tile Tile VM Java Framework Controller Diese Prozedur wird in der Regel beginnend mit eins - für steigende Tile-Anzahlen durchgeführt, bis keine signifikante Steigerung dieses vservcon-scores mehr eintritt. Der finale vservcon-score ist dann das Maximum über die vservcon- Scores aller Tile-Anzahlen. Er spiegelt für eine Serverkonfiguration mit Hypervisor den maximalen summarischen Konsolidierungs-Nutzen über alle VMs wider. Ferner werden bei vservcon die Gesamt-CPU-Auslastung des Hosts (VMs und alle übrigen CPU-Aktivitäten), Memory- Verbrauch und Leistungsaufnahme dokumentiert. Der Score soll eine virtualisierungsspezifische Leistung eines Systems ausdrücken, die man bis zur möglichst vollständigen Ausnutzung der CPU-Ressourcen mittels vieler VMs erzielen kann. Der Score wäre also nicht aussagekräftig, wenn während einer vservcon-messung schon bei einer unnötig kleinen Tile-Anzahl eine Limitierung eintreten würde, z. B. durch eine nicht ausreichend dimensionierte Disk-Anbindung. Deswegen wird die Messumgebung für vservcon-messungen so ausgelegt, dass nur die CPU der begrenzende Faktor ist, und keine Limitierungen durch andere Ressourcen eintreten. Zu diesem Zweck und zu Zwecken der Vergleichbarkeit wird für alle benutzten VMs in vservcon ein genau festgelegtes Profil für die virtuellen Hardware-Ressourcen, das Betriebssystem und die Anwendungen verwendet. Eine ausführliche Beschreibung von vservcon ist zu finden im Übersichtsdokument: vservcon - Benchmark Überblick. VM Idle Fujitsu Technology Solutions 2009 Seite 31 (37)

32 Benchmark-Ergebnisse Die PRIMERGY RX330 S1 ist gut für die Virtualisierung von Anwendungen geeignet. Insbesondere die aktuelle Prozessorgeneration Opteron 237x und 238x sorgt durch den großen Cache für einen Leistungsschub. Verglichen mit dem Referenzsystem von Ende 2006 ist fast eine dreifache Virtualisierungs-Performance (gemessen in vservcon-score) erreichbar. So ist z. B. auf Basis des zuvor beschriebenen vservcon-profils bei Vollausbau mit zwei Opteron 2380 Prozessoren durch neun echte Anwendungs-VMs (entsprechend drei Tiles) eine nahezu optimale Auslastung der CPU- Ressourcen des Systems möglich. Das erste Diagramm veranschaulicht dies für die PRIMERGY RX330 S1 durch die vservcon-scores in Abhängigkeit vom Prozessor und der Anzahl der Tiles. Zusätzlich sind die jeweiligen CPU-Auslastungen des Hosts eingetragen. Im Bereich um 90% liegen typischerweise die Tile-Anzahlen mit optimaler CPU-Ausnutzung; jenseits davon liegt der Überlastbereich, in dem die Virtualisierungs-Performance nicht mehr zunimmt bzw. wieder abnimmt. Ein wesentlicher Aspekt der Server-Konsolidierung ist die Einsparung elektrischer Energie. So kann man z. B. beim Opteron 2380 Prozessor allein durch die Verdoppelung der Anzahl der echten Anwendungs-VMs von drei (ein Tile) auf sechs (zwei Tiles) die Virtualisierungs-Performance um 58% steigern, während gleichzeitig die elektrische Leistungsaufnahme nur um ca. 13% ansteigt. Die Power-Aspekte für die oben dargestellten Prozessoren veranschaulicht das folgende Diagramm. Darin sind zum einen die absoluten Unterschiede in der Leistungsaufnahme dargestellt, zum anderen das Verhältnis vservcon-score zur Leistungsaufnahme in kw, im Diagramm kurz als»vservcon power score«bezeichnet. Fujitsu Technology Solutions 2009 Seite 32 (37)

33 Im Vorangegangenen wurde die Virtualisierungs-Performance des Systems in Gänze betrachtet. Für eine optimale Virtualisierungsperformance wird abweichend vom Standardwert die BIOS-Einstellung Node Interleave = OFF zugrunde gelegt, da sich hierbei die höchsten Gesamtscores ergeben. Im Folgenden soll noch die Performance aus Sicht einer einzelnen Anwendungs-VM in der beschriebenen virtualisierten Umgebung diskutiert werden. Dazu wird im Folgenden exemplarisch das System mit dem Prozessor Opteron 2384 betrachtet. Wenn die Anzahl der Anwendungs-VMs im optimalen Bereich aus Sicht der Gesamtperformance liegt, ist die Performance einer einzelnen VM schon merklich geringer als im Betrieb in Niedriglastsituationen. Das nebenstehende Diagramm verdeutlicht dies durch die relative Performance im Verhältnis zum Referenzsystem bei einer einzelnen Anwendungs-VM von jedem der drei Typen für wachsende VM- Anzahlen. Die jeweils erste Säule einer Gruppe betrachtet eine VM im Verbund von insgesamt drei Anwendungs-VMs (eine Tile), die jeweils zweite im Verbund von sechs Anwendungs-VMs (zwei Tiles) usw. Die Werte sind sowohl einzeln dargestellt als auch summiert über alle VMs des jeweiligen Typs - durch die Höhe der gestapelten Säule. Die Performance-Abnahme in der Nähe des Gesamt-Optimums zeigt systemübergreifend ein generelles Verhalten: Es fällt am mildesten für die CPU-intensive JAVA- VM aus, ein bisschen deutlicher für die Netzwerk-I/O-intensive Web-VM und am stärksten für die DB-VM. Etwa ab dem Gesamtoptimum für die Tile-Anzahl bricht die Performance der DB-VMs erkennbar ein. Bezüglich der VM-Anzahlen auf einem Virtualisierungs-Host muss man im konkreten Fall die Performance-Anforderungen einer einzelnen Anwendung gegen die Gesamtanforderungen abwägen. Bei der PRIMERGY RX330 S1 zeigen sich für die I/O-intensiven Webserver-VMs bei Tile-Anzahlen nahe der CPU-Sättigung deutliche Ungleichmäßigkeiten. Wenn der für die Web-VMs minimale garantierte Web-Durchsatz im Sättigungsbereich wichtiger ist als die Gesamtperformance der virtualisierten Applikationen, ist die BIOS-Einstellung Node Interleave = AUTO sinnvoll, sonst jedoch nicht. Fujitsu Technology Solutions 2009 Seite 33 (37)

34 Wenn man Anwendungen in virtuellen Maschinen mit größtmöglicher Performance betreiben will, lohnt sich ein genauer Blick auf solche Anwendungsprofile, die erhöhte Anforderungen an eine Virtualisierungslösung stellen. Hierzu gehören Anwendungsszenarien wie Webserver, die das Memory-Management stark beanspruchen. Diese sollen im Folgenden für den Prozessor Opteron 2376 betrachtet werden. Der erste Optimierungsweg setzt beim Anwendungsszenario an. Am Beispiel eines Webservers mit dynamischen Seiten lässt sich eindrucksvoll der Einfluss der Realisierung der dynamischen Inhalte auf die Performance aufzeigen. Dynamische Inhalte sind häufig als CGI-Programme (bzw. Skripte) realisiert. Diese CGI- Programme erzeugen bei jedem Aufruf einen neuen Prozess, was für den Hypervisor recht aufwändig ist. Alternativ können dynamische Inhalte durch den Einsatz von PHP, ASP oder ähnlicher Methoden realisiert werden, die keinen Overhead durch neu erzeugte Prozesse bewirken. Dies lässt sich in vservcon simulieren, indem im Lastprofil der Webserver-VM der Anteil der HTTP-Requests, die solche CGI-Programme starten, variiert wird. Die Auswirkungen auf die Performance verdeutlicht das Diagramm für einen unmodifizierten Linux-Kernel in der VM. Die beiden verglichenen Lastprofile sind: Lastprofile für Webserver STD-CGI MIN-CGI Definiert, dass 16% aller HTTP-Requests und 2% aller HTTP-SSL-Requests auf dem Webserver ein CGI-Programm starten. Beansprucht eine Virtualisierungslösung stark. STD-CGI-Profil ohne die 16% CGI-HTTP-Requests. Durch diese Verringerung der Zahl der CGI-Prozesse wird ein Webserver entlastet; sehr viel mehr noch aber reduziert dies den Aufwand innerhalb der Virtualisierungslösung. Durch beide Effekte zusammen wird soviel zusätzliche CPU-Leistung verfügbar, dass sich die Web-Transaktionsrate für VMs deutlich erhöht. Alle zuvor beschriebenen Messungen benutzen das STD-CGI-Profil als Standard. Der zweite Optimierungsweg setzt unterhalb der Anwendungsebene in der VM an. Prinzipiell möglich sind Performance- Steigerungen sowohl durch entsprechende Prozessorfunktionalitäten, als auch durch einen geeigneten Hypervisor oder auch durch ein speziell auf den Hypervisor angepasstes Betriebssystem oder Treiber in der VM. Ob solche Anpassungen existieren, hängt vom Virtualisierungsumfeld ab. Eine so angepasste VM unterstützt den Hypervisor aktiv in seiner Arbeit, wodurch sich der Virtualisierungs-Overhead teilweise signifikant reduzieren lässt. Das Potential dieses Optimierungsweges soll demonstriert werden durch einen Vergleich der summierten Performance der drei Webserver-VMs in drei Tiles bei zwei verschiedenen VM-Kerneln. Der eine Kernel ist der unmodifizierte LINUX- Kernel, und der andere ist ein für Virtualisierung angepasster Kernel. Letzterer ist der Standard für die zuvor beschriebenen Messungen, wenn nichts anderes gesagt wird. Das nebenstehende Ergebnisdiagramm vergleicht die so erzielten Performance-Werte für beide Kernel und die beiden o.g. Lastprofile. Interessant ist hierbei das STD-CGI-Lastprofil, das die Qualität der Virtualisierungskonfiguration besonders beansprucht. Hierbei ist der prozentuale Abstand zwischen der Web-Transaktionsrate für den unmodifizierten Kernel und den angepassten Kernel ein reziprokes Maß für die Qualität der Virtualisierungsunterstützung durch die CPU. Je besser die CPU hier unterstützt, umso weniger können der Hypervisor oder modifizierte VM-Kernel noch erreichen. Bei den für die PRIMERGY RX330 S1 freigegebenen Prozessoren liegen die prozentualen Performance-Abstände zwischen den Kerneln im vergleichsweise günstigen Bereich von 24% - 32%. Für das Referenzsystem ist dieser Prozentsatz 71%. Das MIN-CGI-Lastprofil simuliert den Fall, dass bereits auf Anwendungsebene optimiert worden ist (bessere Web-Schnittstelle). Es zeigt, dass sich hierbei die Notwendigkeit eines angepassten Kernels signifikant verringert. Stehen im Anwendungsszenario beide Optimierungswege zur Verfügung, so profitiert man von beiden Effekten und erzielt die bestmögliche Performance. Fujitsu Technology Solutions 2009 Seite 34 (37)

35 Benchmark-Umgebung Die Messungen wurden mit der im Folgenden beschriebenen Umgebung durchgeführt: vservcon Benchmark Environment System under Test (SUT) Tile 1 Tile n VM Web VM Database VM Java VM Idle VM Web VM Database VM Java VM Idle 1 GBit LAN 1 GBit LAN vservcon Framework Controller Load generator BX600 Disk-Subsystem FibreCAT CX500 SUT-Hardware Modell PRIMERGY RX330 S1 Prozessor 2 Opteron 2352 (2.10 GHz) 2 Opteron 2356 (2.30 GHz) 2 Opteron 2376 (2.30 GHz) 2 Opteron 2380 (2.50 GHz) 2 Opteron 2384 (2.70 GHz) Speicher Bei Opteron 235x: 16 GB (2Rx4 PC2-5300P J2) Sonst 32 GB (2Rx4 PC2-6400P ) Netzwerk-Interface 2 1-GBit LAN; eins für Load, eins für Control Disk Subsystem Es wurden keine internen Festplatten verwendet, sondern ausschließlich ein Storage-System FibreCAT CX500. Pro Tile eine 50 GB LUN für die»virtual disk files«der VMs. Jede LUN ist ein RAID 0 Verband aus je 6 Seagate ST Disks (15 kprm) Storage-Anbindung Über FC-Controller Qlogic QLE 2460 SUT-Software Betriebssystem Hypervisor VMware ESX Server Version Version build , Update 3 BIOS Version 5.00 Rev ; Node Interleave = Off; Cool n Quiet = Disabled; SAS Option ROM Scan =Disabled SUT: Virtualisierungsspezifisches Webserver-VM-Kernel SLES10 SP2, 32-bit, smp original Webserver-VM-Kernel angepasst Generelles SLES10 SP2, 32-bit, vmi (Kernel mit VMware-VMI-Interface) Beschrieben im Benchmark Überblick vservcon Lastgenerator-Hardware Modell Pro Tile 4 Serverblades in PRIMERGY BX600 S2 Chassis Prozessor X86 Family 15, Model 4, Stepping 1, Genuine Intel 3000 MHz Memory 1 2 GB Netzwerk-Interface Je 2 1 GBit LAN Betriebssystem W2K3 EE Fujitsu Technology Solutions 2009 Seite 35 (37)