Performance Report PRIMERGY RX600 S4
Werbung
Version 2.2b November 2009 Performance Report PRIMERGY RX600 S4 Seiten 49 Abstract In diesem Dokument sind alle Benchmarks, die für die PRIMERGY RX600 S4 durchgeführt wurden, zusammengefasst. Ferner werden die Leistungsdaten der PRIMERGY RX600 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 SPECcpu2006.........................................................................................................................................................3 SPECjbb2005........................................................................................................................................................10 SPECweb2005 ......................................................................................................................................................16 StorageBench .......................................................................................................................................................21 OLTP-2..................................................................................................................................................................26 TPC-E ...................................................................................................................................................................29 SAP SD .................................................................................................................................................................33 Terminal Server .....................................................................................................................................................37 vServCon ..............................................................................................................................................................43 Literatur .................................................................................................................................................................48 Kontakt ..................................................................................................................................................................49 White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Technische Daten Die PRIMERGY RX600 S4 ist ein mit nur 4 Höheneinheiten besonders Platz sparender 4-Socket Rack Server mit Intel 7300 Chipsatz, Intel Xeon Prozessoren, 4-way interleaved registered enhanced ECC PC2-5300F DDR2-SDRAM, einem mit 1067 MHz getakteten Front-Side-Bus, einem 8-Port SAS RAID-Controller mit 512 MB Cache, zwei dual GBit Ethernet-Controllern und acht PCI-Steckplätzen (4 PCI-Express x8, 4 PCI-Express x4). Sie besitzt 8 Laufwerkseinschübe für SAS-Festplatten. Detaillierte technische Informationen finden Sie im Datenblatt PRIMERGY RX600 S4. © Fujitsu Technology Solutions 2009 Seite 2 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 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 SPECint2006 SPECint_base2006 SPECint_rate2006 SPECint_rate_base2006 SPECfp2006 SPECfp_base2006 SPECfp_rate2006 SPECfp_rate_base2006 Arithmetik Typ Integer Integer Integer Integer Fließkomma Fließkomma Fließkomma Fließkomma peak base peak base peak base peak base CompilerOptimierung aggressiv konservativ aggressiv konservativ aggressiv konservativ aggressiv konservativ Messergebnis Anwendung Geschwindigkeit Singlethreaded Durchsatz Multithreaded Geschwindigkeit Singlethreaded Durchsatz 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_base2006Ergebnisse 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 RX600 S4 wurde mit zwei verschiedenen Prozessorvarianten der Xeon-Reihe vermessen: Xeon E7220, E7310, E7330 und X7350 (Tigerton) Xeon E7430, L7445, E7450 und X7460 (Dunnington) Die Ergebnisse der Tigerton-Prozessoren basieren auf Messungen, bei denen die SPECcpu-Benchmark-Programme mit dem Intel C++/Fortran-Compiler 10.1 kompiliert und unter SUSE Linux Enterprise Server 10 SP1 (64-bit) ausgeführt wurden. Für die Dunnington-Prozessoren wurden die SPECcpu-Benchmark-Programme mit dem Intel C++/FortranCompiler 11.0 kompiliert und unter SUSE Linux Enterprise Server 10 SP2 (64-bit) ausgeführt. SPEC®, SPECint®, SPECfp® und das SPEC-Logo sind eingetragene Warenzeichen der Standard Performance Evaluation Corporation (SPEC). © Fujitsu Technology Solutions 2009 Seite 3 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Die in den beiden folgenden Tabellen fett gedruckten Ergebnisse sind veröffentlicht bei http://www.spec.org. Prozessor Xeon E7220 Xeon E7310 Xeon E7330 Xeon X7350 Xeon E7430 Xeon L7445 Xeon E7450 Xeon X7460 Cores 2 4 4 4 4 4 6 6 GHz 2.93 1.60 2.40 2.93 2.13 2.13 2.40 2.67 L2-Cache 4 MB pro Core 4 MB pro Chip 6 MB pro Chip 8 MB pro Chip 6 MB pro Chip 6 MB pro Chip 9 MB pro Chip 9 MB pro Chip L3-Cache TDP n/a n/a n/a n/a 12 MB pro Chip 12 MB pro Chip 12 MB pro Chip 16 MB pro Chip 80 Watt 80 Watt 80 Watt 130 Watt 90 Watt 50 Watt 90 Watt 130 Watt SPECint_rate_base2006 2 Chips 4 Chips 62.0 119 63.6 115 85.1 151 99.0 175 n/a 180 n/a 179 n/a 235 144 269 SPECint_rate2006 2 Chips 4 Chips 74.8 142 70.3 126 94.9 177 112 210 n/a 194 n/a 194 n/a 252 159 291 Die SPECint_rate_2006-Ergebnisse der Tigerton-Prozessoren liegen 10-21%, die der Dunnington-Prozessoren 7-10% über den SPECint_rate_base2006-Ergebnissen. Prozessor Xeon E7220 Xeon E7310 Xeon E7330 Xeon X7350 Xeon E7430 Xeon L7445 Xeon E7450 Xeon X7460 Cores 2 4 4 4 4 4 6 6 GHz 2.93 1.60 2.40 2.93 2.13 2.13 2.40 2.67 L2-Cache 4 MB pro Core 4 MB pro Chip 6 MB pro Chip 8 MB pro Chip 6 MB pro Chip 6 MB pro Chip 9 MB pro Chip 9 MB pro Chip © Fujitsu Technology Solutions 2009 L3-Cache TDP n/a n/a n/a n/a 12 MB pro Chip 12 MB pro Chip 12 MB pro Chip 16 MB pro Chip 80 Watt 80 Watt 80 Watt 130 Watt 90 Watt 50 Watt 90 Watt 130 Watt SPECfp_rate_base2006 2 Chips 4 Chips 44.4 82.3 45.4 82.3 55.2 97.6 60.6 107 n/a 110 n/a 110 n/a 130 73.7 142 SPECfp_rate2006 2 Chips 4 Chips 47.8 88.4 48.0 87.3 58.4 104 64.3 117 n/a 116 n/a 116 n/a 139 81.2 156 Seite 4 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Die SPECfp_rate_2006-Ergebnisse der Tigerton-Prozessoren liegen 6-9%, die der Dunnington-Prozessoren 5-10% über den SPECfp_rate_base2006-Ergebnissen. Mit dem Xeon X7460 Prozessor wurden Vergleichsmessungen vorgenommen, die den Einfluss von Compiler-Versionen auf den Durchsatz des Servers verdeutlichen. Für die Komplierung der Benchmark-Programme wurden die Versionen 10.1 und 11.0 des Intel C++/Fortran-Compilers verwendet. Die Messungen erfolgten in identischer Hard- und SoftwareUmgebung. Die Messungen zeigten, dass die Wahl des Compilers für die Benchmark-Ergebnisse von erheblicher Bedeutung sind. © Fujitsu Technology Solutions 2009 Seite 5 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Im August 2008 wurde die PRIMERGY RX600 S4 mit vier Xeon X7460 Prozessoren vermessen. Die SPECcpuBenchmark-Programme wurden mit dem Intel C++/FortranCompiler 10.1 kompiliert und unter SUSE Linux Enterprise Server 10 SP2 (64-bit) ausgeführt. Die PRIMERGY RX600 S4 erzielte sowohl das beste SPECint_rate_base2006-Ergebnis1 2 als auch das beste SPECint_rate2006-Ergebnis aller Server mit Intel Xeon Prozessoren. Quelle: http://www.spec.org/cpu2006/results, Stand: 2.9.2008 1 2 Die oben genannten Vergleichswerte zu Wettbewerbsprodukten geben den Stand vom 2. September 2008 wieder. Der vorgestellte Vergleich basiert auf den SPECint_rate_base2006-Ergebnissen für Server mit Intel Xeon Prozessoren. Es werden die zu diesem Zeitpunkt besten verfügbaren Systeme von Lenovo, IBM und Fujitsu Siemens Computers, heute firmierend unter Fujitsu, verglichen. Die aktuellen SPECint_rate_base2006-Ergebnisse sind zu finden unter http://www.spec.org/cpu2006/results. Die oben genannten Vergleichswerte zu Wettbewerbsprodukten geben den Stand vom 2. September 2008 wieder. Der vorgestellte Vergleich basiert auf den SPECint_rate2006-Ergebnissen für Server mit Intel Xeon Prozessoren. Es werden die zu diesem Zeitpunkt besten verfügbaren Systeme von Acer, Dell, Lenovo und Fujitsu Siemens Computers, heute firmierend unter Fujitsu, verglichen. Die aktuellen SPECint_rate2006-Ergebnisse sind zu finden unter http://www.spec.org/cpu2006/results. © Fujitsu Technology Solutions 2009 Seite 6 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Im August 2008 wurde die PRIMERGY RX600 S4 mit vier Xeon X7460 Prozessoren vermessen. Die SPECcpuBenchmark-Programme wurden mit dem Intel C++/Fortran-Compiler 11.0 kompiliert und unter SUSE Linux Enterprise Server 10 SP2 (64-bit) ausgeführt. Die PRIMERGY RX600 S4 erzielte sowohl das beste SPECfp_rate_base2006-Ergebnis als auch das beste SPECfp_rate2006Ergebnis aller Server mit Intel Xeon Prozessoren. 3 Quelle: http://www.spec.org/cpu2006/results, Stand: 18.9.2008 Im September 2008 wurde die PRIMERGY RX600 S4 mit vier Xeon X7460 Prozessoren vermessen. Die SPECcpu-Benchmark-Programme wurden mit dem Intel C++/FortranCompiler 11.0 kompiliert und unter SUSE Linux Enterprise Server 10 SP2 (64-bit) ausgeführt. Die PRIMERGY RX600 S4 erzielte sowohl das beste SPECint_rate_base2006-Ergebnis als auch gemeinsam mit Servern anderer Hersteller das beste SPECint_rate2006Ergebnis aller Server mit Intel Xeon Prozessoren. 4 Quelle: http://www.spec.org/cpu2006/results, Stand: 16.9.2008 3 4 Die oben genannten Vergleichswerte zu Wettbewerbsprodukten geben den Stand vom 18. September 2008 wieder. Der vorgestellte Vergleich basiert auf den SPECfp_rate_base2006-Ergebnissen und SPECfp_rate2006-Ergebnissen für Server mit Intel Xeon Prozessoren. Es werden die zu diesem Zeitpunkt besten verfügbaren Systeme von Dell, HP und Fujitsu Siemens Computers, heute firmierend unter Fujitsu, verglichen. Die aktuellen SPECfp_rate_base2006Ergebnisse und SPECfp_rate2006-Ergebnisse sind zu finden unter http://www.spec.org/cpu2006/results. Die oben genannten Vergleichswerte zu Wettbewerbsprodukten geben den Stand vom 16. September 2008 wieder. Der vorgestellte Vergleich basiert auf den SPECint_rate_base2006-Ergebnissen und SPECint_rate2006-Ergebnissen für Server mit Intel Xeon Prozessoren. Es werden die zu diesem Zeitpunkt besten verfügbaren Systeme von HP, Dell und Fujitsu Siemens Computers, heute firmierend unter Fujitsu, verglichen. Die aktuellen SPECint_rate_base2006Ergebnisse und SPECint_rate2006-Ergebnisse sind zu finden unter http://www.spec.org/cpu2006/results. © Fujitsu Technology Solutions 2009 Seite 7 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Die beiden nebenstehenden Grafiken verdeutlichen die Leistungsunterschiede zwischen den derzeit besten Mono-, Dual- und Quad-Prozessor Rack Servern der PRIMERGY Serie. Die PRIMERGY RX600 S4 übertrifft das Ergebnis des derzeit leistungsstärksten Monoprozessorsystems PRIMERGY RX100 S5 um mehr als 275% in der Integer-Testsuite und knapp 200% in der Fließkomma-Testsuite. Im Vergleich zum derzeit leistungsstärksten Dualprozessorsystems PRIMERGY RX200 S4 erzielt die PRIMERGY RX600 S4 ein Plus von rund 90%. Die beiden folgenden Grafiken stellen die PRIMERGY RX600 S4 in Relation zu ihrem Vorgänger, der PRIMERGY RX600 S3, in jeweils performantester Ausstattung. In der Integer-Testsuite wurde eine Steigerung von +256% bei SPECint_rate_base2006 und +261% bei SPECint_rate2006 erzielt. In der Fließkomma-Testsuite beträgt der Zuwachs +143% bei SPECfp_rate_base2006 und +159% bei SPECfp_rate2006. © Fujitsu Technology Solutions 2009 Seite 8 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Benchmark-Umgebung* Alle SPECcpu2006-Messungen wurden auf einer PRIMERGY RX600 S4 mit folgender Hard- und Software-Ausstattung vorgenommen: Hardware Modell CPU Anzahl CPUs Primary Cache Secondary Cache Other Cache Memory Software Betriebssystem Compiler * PRIMERGY RX600 S4 Xeon E7220, E7310, E7330 und X7350 Xeon E7430, L7445, E7450 und X7460 2, 4 32 kB instruction + 32 kB data on chip, pro Core Xeon E7220: 4 MB (I+D) on chip, pro Core Xeon E7310: 4 MB (I+D) on chip, pro Chip Xeon E7330, E7430 und L7445: 6 MB (I+D) on chip, pro Chip Xeon X7350: 8 MB (I+D) on chip, pro Chip Xeon E7450 und X7460: 9 MB (I+D) on chip, pro Chip Xeon E7430, L7445 und E7450: 12 MB (I+D) on chip, pro Chip Xeon X7460: 16 MB (I+D) on chip, pro Chip andere: nein 16 x 4 GB PC2-5300F DDR2-SDRAM Xeon E7220, E7310, E7330 und X7350: SUSE Linux Enterprise Server 10 SP1 (64-bit) Xeon E7430, L7445, E7450 und X7460: SUSE Linux Enterprise Server 10 SP2 (64-bit) Xeon E7220, E7310, E7330, X7350 and X7460: Intel C++/Fortran Compiler 10.1 Xeon E7430, L7445, E7450 and X7460: Intel C++/Fortran Compiler 11.0 Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. © Fujitsu Technology Solutions 2009 Seite 9 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 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 NetzwerkI/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 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Benchmark-Ergebnisse Im August 2007 wurde die PRIMERGY RX600 S4 mit vier Xeon X7350 Prozessoren und einem Speicherausbau von 64 GB PC2-5300F DDR2-SDRAM vermessen. Die Messung wurde unter Windows Server 2003 R2 Enterprise x64 Edition durchgeführt. Als JVM wurden acht Instanzen von JRockit(R) 6.0 P27.4.0 (build P27.4.0-3-86647-1.6.0_02-200708011931-windows-x86_64) von BEA verwendet. Die PRIMERGY RX600 S4 erzielte das beste Ergebnis aller Server mit 4 Prozessoren und ließ damit auch Anbieter von Servern mit anderen Prozessortypen hinter sich. Bei der Messung der PRIMERGY RX600 S4 flossen alle Ergebnisse von 2 bis 4 Warenhäusern, bei der Messung des IBM System p 570 alle Ergebnisse von 4 bis 8 Warenhäusern in das Benchmark-Ergebnis ein. Quelle: http://www.spec.org/jbb2005/results, Stand: 30.9.2007 Im August 2008 wurde die PRIMERGY RX600 S4 mit vier Xeon X7460 Prozessoren und einem Speicherausbau von 64 GB PC2-5300F DDR2-SDRAM vermessen. Die Messung wurde unter Windows Server 2003 R2 Enterprise x64 Edition durchgeführt. Als JVM wurden vier Instanzen von JRockit(R) 6.0 P27.5.0 (build P27.5.0-5_o_CR371811_CR374296100684-1.6.0_03-20080702-1651-windows-x86_64) von Oracle verwendet. Im September 2008 erfolgten weitere Messungen mit zwei und vier Xeon E7310 und Xeon E7330 Prozessoren. Hier wurden bei den Messungen mit zwei Prozessoren vier JVM-Instanzen, bei den Messungen mit vier Prozessoren acht JVM-Instanzen verwendet. Die oben genannten Vergleichswerte zu Wettbewerbsprodukten geben den Stand vom 30. September 2007 wieder. Der vorgestellte Vergleich basiert auf den SPECjbb2005-Ergebnissen für Server mit 4 Prozessoren. Es werden die zu diesem Zeitpunkt besten verfügbaren Systeme von IBM und Fujitsu Siemens Computers, heute firmierend unter Fujitsu, verglichen. Die aktuellen SPECjbb2005-Ergebnisse sind zu finden unter http://www.spec.org/jbb2005/results. © Fujitsu Technology Solutions 2009 Seite 11 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Im Februar 2009 wurde die PRIMERGY RX600 S4 erneut mit vier Xeon X7460 Prozessoren und einem Speicherausbau von 64 GB PC2-5300F DDR2-SDRAM vermessen. Die Messung wurde unter Windows Server 2003 R2 Enterprise x64 Edition durchgeführt. Als JVM wurden vier Instanzen von JRockit(R) 6 P28.0.0 (build P28.0.0-8-109238-1.6.0_0520090130-1408-windows-x86_64) von Oracle verwendet. Die PRIMERGY RX600 S4 erzielte das beste Ergebnis aller Server mit 4 Intel Prozessoren. Bei den Messungen flossen alle Ergebnisse von 6 bis 12 Warenhäusern in das Benchmark-Ergebnis ein. Quelle: http://www.spec.org/jbb2005/results, Stand: 26.3.2009 Die oben genannten Vergleichswerte zu Wettbewerbsprodukten geben den Stand vom 26. März 2009 wieder. Der vorgestellte Vergleich basiert auf den SPECjbb2005-Ergebnissen für Server mit 4 Intel Prozessoren. Es werden die zu diesem Zeitpunkt besten verfügbaren Systeme von Dell und Fujitsu verglichen. Die aktuellen SPECjbb2005Ergebnisse sind zu finden unter http://www.spec.org/jbb2005/results. © Fujitsu Technology Solutions 2009 Seite 12 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Vergleicht man die PRIMERGY RX600 S4 mit ihrem Vorgänger, der PRIMERGY RX600 S3, in jeweils performantester Ausstattung, so ergibt sich ein Plus von 192%. © Fujitsu Technology Solutions 2009 Seite 13 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Die beiden folgenden Grafiken verdeutlichen die Leistungsunterschiede zwischen den derzeit besten Mono-, Dual- und Quad-Prozessor Rack Servern der PRIMERGY Serie. Die PRIMERGY RX600 S4 übertrifft das Ergebnis des derzeit leistungsstärksten Monoprozessorsystems PRIMERGY RX150 S5 um 200% und das Ergebnis des derzeit leistungsstärksten Dualprozessorsystems PRIMERGY RX200 S4 um 72%. Bei der PRIMERGY RX600 S4 flossen die Messwerte von 6 bis 12 Warenhäusern, bei den anderen Servern die Messwerte von 2 bis 4 Warenhäusern in das Benchmark-Ergebnis ein. © Fujitsu Technology Solutions 2009 Seite 14 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Benchmark-Umgebung* Die SPECjbb2005-Messung wurde auf einer PRIMERGY RX600 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 RX600 S4 Xeon E7310, E7330, X7350 und X7460 Xeon E7310 und E7330: 2 Chips, 8 Cores, 4 Cores pro Chip Xeon E7310, E7330 und X7350: 4 Chips, 16 Cores, 4 Cores pro Chip Xeon X7460: 4 Chips, 24 Cores, 6 Cores pro Chip 32 KB instruction + 32 KB data on chip, pro Kern Xeon E7310: 4 MB (I+D) on chip, pro Chip Xeon E7330: 6 MB (I+D) on chip, pro Chip Xeon X7350: 8 MB (I+D) on chip, pro Chip Xeon X7460: 9 MB (I+D) on chip, pro Chip Xeon X7460: 16 MB (I+D) on chip, pro Chip alle anderen: nein 16 x 4 GB PC2-5300F DDR2-SDRAM Windows Server 2003 R2 Enterprise x64 Edition Xeon X7350: BEA JRockit(R) 6.0 P27.4.0 (build P27.4.0-3-86647-1.6.0_02-20070801-1931-windows-x86_64) alle anderen: Oracle JRockit(R) 6.0 P27.5.0 (build P27.5.0-5_o_CR371811_CR374296-100684-1.6.0_03-20080702-1651windows-x86_64) Xeon X7460 zusätzlich: Oracle JRockit(R) 6 P28.0.0 (build P28.0.0-8-109238-1.6.0_05-20090130-1408-windows-x86_64) Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. © Fujitsu Technology Solutions 2009 Seite 15 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 SPECweb2005 Benchmark-Beschreibung SPECweb2005 wurde von der Open Systems Group (OSG) der Standard Performance Evaluation Corporation (SPEC) als Nachfolger für SPECweb99 und SPECweb99_SSL entwickelt. SPECweb2005 ist der Benchmark der nächsten Generation zur Leistungsbewertung von Web-Servern im WWW. Der Benchmark misst die Leistung eines HTTP-Servers unter einer standardisierten Last von Anfragen nach statischen und dynamischen Webseiten. Die neue Version enthält viele Erweiterungen zum Test der ständig fortschreitenden Web-Technologien. Im Unterschied zur Vorgängerversion ist SPECweb2005 in drei verschiedene Workloads aufgeteilt, die sich an echten Anwendungen orientieren: - SPECweb2005_Banking – Es werden typische Anfragen simuliert, die Kunden einer Online-Bank abschicken, wie Anmelden/Abmelden, Kontostandsabfrage, Überweisungen, Anzeigen und Ändern des Benutzerprofils usw.. Die Anmeldung umfasst die Einrichtung einer SSL Verbindung, die für alle weiteren Aktionen genutzt wird. - SPECweb2005_Ecommerce – Es wird ein Online-Geschäft für Computer simuliert. Die Benutzer können die Seiten durchsuchen, Waren anschauen, Bestellungen zusammenstellen und die Produkte erwerben. Die ersten Schritte erfolgen über ungesicherte Verbindungen. Sobald eine Bestellung abgeschickt werden soll, werden daraus SSLverschlüsselte Verbindungen. - SPECweb2005_Support – Hier werden die Anfragen einer Support Seite simuliert. Die Benutzer können die Seite durchsuchen, Listen verfügbarer Produkte anschauen und die zugehörigen Dateien herunterladen. Alle Anfragen erfolgen unverschlüsselt. Die Anfragen aller drei Workloads umfassen dynamisch erzeugte Inhalte und statische Dateien verschiedener Größe. Zwischen den Anfragen werden unterschiedliche Wartezeiten eingehalten. Die Verteilung der Anfragen und die Dauer der Wartezeiten werden über Tabellen und Funktionen gesteuert. Die Durchschnittswerte für diese Größen sind in Konfigurationsdateien festgelegt und werden durch die Ablaufsteuerung überwacht. SPECweb2005 ist nicht an ein spezielles Betriebssystem oder einen bestimmten Web-Server gebunden. Die Benchmark-Umgebung besteht aus mehreren Teilen. Auf den Client-Systemen läuft ein Lastgenerator-Programm, das Verbindungen zum Web-Server aufbaut, Seitenanforderungen sendet und die Antwortseiten empfängt. Ein Prime Client initialisiert die anderen Systeme, überwacht den Testablauf, sammelt die Ergebnisse und und wertet sie aus. Der Web-Server oder System Under Test (SUT) umfasst die Hardware und Software zur Bearbeitung der Anfragen. Neu hinzugekommen ist der Back-End Simulator (BeSim), der die Datenbank- und Applikationsteile der gesamten Anwendung simuliert. Der Web-Server kommuniziert mit dem BeSim über HTTP-Anfragen, um zusätzlich erforderliche Informationen zu erhalten. Die Ablaufsteuerung und die Client-Programme sind in Java programmiert und in einzelne Threads unterteilt, die jeweils einen virtuellen Benutzer (Session) simulieren. Alle drei Workloads durchlaufen im Test verschiedene Phasen. In der Ramp-Up Phase werden die Threads zur Lastgenerierung nacheinander gestartet. Es folgt eine Warm-Up Phase zur Vorbereitung der Messung. Bevor das eigentliche Messinterval beginnt, werden die bisher aufgezeichneten Ergebnisse und Fehler gelöscht. Während der Messphase werden alle Anfragen und Antworten aufgezeichnet zur Ermittlung der Ergebnisse. In der anschliessenden Ramp-Down Phase werden die Threads gestoppt. Danach folgt eine Ruhephase, bevor der nächste Durchlauf wieder mit einer RampUp Phase beginnt. Insgesamt werden so jeweils drei Durchläufe für jeden Workload durchgeführt. Die Zahl der erzeugten Threads wird für jeden Workload extra je nach Leistungsfähigkeit des SUT in der Testkonfiguration festgelegt. Zur Ermittlung der Ergebnisse werden auf den Clients für jede angeforderte Seite die Zeiten gemessen zwischen dem Abschicken der Anfrage und dem Eintreffen aller Daten, die zu dieser Seite gehören. Ferner werden die Antwortzeiten für eingebettete Bilddateien hinzugezählt. Im Ergebnis werden alle Seiten gewertet, die bestimmte QoS (Quality of Service) Kriterien erfüllen. Dazu werden die Anworten nach Antwortzeiten (Banking und Ecommerce) bzw. Transferraten (Support) innerhalb der Workloads in folgende Klassen eingeteilt: - GOOD – Antwortzeit < 2s (Banking), < 3s (Ecommerce); Transferrate > 99000 Bytes/s (Support) TOLERABLE – Antwortzeit < 4s (Banking), < 5s (Ecommerce); Transferrate > 95000 Bytes/s (Support) FAILED – Antwortzeit > 4s (Banking), > 5s (Ecommerce); Transferrate < 95000 Bytes/s (Support) Für ein gültiges Workload-Ergebnis müssen in allen drei Durchläufen mindestens 95% aller Antworten in die Klasse GOOD und 99% in die Klasse TOLERABLE fallen. Ein regelkonformes Gesamtergebnis erfordert gültige Teilergebnisse in allen drei Workloads mit der gleichen Systemkonfiguration. Die Einzelresultate sind nach den Workloads benannt und zeigen, wieviele Benutzer (Sessions) maximal bei Einhaltung der QoS Kriterien vom gemessenen System bedient werden können. Sie ermöglichen so die Beurteilung eines Systems unter realitätsnahen Bedingungen. Zur Berechnung des Gesamtergebnisses wird jedes Teilresultat ins Verhältnis zu SPEC®, SPECweb® und das SPEC-Logo sind eingetragene Warenzeichen der Standard Performance Evaluation Corporation (SPEC). © Fujitsu Technology Solutions 2009 Seite 16 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 einem Referenzwert gesetzt und aus diesen drei Werten wird das geometrische Mittel gebildet multipiziert mit 100. Das Gesamtergebnis (SPECweb2005) zeigt also die relative Leistung des gemessenen Systems im Verhältnis zum Referenzsystem. Benchmark-Ergebnisse Im Mai 2008 wurde die PRIMERGY RX600 S4 mit vier Prozessoren Xeon X7350 sowie 72 GB PC2-5300F DDR2SDRAM vermessen. Für das Netzwerk wurden vier quad-port Intel PRO/1000PT (PCIe) und ein Intel PRO/1000 (onboard) verwendet. Als Disk-Subsystem kamen zwei FibreCAT CX500 mit jeweils 75 Festplatten vom Typ Seagate ST336753 mit 36 GB und 15 krpm zum Einsatz, die über einen Qlogic QLE2462 Fibre Channel Controller angeschlossen waren. Es wurden zwei RAID 5 Verbände über je 75 Festplatten gebildet. Diese wurden zu einem RAID 0 zusammengefasst. Das Betriebssystem lag auf einer Festplatte des Typs Seagate ST936751SS, die über den onboard SAS-Controller betrieben wurde. Die Messung wurde mit der HTTP-Software Accoria Rock Web Server v1.4.7 (x86_64) unter Red Hat Enterprise Linux 5.1 (2.6.18-53.el5 x86_64) durchgeführt. Die PRIMERGY RX600 S4 erzielte das weltweit beste SPECweb2005-Ergebnis aller Server. Quelle: http://www.spec.org/web2005/results, Stand: 9. Juni 2008 Im Nobember 2008 wurde die PRIMERGY RX600 S4 mit vier Prozessoren Xeon X7460 sowie 64 GB PC2-5300F DDR2SDRAM vermessen. Für das Netzwerk wurden vier quad-port Intel PRO/1000PT (PCIe) und ein Intel PRO/1000 (onboard) verwendet. Als Disk-Subsystem kamen vier FibreCAT SX40 mit jeweils 12 Festplatten vom Typ Seagate ST3300656SS mit 300 GB und 15 krpm zum Einsatz, die über einen LSI SAS MegaRAID 8880EM2 Controller angeschlossen waren. Es wurden zwei RAID 0 Verbände über je 24 Festplatten gebildet. Diese wurden zu einem RAID 0 zusammengefasst. Die Logdateien lagen auf vier Festplatten des Typs Seagate ST973401SS, das Betriebssystem auf einer Festplatte des Typs Seagate ST936751SS: Diese fünf Festplatten wurden über den onboard SAS-Controller betrieben. HTTP-Software und Betriebssystem entsprachen der Messung vom Mai 2008. Die oben genannten Vergleichswerte zu Wettbewerbsprodukten geben den Stand vom 9. Juni 2008 wieder. Der vorgestellte Vergleich basiert auf den besten vier SPECweb2005-Ergebnissen aller Server. Es werden die zu diesem Zeitpunkt besten verfügbaren Systeme von Fujitsu, HP, Sun und Fujitsu Siemens Computers, heute firmierend unter Fujitsu, verglichen. Die aktuellen SPECweb2005-Ergebnisse sind zu finden unter http://www.spec.org/web2005/results. © Fujitsu Technology Solutions 2009 Seite 17 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Die PRIMERGY RX600 S4 erzielte erneut das weltweit beste SPECweb2005-Ergebnis aller Server. Quelle: http://www.spec.org/web2005/results, Stand: 23. Dezember 2008 Im Februar 2009 wurde die PRIMERGY RX600 S4 mit vier Prozessoren Xeon X7460 sowie 128 GB PC2-5300F DDR2SDRAM vermessen. Für das Netzwerk wurden fünf quad-port Intel PRO/1000PT (PCIe) und ein Intel PRO/1000 (onboard) verwendet. Als Disk-Subsystem kamen zwei FibreCAT CX500 mit jeweils 60 Festplatten vom Typ Seagate ST336753 mit 36 GB und 15 krpm zum Einsatz, die über einen Emulex LPe11002 Fibre Channel Controller angeschlossen waren. Es wurden zwei RAID 0 Verbände über je 60 Festplatten gebildet. Diese wurden zu einem RAID 0 zusammengefasst. Die Logdateien lagen auf vier Festplatten des Typs Seagate ST973401SS, das Betriebssystem auf einer Festplatte des Typs Seagate ST936751SS: Diese fünf Festplatten wurden über den onboard SAS-Controller betrieben. Die Messung wurde unter Red Hat Enterprise Linux 5.2 (2.6.18-92.el5 x86_64) durchgeführt. Die HTTPSoftware entsprach der Messung vom Mai 2008. Die PRIMERGY RX600 S4 erzielte wie üblich das weltweit beste SPECweb2005-Ergebnis aller Server. Quelle: http://www.spec.org/web2005/results, Stand: 13. März 2009 Die oben genannten Vergleichswerte zu Wettbewerbsprodukten geben den Stand vom 23. Dezember 2008 wieder. Der vorgestellte Vergleich basiert auf den besten drei SPECweb2005-Ergebnissen aller Server. Es werden die zu diesem Zeitpunkt besten verfügbaren Systeme von HP und Fujitsu Siemens Computers, heute firmierend unter Fujitsu, verglichen. Die aktuellen SPECweb2005-Ergebnisse sind zu finden unter http://www.spec.org/web2005/results. Die oben genannten Vergleichswerte zu Wettbewerbsprodukten geben den Stand vom 13. März 2009 wieder. Der vorgestellte Vergleich basiert auf den besten vier SPECweb2005-Ergebnissen aller Server. Es werden die zu diesem Zeitpunkt besten verfügbaren Systeme von Sun, HP und Fujitsu verglichen. Die aktuellen SPECweb2005-Ergebnisse sind zu finden unter http://www.spec.org/web2005/results. © Fujitsu Technology Solutions 2009 Seite 18 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Gegenüber der PRIMERGY RX600 S3, die im September 2006 gleichfalls einen SPECweb2005-Weltrekord aufgestellt hatte, verbesserte die PRIMERGY RX600 S4 die Durchsatzleistung um 245%. Benchmark-Umgebung* Messung Mai 2008 Disk subsystem 2 FibreCAT CX500 with 150 36 GB Seagate ST336753 ● ● ● ● ● ● ● ● ● ● 64 PRIMERGY RX100 S3 1 x Pentium D 820 2 GB RAM 2 x Broadcom NetXtreme (onboard) Windows Server 2003 SE SP1 © Fujitsu Technology Solutions 2009 PRIMERGY RX600 S4 4 Xeon X7350 72 GB PC2-5300F DDR2-SDRAM 1 Qlogic QLE2462 fibre channel controller 4 quad channel Intel PRO/1000PT (PCIe) 1 Intel PRO/1000PT (onboard) Operating system: Red Hat Enterprise Linux 5.1 (2.6.18-53.el5 x86_64) HTTP software: Accoria Rock Web Server v1.4.7 (x86_64) Seite 19 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Messung Dezember 2008 Disk subsystem 4 FibreCAT SX40 with 48 hard disks (300 GB, 3.5”, 15 krpm) ● ● ● ● ● ● ● ● ● ● 64 PRIMERGY RX100 S3 1 x Pentium D 820 2 GB RAM 2 x Broadcom NetXtreme (onboard) Windows Server 2003 SE SP1 PRIMERGY RX600 S4 4 Xeon X7460 64 GB PC2-5300F DDR2-SDRAM 1 LSI Fusion MPT SAS/RAID 1078I controller (onboard) 1 LSI SAS/MegaRAID 8880EM2 controller 4 quad channel Intel PRO/1000PT (PCIe) 1 Intel PRO/1000PT (onboard) Operating system: Red Hat Enterprise Linux 5.1 (2.6.18-53.el5 x86_64) HTTP software: Accoria Rock Web Server v1.4.7 (x86_64) Messung Februar 2009 Disk subsystem 2 FibreCAT CX500 with 120 36 GB Seagate ST336753 ● ● ● ● ● ● ● ● ● ● 60 PRIMERGY RX100 S3 1 x Pentium D 820 2 GB RAM 2 x Broadcom NetXtreme (onboard) Windows Server 2003 SE SP1 * PRIMERGY RX600 S4 4 Xeon X7460 128 GB PC2-5300F DDR2-SDRAM 1 Emulex LPe11002 fibre channel controller 5 quad channel Intel PRO/1000PT (PCIe) 1 Intel PRO/1000PT (onboard) Operating system: Red Hat Enterprise Linux 5.2 (2.6.18-92.el5 x86_64) HTTP software: Accoria Rock Web Server v1.4.7 (x86_64) Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. © Fujitsu Technology Solutions 2009 Seite 20 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 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 Messwerkzeug Iometer mit einem definierten Satz von in der Praxis vorkommenden Lastprofilen und einem festgelegten Messszenario. Messwerkzeug Seit Ende 2001 ist Iometer ein Projekt bei http://SourceForge.net und wird von einer Gruppe internationaler Entwickler auf verschiedene Plattformen portiert und weiterentwickelt. Iometer besteht aus einer grafischen Bedieneroberfläche für Windows-Systeme und dem so genannten »dynamo«, der für verschiedene Plattformen verfügbar ist. Diese beiden Komponenten können seit einigen Jahren unter »Intel Open Source License« von http://www.iometer.org/ oder http://sourceforge.net/projects/iometer heruntergeladen 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) wesentlicher 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 Subsysteme bei bestimmten Zugriffsmustern vergleichen. Iometer ist in der Lage, sowohl auf I/O-Subsysteme mit einem Dateisystem als auch auf I/O-Subsysteme ohne Dateisystem, so genannte Raw-Devices, zuzugreifen. Mit Iometer können die Zugriffsmuster verschiedenster Anwendungen simuliert und vermessen werden, jedoch bleibt der File-Cache des Betriebssystems außer Acht und es wird blockmäßig auf einer einzelnen Testdatei operiert. Lastprofil Von erheblichem Einfluss auf die Performance eines Speichersystems ist die Art, wie Anwendungen auf den Massenspeicher zugreifen. Beispiele für verschiedene Zugriffsmuster einiger Anwendungen: Anwendung Zugriffsmuster Datenbank (Datentransfer) random, 67% read, 33% write, 8 KB (SQL Server) Datenbank (Log File) sequentiell, 100% write, 64 KB Blöcke Backup sequentiell, 100% read, 64 KB Blöcke Restore sequentiell, 100% write, 64 KB Blöcke Video Streaming sequentiell, 100% read, Blöcke ≥ 64 KB File-Server random, 67% read, 33% write, 64 KB Blöcke Web-Server random, 100% read, 64 KB Blöcke Betriebssystem random, 40% read, 60% write, Blöcke ≥ 4 KB File-Copy random, 50% read, 50% write, 64 KB Blöcke Daraus wurden vier markante Profile abgeleitet: Lastprofil Zugriff Zugriffsmuster read Streaming sequentiell Restore sequentiell write 100% Blockgröße Last-Tool 64 KB Iometer 100% 64 KB Iometer Database random 67% 33% 8 KB Iometer File-Server random 67% 33% 64 KB Iometer Alle vier Profile wurden mit Iometer generiert. © Fujitsu Technology Solutions 2009 Seite 21 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Messszenario Um vergleichbare Messergebnisse zu erhalten ist es wichtig, alle Messungen in identischen, reproduzierbaren Umgebungen durchzuführen. Daher liegen StorageBench neben dem oben beschriebenen Lastprofil die folgenden Regeln zugrunde: 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 einem Dateisystem formatiert. Für Windows wird NTFS, für Linux ext3 verwendet, auch wenn mit anderen Dateisystemen oder Raw-Devices eventuell eine höhere Leistung erreicht werden könnte. Festplatten gehören zu den fehleranfälligsten Komponenten eines Computersystems. Daher werden in Serversystemen RAID-Controller eingesetzt, um dem Datenverlust durch den Ausfall von Festplatten vorzubeugen. Dabei werden mehrere Festplatten zu einem »Redundant Array of Independent Disks«, kurz RAID, zusammengefasst. Dabei werden die Daten über mehrere Festplatten derart verteilt, dass auch beim Ausfall einer Festplatte alle Daten, mit Ausnahme von RAID 0, erhalten bleiben. Die gebräuchlichsten Arten um Festplatten in Verbänden zu organisieren sind die RAID-Levels RAID 0, RAID 1, RAID 5, RAID 6, RAID 10, RAID 50 und RAID 60. Informationen zu den Grundlagen verschiedener RAID-Levels sind im Papier Performance Report Modular RAID für PRIMERGY zu finden. Für die StorageBench-Untersuchungen der PRIMERGY Server werden die je nach Plattenanzahl und eingebautem Controller möglichen RAID-Konfigurationen verwendet. Bei Systemen mit zwei Festplatten RAID 1 und RAID 0, bei drei und mehr Festplatten zusätzlich RAID 1E und RAID 5 und ggf. weitere RAID-Levels – sofern der Controller diese RAID-Levels unterstützt. Für die Messung wird immer eine Messdatei mit einer Größe von 8 GB verwendet, unabhängig von der Größe der Festplatte. Bei der Beurteilung der Leistungsfähigkeit von I/O-Subsystemen spielen bei heutigen Systemen die Prozessorleistung und der Speicherausbau des Systems keine signifikante Rolle – ein eventuell vorhandener Engpass betrifft in der Regel die Festplatten und den RAID-Controller und nicht CPU oder Memory. Daher brauchen unterschiedliche Ausbauvarianten mit CPU und Speicher unter StorageBench nicht untersucht zu werden. Messergebnisse StorageBench liefert pro Lastprofil eine ganze Reihe von Kenngrößen, z.B. den »Datendurchsatz« in Megabytes pro Sekunde, kurz MB/s, die »Transaktionsrate« in I/O-Operationen pro Sekunde, kurz IO/s, und die »Latenzzeit« oder auch »mittlere Zugriffszeit« in ms. Für die sequentiellen Lastprofile ist der Datendurchsatz die übliche Messgröße, während bei den random-Lastprofilen mit ihren kleinen Blockgrößen die Messgröße »Transaktionsrate« allgemein verwendet wird. Datendurchsatz und Transaktionsrate sind direkt proportional zueinander und lassen sich nach der Formel Datendurchsatz [MB/s] = Transaktionsrate [Disk-I/O s-1] × Blockgröße [MB] Transaktionsrate [Disk-I/O s-1] = Datendurchsatz [MB/s] / Blockgröße [MB] berechnen. Benchmark-Ergebnisse Die PRIMERGY RX600 S4 ist mit dem Controller LSI MegaRAID SAS 1078 der »Modular RAID« Familie ausgestattet. Der Controller wird als Riser-Karte mit der PRIMERGY RX600 S4 mitgeliefert und bietet dem Anwender eine komplette RAID-Lösung an. Es werden die RAID-Levels 0, 1, 5, 6, 10, 50 und 60 unterstützt. Der Controller wird mit 512 MB Controller-Cache angeboten. Der Controller-Cache kann durch eine optionale Battery Backup Unit (BBU) gegen Stromausfälle geschützt werden. Der Controller unterstützt bis zu 240 Festplatten. An den Controller können unterschiedliche 2½" SAS-Festplatten angeschlossen werden. In Abhängigkeit von der benötigten Performance und Kapazität kann das Disk-Subsystem passend ausgewählt werden. Die PRIMERGY RX600 S4 bietet acht hot-plug Einschübe für 2½" SAS-Festplatten. Für die PRIMERGY RX600 S4 stehen folgende Festplatten zur Auswahl: 2½" SAS Festplatten mit einer Kapazität von 36 GB, 73 GB und 146 GB (10 krpm) 2½" SAS Festplatten mit einer Kapazität von 36 GB und 73 GB (15 krpm) RAID-Unterstützung Der RAID-Verband definiert die Art und Weise, wie die Daten hinsichtlich der Verfügbarkeit behandelt werden. Wie schnell die Daten im jeweiligen RAID-Verband-Kontext transportiert werden, hängt nicht unwesentlich vom Datendurchsatz der Festplatten ab. Der Durchsatz ist weiterhin geprägt vom verwendeten RAID-Level und Zugriffsmuster sowie von den Controller- und Disk-Cache-Einstellungen. Weil der LSI MegaRAID SAS 1078 Controller einen Cache besitzt, wurden bei den Messungen sowohl die Auswirkungen der Controller-Cache- als auch der Disk-Cache-Parameter auf den Gesamtdurchsatz untersucht. Der Disk-Cache hat Einfluss auf die Disk-I/O-Performance, aber er wird leider häufig als Sicherheitsproblem bei Stromausfall angesehen und daher abgeschaltet. Andererseits wurde er von den Festplattenherstellern aus gutem © Fujitsu Technology Solutions 2009 Seite 22 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Grund zur Steigerung der Schreib-Performance integriert. Aus Performance-Gründen ist es empfehlenswert, den DiskCache einzuschalten. Der weitaus größere Cache für I/O-Zugriffe und damit potentielles Sicherheitsrisiko für Datenverluste bei Stromausfall sitzt ohnehin im Arbeitsspeicher und wird vom Betriebssystem verwaltet. Um Datenverlusten vorzubeugen, empfiehlt es sich, das System mit einer USV auszustatten. Abhängig vom RAID-Level wurde die Anzahl Festplatten festgelegt, die für die Messungen in einem RAID-Verband konfiguriert wurden. Im Testaufbau wurden zwei Festplatten an den Controller angeschlossen und als RAID 1 konfiguriert. Bei den Messungen wurden 2½" SAS-Festplatten mit 10 krpm und 15 krpm verwendet. Dabei wurde der Einfluss der Umdrehungsgeschwindigkeit der Festplatten auf die Durchsätze bei sequentiellem Lesen/Schreiben sowie bei wahlfreiem Zugriff untersucht. Es wurden jeweils zwei Messreihen durchgeführt. Eine mit ausgeschalteten Caches (Off), d.h. »No Read-ahead«, »Write-through«, »I/O direct« und »Disk cache disabled« und eine mit optimalen Cache-Einstellungen (Optimal), d.h. »No Read-ahead«, »Write-through«, »I/O direct« und »Disk cache enabled«. Mit diesen Cache-Einstellungen kann man bei einem Mix von Zugriffsmustern die besten Durchsätze erreichen. Die Grafik für RAID 1 zeigt, dass der Durchsatz mit steigender Umdrehungsgeschwindigkeit bei allen Zugriffsmustern steigt. Werden beim sequentiellen Lesen im RAID 1 statt Festplatten mit einer Umdrehungsgeschwindigkeit von 10 krpm Festplatten mit 15 krpm verwendet, ergibt sich eine Durchsatzsteigerung von etwa 20%. Wird beim sequentiellen Schreiben im RAID 1 und bei eingeschaltetem Disk-Cache statt Festplatten mit einer Umdrehungsgeschwindigkeit von 10 krpm eine Festplatte mit 15 krpm verwendet, ergibt sich eine Durchsatzsteigerung von etwa 18%. Eine besondere Durchsatzsteigerung beim sequentiellen Schreiben kann man durch das Einschalten des Disk-Caches erreichen. Bei den 2½" Festplatten mit 10 krpm steigt der Durchsatz um 47% und bei den 2½" Festplatten mit 15 krpm um etwa 62%. Die nebenstehende Grafik zeigt, dass auch bei wahlfreiem Zugriff mit 67% Leseanteil der Disk-Cache eine wichtige Rolle bei der Verbesserung des Durchsatzes spielt. Die Durchsatzsteigerung bei den beiden Festplattentypen durch Einschalten des Disk-Caches beträgt etwa 15%. Vergleicht man den Durchsatz der 2½" SAS-Festplatten mit 10 krpm und 15 krpm, sieht man, dass der Durchsatz der schnelleren Festplatte bei wahlfreiem Zugriff mit 8 KB und 64 KB Blöcken etwa um 22% höher ist als bei der langsameren Festplatte. Die Cache-Einstellungen, die bei den Messungen im RAID 1 verwendet wurden, bringen im Durchschnitt bei einem Mix von Zugriffsmustern die besten Durchsätze. Bei speziellen Zugriffsmustern, z.B. beim wahlfreien Zugriff im RAID 1, können durch Einschalten des Controller-Caches, also durch die Verwendung der Controller-Cache-Optionen »No Readahead«, »Write-back«, »I/O direct« und »Disk cache enabled« noch höhere Durchsätze erreicht werden. Allerdings ist es in diesem Falle unabdingbar, den Controller-Cache gegen eventuelle Stromausfälle mit einer BBU zu sichern, um einen Datenverlust zu vermeiden. © Fujitsu Technology Solutions 2009 Seite 23 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Bei den weiteren Messungen wurden nur die schneller drehenden 15 krpm Festplatten verwendet. Die zweite Grafik stellt die Durchsätze dieser Festplatten im RAID 5 Verband dar. Die Durchsätze wurden bei ausgeschalten Caches (Off) und bei den optimalen Cache-Einstellungen (Optimal) ermittelt. Beim sequentiellen Lesen mit 64 KB Blöcken haben Controller- und DiskCache keine Auswirkung auf die Durchsätze. Bei den anderen Zugriffsmustern dagegen kann man die Durchsätze durch die geeignete Controller-Cache-Einstellungen teilweise erheblich erhöhen. Diese Durchsatzsteigerungen falllen allerdings, je nach Datenstruktur und Zugriffsmuster, unterschiedlich aus. Beispielsweise hängt der Schreibdurchsatz beim sequentiellen Schreiben stark von den Cache-Einstellungen ab. Um die beste Leistung zu erreichen, ist es notwendig, die optimalen CacheEinstellungen »Write-back«, »I/O direct« und »Disk-Cache enabled« zu verwenden. Der erreichete Durchsatz ist um den Faktor 30 höher, als der, der bei ausgeschalteten Caches erreicht wurde. Beim wahlfreien Zugriff im RAID 5 ist die Performance-Steigerung durch die optimale Cache-Einstellung auch ziemlich groß, allerdings nicht mehr so beeindruckend, wie es beim sequentiellen Schreiben der Fall war. Beim wahlfreien Zugriff mit 8 KB Blöcken steigt der Durchsatz etwa um 62% und mit 64 KB Blöcken um 54%. Ähnliche Charakteristika kann man auch aus der Grafik für RAID 10 entnehmen. Die Cache-Einstellungen beim sequentiellen Lesen haben auch im RAID 10 keinen Einfluß auf den Durchsatz. Beim sequentielllen Schreiben dagegen kann man durch die optimale Cache-Einstellung eine bis zu 4.5-fache Durchsatzsteigerung erreichen. Beim wahlfreien Zugriff im RAID 10 ist die Performance-Steigerung durch die optimale Cache-Einstellung auch ziemlich groß, allerdings nicht mehr so markant wie es beim sequentiellen Schreiben der Fall war. Beim wahlfreien Zugriff mit 8 KB Blöcken steigt der Durchsatz etwa um 37% und mit 64 KB Blöcken um 29%. Umfangreichere Information zu diesem Thema sind im Papier Performance Report - Modular RAID für PRIMERGY zu finden. Fazit Mit dem »Modular RAID« LSI MegaRAID SAS 1078 Controller bietet die PRIMERGY RX600 S4 eine Fülle von Möglichkeiten, um den verschiedenen Anforderungen unterschiedlichster Anwendungsszenarien gerecht zu werden. Der LSI MegaRAID SAS 1078 Controller bietet alle heute gängige RAID-Lösungen RAID 0, 1, 5, 6, 10, 50 und 60 an. Der Controller wird mit einem 512 MB großen Controller-Cache ausgeliefert und kann optional mit einer BBU gesichert werden. Vielfältige Möglichkeiten, die Nutzung des Caches einzustellen, erlauben eine flexible Anpassung der Controllerleistung an den verwendeten RAID-Level. Die Verwendung von RAID 5 ermöglicht eine wirtschaftliche Ausnutzung der vorhandenen Festplattenkapazität bei guter Performance. Für optimale Performance beim wahlfreien Zugriff und Sicherheit ist jedoch ein RAID 10 zu empfehlen. Die PRIMERGY RX600 S4 bietet die Auswahl zwischen 2½" SAS Festplatten mit 10 krpm oder 15 krpm Umdrehungsgeschwindigkeit. In Abhängigkeit von der benötigten Performance ist zu entscheiden, welcher Festplattentyp mit welcher Umdrehungsgeschwindigkeit zum Einsatz kommen soll. Festplatten mit 15 krpm bieten eine bis zu 62% bessere Performance. © Fujitsu Technology Solutions 2009 Seite 24 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Benchmark-Umgebung* Alle hier vorgestellten Messungen wurden mit den im Folgenden aufgelisteten Hardware- und Software-Komponenten durchgeführt. * Komponente Details Server PRIMERGY RX600 S4 Betriebssystem Windows Server 2003, Enterprise Edition Version: 5.2.3790 Service Pack 1 Build 3790 Dateisystem NTFS Messwerkzeug Iometer 27.07.2006 Messdaten Messdatei von 8 GB Controller LSI MegaRAID SAS 1078 Produkt: LSI RAID 5/6 SAS 1078 Driver Name: msas2k3.sys, Driver Version: 2.17.0.32 Controller Cache: 512 MB Hard Disk SAS, 2½", 10 krpm, Seagate ST973402SS, 73 GB Hard Disk SAS, 2½", 15 krpm, Seagate ST973451SS, 73 GB Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. © Fujitsu Technology Solutions 2009 Seite 25 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 OLTP-2 Benchmark-Beschreibung OLTP steht für Online Transaction Processing. Dem OLTP-2-Benchmark liegt das typische Anwendungsszenario einer Datenbanklö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. Der zum Teil enorme Hardware- und Zeit-Aufwand der standardisierten Benchmarks wurde 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 und die gleichen Lastprofile verwenden, 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-EWerten ähnlich. Ein direkter Vergleich oder gar die Bezeichnung des OLTP-2-Ergebnisses als TPC-E-Ergebnis ist nicht zulässig, da insbesondere kein Preis-Leistungswert ermittelt wird. Benchmark-Ergebnisse Die PRIMERGY RX600 S4 wurde mit Intel Xeon Prozessoren der Serien 73xx und 74xx bei Speicherausbauten von 64 GB, 128 GB und 256 GB vermessen. Alle Ergebnisse basieren auf dem Betriebssystem Microsoft Windows Server 2008 Enterprise x64 Edition und der Datenbank SQL Server 2008 Enterprise x64 Edition. OLTP-2 Benchmark-Ergebnisse sind in hohem Maße abhängig von den Ausbaumöglichkeiten eines Systems mit Festplatten und deren Controllern. Für die Messungen wurden daher zwei Ausbaustufen des Disk-Subsystems mit 240 und 336 SAS-Festplatten verwendet. Weitere Informationen über die Systemkonfiguration können dem Abschnitt Benchmark-Umgebung entnommen werden. Die folgende Grafik zeigt die OLTP-2-Leistungsdaten der PRIMERGY RX600 S4 mit Intel Xeon Serie 73xx Prozessoren (E7220, E7310, E7330 und X7350) und einem Disk-Subsystem mit 240 SAS Festplatten. OLTP-2: OLTP-2:PRIMERGY PRIMERGYRX600 RX600S4 S4wwith ith22and and44Xeon Xeonprocessors processors73xx 73xx 501.23 501.23 tps tps 453.10 453.10 489.96 489.96 500 500 443.13 443.13 464.59 464.59 371.83 371.83421.12 421.12 363.83 363.83 bold boldnumbers: numbers:measured measuredresults results others: calculated others: calculatedresults results 400 400 300 300 200 200 273.39 273.39 245.42 245.42 269.22 269.22 241.79 200.60 200.60 241.79 258.22 258.22 167.56 231.82 167.56 197.73 197.73 231.82 165.25 165.25 190.13 190.13 159.62 159.62 308.14 308.14 346.50 346.50 301.65 301.65 289.22 289.22 +80-83% +80-83% RAM RAM 100 100 00 +60-63% +60-63% +62-63% +62-63% 256 256GB GB 128 GB 128 GB 64 64GB GB Xeon Xeon E7220 E7220 Xeon Xeon E7310 E7310 Xeon Xeon E7330 E7330 Xeon Xeon X7350 X7350 Xeon Xeon E7220 E7220 Xeon Xeon E7310 E7310 Xeon Xeon E7330 E7330 Xeon Xeon X7350 X7350 Die Skalierung über alle Prozessor-Typen liegt bei +60% bis +63% und ist bei zwei und vier Prozessoren in etwa identisch. Besonders gut ist die Skalierung von zwei auf vier Prozessoren mit bis zu +83%. Die Speicherskalierung von 64 GB auf 128 GB beträgt +4% bis +5% und von 128 GB auf 256 GB +1% bis +2%. Dies ist sehr stark vom Lastprofil des OLTP-2 Benchmarks abhängig und kann nicht auf alle Datenbankanwendungen übertragen werden. © Fujitsu Technology Solutions 2009 Seite 26 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Die folgende Grafik zeigt die OLTP-2-Leistungsdaten der PRIMERGY RX600 S4 mit Intel Xeon Serie 74xx (L7445, E7430, E7450 und X7460) und einem Disk-Subsystem mit 336 SAS-Festplatten. Der Low Voltage Prozessor Xeon L7445 unterscheidet sich nur im Stromverbrauch vom Xeon E7430 und erreicht für diesen Benchmark die gleichen Durchsatzwerte. tps tps OLTP-2: OLTP-2:PRIMERGY PRIMERGYRX600 RX600S4 S4wwith ith22and and44Xeon Xeonprocessors processors74xx 74xx 736.94 736.94 718.91 656.69 656.69 718.91 700 700 bold boldnumbers: numbers:measured measuredresults results others: others:calculated calculatedresults results 641.32 641.32 649.11 649.11 590.07 478.77 478.77 478.77 478.77 590.07 600 600 468.07 468.07 468.07 468.07 401.99 401.99 500 500 400 400 300 300 355.38 355.38 394.96 394.96 349.56 349.56 369.92 251.07 369.92 251.07 251.07 251.07329.26 329.26 247.24 247.24 247.24 247.24 435.09 435.09 435.09 435.09 +75-83% +75-83% 234.43 234.43 234.43 234.43 200 200 RAM RAM +58-60% +58-60% 100 100 00 +49-54% +49-54% Xeon Xeon L7445 L7445 Xeon Xeon E7430 E7430 Xeon Xeon E7450 E7450 Xeon Xeon X7460 X7460 Xeon Xeon L7445 L7445 Xeon Xeon E7430 E7430 Xeon Xeon E7450 E7450 256 256GB GB 128 128GB GB 64 64GB GB Xeon Xeon X7460 X7460 Die Skalierung über diese Prozessortypen liegt bei +49% bis +60% und fällt für zwei Prozessoren etwas höher aus als für 4 Prozessoren. Besonders gut ist auch hier die Skalierung von zwei auf vier Prozessoren mit bis zu +83%. Die Speicherskalierung von 64 GB auf 128 GB beträgt +5% bis +11% und von 128 GB auf 256 GB +1.5% bis +2.5%. Bei vier Prozessoren mit höherem Durchsatz wird mehr Speicher benötigt und die Werte fallen entsprechend höher aus. Auch hier gilt, dass die Angaben für das Lastprofil von OLTP-2 zutreffen und nicht auf alle Datenbankanwendungen übertragen werden kann. Die nebenstehende Graphik zeigt einen OLTP-2: Vergleich zwischen der PRIMERGY RX600 S3 OLTP-2:PRIMERGY PRIMERGYRX600 RX600S4 S4vs. vs.RX600 RX600S3 S3 800 mit Xeon 7140M (2 Cores), der PRIMERGY 800 66Cores tps RX600 S4 mit Xeon X7350 (4 Cores) und der Cores tps PRIMERGY RX600 S4 mit Xeon X7460 (6 700 736.94 700 736.94 Cores). Durch die Verdopplung der Anzahl Cores von zwei auf vier wird eine 600 600 Leistungssteigerung von +46% erreicht. Mit dem 44Cores Xeon X7460 erhöht sich die Anzahl Cores zwar Cores 500 nur um 50%, es wird aber ein 16 MB grosser 500 L3-Cache verwendet, so dass die 489.96 489.96 22Cores Leistungssteigerung gegenüber dem Xeon Cores 400 400 X7350 +50% beträgt. Gegenüber der PRIMERGY RX600 S3 beträgt die Zunahme +121% +121% 300 333.70 des Durchsatzes +121%. 300 333.70 200 200 100 100 +47% +47% +50% +50% 00 PRIMERGY PRIMERGYRX600 RX600S3 S3PRIMERGY PRIMERGYRX600 RX600S4 S4PRIMERGY PRIMERGYRX600 RX600S4 S4 44xxXeon 7140M 4 x Xeon X7350 4 x Xeon X7460 Xeon 7140M 4 x Xeon X7350 4 x Xeon X7460 64 128 256 64GB GBRAM RAM 128GB GBRAM RAM 256GB GBRAM RAM © Fujitsu Technology Solutions 2009 Seite 27 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Benchmark-Umgebung* Für die OLTP-2 Messungen der PRIMERGY RX600 S4 wurde das Disk-Subsystem in zwei Ausbaustufen genutzt. Zum einen mit 240 SAS-Festplatten, 20 FibreCAT SX40 und 4 LSI SAS-RAID Controllern, zum anderen mit 336 SAS-Festplatten, 28 FibreCAT SX40 und 5 LSI SAS RAID Controllern. Diese Konfigurationen entsprechen denen bei den TPC-E Messungen. Als Betriebssystem wurde Microsoft Windows Server 2008 Enterprise x64 Edition und als Datenbank SQL Server 2008 Enterprise x64 Edition eingesetzt. Bei den OLTP-2 Messungen wurden die Prozessor-Typen, die Prozessoranzahl sowie die Speichermenge variiert. Die folgenden beiden Bilder zeigen den Rackaufbau mit Front-End PRIMERGY RX300 S4 (Tier A), Datenbankserver PRIMERGY RX600 S4 (Tier B) und dem Festplattensubsystem FibreCAT SX40. Als Lastgeneratoren (Driver Systems) wurden zwei PRIMERGY Econel 200 verwendet. Testumgebung mit Disk-Subsystem mit 240 SAS-Festplatten Tier A PRIMERGY RX300 S4 2x Intel Xeon E5405 2.00 GHz 4 GB Memory 1x 250 GB SATA Drive Onboard 1 GBit/s Dual-Port LAN 1 GBit/s 2 Driver Systems Storage 1x PRIMECENTER Rack 20x FibreCAT SX40 Disk Drives: 120x 73 GB 15K SAS 120x 146 GB 15K SAS Tier B PRIMERGY RX600 S4 2/4x Intel Xeon X73xx Serie 64/128/256 GB Memory 2x 36 GB 15K SAS Drives 6x 146 GB 10K SAS Drives Onboard SAS RAID Controller 4x SAS RAID Controller Testumgebung mit Disk-Subsystem mit 336 SAS-Festplatten Tier A PRIMERGY RX300 S4 2x Intel Xeon E5405 2.00 GHz 4 GB Memory 1x 250 GB SATA Drive Onboard 1 GBit/s Dual-Port LAN 1 GBit/s 2 Driver Systems * Storage 2x PRIMECENTER Rack 28x FibreCAT SX40 Disk Drives: 192x 73 GB 15K SAS 144x 146 GB 15K SAS Tier B PRIMERGY RX600 S4 2/4x Intel Xeon X74xx Serie 64/128/256 GB Memory 2x 36 GB 15K SAS Drives 6x 146 GB 10K SAS Drives Onboard SAS RAID Controller 5x SAS RAID Controller Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. © Fujitsu Technology Solutions 2009 Seite 28 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 TPC-E Benchmark Beschreibung Der TPC-E-Benchmark misst die Performance online transaktionsverarbeitender Systeme (Online Transaction Processing oder kurz OLTP genannt). Er basiert auf einer komplexen Datenbank und einer Reihe unterschiedlicher Transaktionstypen, die auf ihr ausgeführt werden. TPC-E ist ein sowohl Hardware- als auch Software-unabhängiger Benchmark und kann damit auf jeder Testplattform – sei es eine proprietäre oder offene – implementiert werden. Neben den Messergebnissen müssen auch sämtliche Details der vermessenen Systeme und des Messvorgangs in einem Messreport (Full Disclosure Report oder kurz FDR) erläutert werden. Dadurch wird überprüfbar, ob eine Messung allen BenchmarkAnforderungen entspricht und nachvollziehbar ist. Durch TPC-E wird nicht ein einzelner Server, sondern eine recht umfangreiche Systemkonfiguration vermessen. Performance-bestimmend ist hierbei die Systemleistung des Datenbankservers mit Disk-I/O und Netzwerk-Kommunikation. Die Performance-Metrik ist tpsE. tps steht dabei für transactions per second. tpsE ist die mittlere Anzahl an Trade-Result-Transaktionen, die innerhalb einer Sekunde ausgeführt wurden. Gemäß dem TPC-E-Standard besteht eine korrekte Angabe aus der tpsE-Rate, dem zugehörigen Preis/Leistungs-Wert und dem Verfügbarkeitsdatum (Availability Date) der Konfiguration. Weitere Informationen können dem Dokument Benchmark-Überblick TPC-E entnommen werden. Benchmark-Ergebnisse Im September 2008 veröffentlichte Fujitsu Siemens Computers, heute firmierend unter Fujitsu, zwei TPC-E BenchmarkErgebnisse, für den 4-Core Prozessor Xeon X7350 und den 6-Core Prozessor Xeon X7460, in nahezu identischer Hardware- und Software-Umgebung*. Damit ist es möglich, die enorme Leistungssteigerung bei gleichzeitiger Reduzierung der Kosten zu demonstrieren. Weitere Informationen sowie der Vergleich zum Mitbewerb können der TPCWebseite (http://www.tpc.org/tpce/default.asp) entnommen werden. TPC-E 1.5.1 TPC Pricing 1.3.0 PRIMERGY RX600 S4 TPC-E Throughput 492.34 tpsE Price/Performance $ 559.88 USD per tpsE Availability Date January 1, 2009 Report Date September 10, 2008 Total System Cost $ 275,649 Database Server Configuration Operating System Microsoft Windows Server 2008 Enterprise x64 Edition Database Manager Microsoft SQL Server 2008 Enterprise x64 Edition Processors/Cores/Threads 4/16/16 Memory 128 GB SUT Tier A PRIMERGY RX300 S4 2x Intel Xeon E5405 2.00 GHz 4 GB Memory 1x 250 GB SATA Drive Onboard 1 GBit/s Dual Port LAN 1 GBit/s Tier B PRIMERGY RX600 S4 4x Intel Xeon X7350 2.93 GHz 128 GB Memory 2x 36 GB 15K SAS Drives 6x 146 GB 10K SAS Drives Onboard SAS RAID Controller 4x SAS RAID Controller 2 Driver Systems Storage 1x PRIMECENTER Rack 20x FibreCAT SX40 120x 73 GB 15K SAS Drives 120x 146 GB 15K SAS Drives Initial Database Size 1,928 GB * Redundancy Level 1 RAID-10 Storage 120 x 73 GB15K 120 x 146GB 15K 6 x 146GB 10K Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. © Fujitsu Technology Solutions 2009 Seite 29 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 TPC-E 1.5.1 TPC Pricing 1.3.0 PRIMERGY RX600 S4 TPC-E Throughput 721.40 tpsE Price/Performance $ 459.71 USD per tpsE Report Date September 5, 2008 Total System Cost $ 331,637 Availability Date January 1, 2009 Database Server Configuration Operating System Microsoft Windows Server 2008 Enterprise x64 Edition Database Manager Microsoft SQL Server 2008 Enterprise x64 Edition Processors/Cores/Threads 4/24/24 Memory 128 GB SUT Tier A PRIMERGY RX300 S4 2x Intel Xeon E5405 2.00 GHz 4 GB Memory 1x 250 GB SATA Drive Onboard 1 GBit/s Dual Port LAN 1 GBit/s Tier B PRIMERGY RX600 S4 4x Intel Xeon X7460 2.66 GHz 128 GB Memory 2x 36 GB 15K SAS Drives 6x 146 GB 10K SAS Drives Onboard SAS RAID Controller 5x SAS RAID Controller 2 Driver Systems Storage 2x PRIMECENTER Rack 28x FibreCAT SX40 192x 73 GB 15K SAS Drives 144x 146 GB 15K SAS Drives Initial Database Size 2,798 GB Redundancy Level 1 RAID-10 Storage 192 x 73 GB15K 144 x 146GB 15K 6 x 146GB 10K Im September 2008 ist Fujitsu Siemens Computer, heute firmierend unter Fujitsu, in der TPC-E Liste mit drei Veröffentlichungen vertreten, nachdem bereits das Messergebnis der PRIMERGY TX300 S4 im Mai 2008 eingereicht wurde. System und Prozessor TX300 S4 mit 2x Xeon X5460 RX600 S4 mit 4x Xeon X7350 RX600 S4 mit 4x Xeon X7460 © Fujitsu Technology Solutions 2009 Durchsatz 317.45 tpsE 492.34 tpsE 721.40 tpsE Preis / Performance $ 523.49 pro tpsE $ 559.88 pro tpsE $ 459.71 pro tpsE Verfügbarkeit 30. August 2008 1. Januar 2009 1. Januar 2009 Seite 30 (49) White Paper Performance Report PRIMERGY RX600 S4 Nebenstehende Graphik für 2 Sockel 4 Cores, 4 Sockel 4 Cores und 4 Sockel 6 Cores zeigt Einzelsteigerungen von +51% und +46%. Von der PRIMERGY TX300 S4 zur PRIMERGY RX600 S4 mit dem Xeon X7460 Prozessor beträgt der Leistungsgewinn +127%. Der Preis pro Performance von $560/tpsE ist bei der PRIMERGY RX600 S4 mit dem 4-Core-Prozessor Xeon X7350 etwas höher als $523/tpsE bei der PRIMERGY TX300 S4. Den besten Preis pro Performance von $460/tpsE erreicht die PRIMERGY RX600 S4 mit dem 6Core-Prozessor Xeon X7460. 800.00 800.00 Version: 2.2b, November 2009 TPC-E: TPC-E:PRIMERGY PRIMERGYRX600 RX600S4 S4vs. vs.TX300 TX300 $$600 600 tpsE tpsE $/tpsE $/tpsE 700.00 700.00 721.40 721.40 $560 $560 $523 $523 $$500 500 600.00 600.00 $460 $460 $$400 400 500.00 500.00 492.34 492.34 400.00 400.00 $$300 300 +127 +127 300.00 300.00 317.45 317.45 $$200 200 200.00 200.00 100.00 100.00 +46% +46% $$100 100 +51% +51% 0.00 0.00 $$ PPRIM RIMERGY ERGYTX300 TX300S4 S4 PPRIM RIMERGY ERGYRX600 RX600S4 S4 PPRIM RIMERGY ERGYRX600 RX600S4 S4 22xxXeo 44xxXeo 44xxXeo XeonnX5460 X5460 XeonnX7350 X7350 XeonnX7460 X7460 64 128 128 64GB GBRA RAMM 128GB GBRA RAMM 128GB GBRA RAMM Die folgende Graphik zeigt die besten TPC-E Ergebnisse (Stand 5.9.2008) und die zugehörigen Preis/PerformanceWerte für Konfigurationen mit 4 Prozessoren. Über alle TPC-E Veröffentlichungen betrachtet ist das Ergebnis der PRIMERGY RX600 S4 der viertbeste Performancewert und beste Preis/Performance-Wert. Stand 5. September 2008 1) PRIMERGY RX600 S4 721.40 tpsE, 459.71 $/tpsE, availability date 1/1/2009 2) Inspur NF520D2 702.90 tpsE, 4771.37 China Yuan (CNY) Renminbi/tpsE, availability date 11/300/2008 3) Dell PowerEdge R900 671.35 tpsE, 500.55 $/tpsE, availability date 9/15/2008 © Fujitsu Technology Solutions 2009 Seite 31 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Die folgende Graphik zeigt die besten TPC-E Ergebnisse (Stand 10.9.2008) und die zugehörigen Preis/PerformanceWerte für alle Konfigurationen mit 4 Prozessoren und 4 Cores pro Prozessor. Die PRIMERGY RX600 S4 hat in dieser Klasse den besten Performance-Wert und das beste Preis/Performance-Verhältnis. Stand 10. September 2008 1) PRIMERGY RX600 S4 492.34 tpsE, 559.88 $/tpsE, availability date 1/1/2009 2) IBM System x3850 M2 479.51 tpsE, 1591.20 $/tpsE, availability date 8/30/2008 3) Dell PowerEdge R900 451.29 tpsE, 734.25 $/tpsE, availability date 8/31/2008 4) IBM System x3850 M2 419.80 tpsE, 1527.25 $/tpsE, availability date 12/07/2007 © Fujitsu Technology Solutions 2009 Seite 32 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 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 Finanzen MM Materialwirtschaft SD Vertrieb (Sales und Distribution) PP Produktion und Planung WM Warenwirtschaft (Warehouse Management) PS Projektsystem HR 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/3Standard-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-TierKonfiguration 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 http://www.sap.com/benchmark zu finden. Benchmark-Ergebnisse Mit der Zertifikationsnummer 2008004 belegt SAP, dass die PRIMERGY RX600 S4, ausgestattet mit 4 Xeon X7350 Prozessoren, mit SAP ECC 6.0 und SQL Server 2005 (64-bit) unter Windows Server 2003 Enterprise x64 Edition SP2 am 17. Januar 2008 folgendes Ergebnis erzielte: Number of benchmark users 3660 SD (Sales & Distribution) Average dialog response time 1.99 seconds Throughput Fully Processed Order Line items / hour 366330 Dialog steps / hour 1099000 SAPS 18320 Average DB request time (dia/upd) 0.030 sec / 0.020 sec CPU utilization central server 98% Operating System central server Windows Server 2003 Enterprise x64 Edition SP2 RDBMS SQL Server 2005 (64-bit) SAP ECC Release 6.0 Configuration Central Server PRIMERGY RX600 S4 4 Xeon X7350, 2.93 GHz, 8 MB L2 cache per chip, 64 GB RAM © Fujitsu Technology Solutions 2009 Seite 33 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Mit der Zertifikationsnummer 2007074 belegt SAP, dass die PRIMERGY RX600 S4, ausgestattet mit 4 Xeon X7350 Prozessoren, mit SAP ECC 6.0 und SQL Server 2005 (64-bit) unter Windows Server 2003 Enterprise x64 Edition SP2 auf VMware ESX Server 3.0.2 am 7. November 2007 folgendes Ergebnis erzielte: Number of benchmark users 470 SD (Sales & Distribution) Average dialog response time 1.91 seconds Throughput Fully Processed Order Line items / hour 47330 Dialog steps / hour 142000 SAPS 2370 Average DB request time (dia/upd) 0.019 sec / 0.049 sec CPU utilization of central server 12% CPU utilization inside virtual machine 99% Operating System central server Windows Server 2003 Enterprise x64 Edition SP2 on VMware ESX Server 3.0.2 (using 2 virtual CPUs) RDBMS SQL Server 2005 (64-bit) SAP ECC Release 6.0 Configuration Central Server PRIMERGY RX600 S4 4 Xeon X7350, 2.93 GHz, 8 MB L2 cache per chip, 32 GB RAM Mit der Zertifikationsnummer 2008060 belegt SAP, dass die PRIMERGY RX600 S4, ausgestattet mit 4 Xeon X7460 Prozessoren, mit SAP ECC 6.0 und SQL Server 2005 (64-bit) unter Windows Server 2003 Enterprise x64 Edition SP2 am 25. September 2008 folgendes Ergebnis erzielte: Number of benchmark users 5135 SD (Sales & Distribution) Average dialog response time 1.98 seconds Throughput Fully Processed Order Line items / hour 514330 Dialog steps / hour 1543000 SAPS 25720 Average DB request time (dia/upd) 0.016 sec / 0.015 sec CPU utilization central server 98% Operating System central server Windows Server 2003 Enterprise x64 Edition SP2 RDBMS SQL Server 2005 (64-bit) SAP ECC Release 6.0 Configuration Central Server PRIMERGY RX600 S4 4 Xeon X7460, 2.67 GHz, 3 MB L2 cache per 2 cores, 16 MB L3 cache per chip, 64 GB RAM © Fujitsu Technology Solutions 2009 Seite 34 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Die beiden folgenden Grafiken verdeutlichen die Performance der PRIMERGY RX600 S4 im Vergleich zu ihren Vorgängern und anderen PRIMERGY Rack Servern. Benchmark-Umgebung* Zertifikationsnummer 2008004 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 © Fujitsu Technology Solutions 2009 R/3 & Database Server PRIMERGY RX600 S4 2 Xeon X7350, 2.93 GHz, 8 MB L2 cache per chip 64 GB PC2-5300F DDR2-SDRAM 2 x LSI MegaRAID SAS 8344 ELP controller with 256 MB cache 2 x FibreCAT SX40 21 SAS hard disks, 73 GB, 15 krpm, 2.5” Windows Server 2003 Enterprise x64 Edition SP2 MS SQL Server 2005 (64-bit) SAP ECC 6.0 SR1 Seite 35 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Zertifikationsnummer 2007074: 2-Tier-Umgebung Last-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 RX600 S4 2 Xeon X7350, 2.93 GHz, 8 MB L2 cache per chip 32 GB PC2-5300F DDR2-SDRAM 2 SAS hard disk, 73 GB, 15 krpm VMware ESX Server 3.0.2 Windows Server 2003 Enterprise x64 Edition SP2 MS SQL Server 2005 (64-bit) SAP ECC 6.0 SR1 Zertifikationsnummer 2008060 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 RX600 S4 2 Xeon X7460, 2.67 GHz, 16 MB L3 cache per chip 64 GB PC2-5300F DDR2-SDRAM 2 x LSI MegaRAID SAS 8344 ELP controller with 256 MB cache 2 x FibreCAT SX40 21 SAS hard disks, 73 GB, 15 krpm, 2.5” Windows Server 2003 Enterprise x64 Edition SP2 MS SQL Server 2005 (64-bit) SAP ECC 6.0 SR1 Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. © Fujitsu Technology Solutions 2009 Seite 36 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 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. 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 werBenutzer bei T4UST4USden während der Messung als Lastprofil verwendet. der Arbeit Record Skript Der Lastsimulator von T4US besteht aus drei Komponenten. T4US-Control steuert und überwacht den gesamten SiSystem under Test (SUT) mulationslauf zentral und erController Lastgenerator SUT mittelt Messwerte bereits während der Messung. Auf jedem T4USder Lastgeneratoren laufen Playmehrere Instanzen des T4USback TS-Client Playback. Jedes T4US-Playback „füttert“ einen Terminal T4USServer Client in Echtzeit mit PlayTastatur- und Mauseingaben back TS-Client … anhand der mit T4US-Record aufgezeichneten Skripte und überwacht die BildschirminT4UST4UST4USTerminal halte des Terminal Server Agent PlayControl Server back Clients. Durch hoch auflöTS-Client 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 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 37 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Benchmark-Ergebnisse Bei der PRIMERGY RX600 S4 kommen Intel Xeon Prozessoren zum Einsatz, die es heute in zwei Ausprägungen gibt: mit zwei CPU-Kernen („Dual-Core“) oder mit vier CPU-Kernen („Quad-Core“) pro Chip. Auf diesen Prozessoren sind sowohl 32-bit- als auch 64-bit-Betriebssysteme ablauffähig. 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. 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 2003. Für die 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 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 je einem RAID 0 Verbund von jeweils 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 DiskSubsysteme oder externe File Server legen. 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 Nachfolgend sind die vermessenen Prozessoren mit ihren technischen Daten spezifiziert: Xeon E7220, 2.93 GHz, 1067 MHz Front-Side-Bus, 2 x 4 MB L2-Cache, 80 Watt Xeon E7310, Xeon E7330, Xeon X7350, 1.60 GHz, 2.40 GHz, 2.93 GHz, 1067 MHz Front-Side-Bus, 1067 MHz Front-Side-Bus, 1067 MHz Front-Side-Bus, 2 x 2 MB L2-Cache, 2 x 3 MB L2-Cache, 2 x 4 MB L2-Cache, 80 Watt 80 Watt 130 Watt Der Prozessor Xeon E7220 hat zwei Kerne pro Chip (Dual-Core), die Prozessoren der Reihe x73xx dagegen haben vier Kerne pro Chip (Quad-Core). Der L2-Cache beträgt bei dem Dual-Core Xeon E7220 Prozessor 4 MB pro Core, also 8 MB für zwei Cores. Bei den Quad-Core Xeon x73xx Prozessoren wird der L2-Cache von je zwei Cores gemeinsam benutzt und mit einer höheren CPU-Taktfrequenz steht bei diesem Prozessortyp auch ein größerer L2-Cache von bis zu 8 MB zur Verfügung. So hat der Xeon X7350 Prozessor beispielsweise insgesamt 8 MB L2-Cache, wobei jeweils zwei Cores gemeinsam Zugriff auf einen 4 MB L2-Cache haben. 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. In Anwendungsszenarien, in denen heute die Einschränkungen der 32-bit Architektur hinsichtlich fehlender interner Betriebssystemstrukturen oder beschränktem virtuellen Adressraum eine Ausnutzung der CPU-Ressourcen unmöglich macht, profitiert man vom Umstieg auf ein 64-bit Betriebssystem. Gerade modernen Servern mit einer hohen Anzahl an leistungsfähigen Dual- oder Quad-Core Prozessoren, wie der PRIMERGY RX600 S4, ist die 32-bit Variante von Windows nicht mehr gewachsen und es sollte die moderne 64-bit Version eingesetzt werden, um die Leistungsfähigkeit der Hardware effektiv nutzen zu können. Eine ausführliche Diskussion von Terminal Server unter x64 findet sich in dem Dokument Terminal Server Sizing Guide - 64-bit Technologie (siehe Literaturverzeichnis). © Fujitsu Technology Solutions 2009 Seite 38 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Die folgende Grafik stellt alle Messergebnisse der PRIMERGY RX600 S4 mit unterschiedlicher Prozessorausstattung dar. Das mit dem „Medium User Lastprofil“ unter Microsoft Terminal Server gemessene Leistungsspektrum erstreckt sich von 162 Benutzern (ein Xeon E7220) bis zu 272 Benutzern (vier Xeon X7350). Mit Citrix Presentation Server 4.0 liegt die Benutzeranzahl generell etwa 7% niedriger, was der Vergleich der Messungen mit dem Xeon E7220 Prozessor zeigt. Die Erklärung liegt in dem etwas höheren Ressourcenverbrauch pro Citrix Benutzer aufgrund zusätzlicher Funktionalität. Mit steigender Taktfrequenz und größerem L2Cache erhöht sich auch die Benutzeranzahl, die das System unter Terminal Server bedienen kann. Zwei Dual-Core Xeon E7220 Prozessoren liefern dabei etwas mehr Leistung als ein Quad-Core Xeon X7350 Prozessor, was durch den größeren L2-Cache des Dual-Core Prozessors zu erklären ist. Auffallend bei den Messergebnissen ist, dass in dem oberen Leistungsspektrum der Prozessoren die Leistungssteigerung durch höhere Taktfrequenz oder einen weiteren Prozessor kaum noch in eine größere Benutzeranzahl umgesetzt werden kann. Die Verdopplung der Prozessoranzahl führt nur zu einer Leistungssteigerung in einem Bereich von ca. 52% - 11% beim Hinzufügen eines zweiten Prozessors und ist bei einer Erweiterung auf vier Prozessoren noch niedriger. Das liegt zum einen daran, dass eine Steigerung beispielsweise von vier auf acht Prozessorkerne weniger effektiv ist als von zwei auf vier. Eine genauere Analyse zeigte darüber hinaus, dass bereits bei den Messungen mit zwei Quad-Core Prozessoren deren Kerne nur zu ca. 40% - 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. Deshalb wurden Messungen auf ausgewählten Prozessoren 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 insbesondere bei den Messungen mit zwei und vier Prozessoren besser ausgelastet werden konnten (ca. 60% - 80% bei zwei Prozessoren) und sich damit auch die gemessene Skalierung verbesserte, beispielsweise bei den Quad-Core Prozessoren von zwei auf vier CPUs von maximal 8% auf maximal 21%. © Fujitsu Technology Solutions 2009 Seite 39 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 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 RX600 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 RX600 S4 von 128 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-bitVersionen, denn alle Adresszeiger sind bei 64bit 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 Be(Medium Lastprofil, Microsoft Office 2003, Microsoft Terminal Services) standteil des Betriebssystems in einer 64-bitVersion vor. © Fujitsu Technology Solutions 2009 Seite 40 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 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. Resümee Das PRIMERGY System RX600 S4 ist ein leistungsfähiger und ausbaubarer Server mit bis zu 16 CPU-Kernen, der im Scale-Up-Szenario seinen optimalen Platz hat. Terminal Server Umgebungen werden in der Praxis eher als Terminal Server Farm in einem Scale-Out-Szenario auf Basis von Dual-Socket-Systemen aufgebaut, bei dem eine exzellente Skalierung durch einfaches Hinzufügen weiterer Server erreicht wird. Folgende Grafik zeigt die PRIMERGY RX600 S4 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. Die PRIMERGY RX600 S4 als High-End Serversystem kann in Verbindung mit einem 64-bit Betriebssystem mehr Benutzer bedienen als unter einem 32-bit Betriebssystem, wo die Limitierung der Kernel-Strukturen die Benutzeranzahl begrenzt. © Fujitsu Technology Solutions 2009 Seite 41 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 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 Simulationsnetzwerk 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 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 Prozessor Speicher Netzwerk-Interface Disk Subsystem Software Betriebssystem Version Netzwerkprotokoll Disk Organisation Terminal Server Software Anwendung * PRIMERGY RX600 S4 1 - 4 Xeon E7220, E7310, E7330, X7350 bis 16 GB 1 × 1-GBit LAN Intel 82575EB (onboard) 1 × SAS Controller (LSI1078) 4 × 2.5" SAS-Festplatten, 15 krpm, 2 × RAID 0 Windows Server 2003 Enterprise Edition R2 Windows Server 2003 Enterprise x64 Edition R2 Service Pack 1 (Build 1830) TCP/IP 1 Volume für das Betriebssystem 1 Volume für die Daten Microsoft Terminal Services Citrix Presentation Server 4.0 x64 Microsoft Office 2003 (32-bit) System under test (SUT) InfrastrukturServer SUTNetzwerk switched 100 MBit PRIMERGY Windows Server 2003 Enterprise Edition PRIMERGY C200 Windows Server 2003 Active Directory Terminal Server Licensing Service 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 RX100 S3 # Lastgeneratoren 20 Prozessor Pentium D 940 Memory 2 GB Netzwerk-Interface 2 × 1 GBit LAN T4US Controller- und Infrastrukturserver-Hardware Model PRIMERGY C200 Prozessor 2 × Pentium III 1.40 MHz Memory 1.5 GB Netzwerk-Interface 2 × 100 MBit LAN Software Betriebssystem Windows Server 2003 Standard Edition SP1 Netzwerkprotokoll TCP/IP RDP Client 5.2.3790.1830 ICA Client 9.00.32649, 32-bit T4US Version 3.3 T4US Lastprofil Medium Lastprofil Medium Lastprofil (2 × Word) Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. © Fujitsu Technology Solutions 2009 Seite 42 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 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 Fehler! Unbekannter Name für Dokument-Eigenschaft. 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) 2 1.5 GB Java-Applikationsserver SPECjbb (angepasst, mit 50% - 60% Last) 2 2 GB Webserver WebBench 1 1.5 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 System Under Test parallel gestartet werden müssen, um eine maximale Performance-Bewertungszahl (Score) zu erreichen. Tile Tile Tile Jedes der drei vServCon-Anwendungsszenarien ergibt für jede VM VM ein spezifisches Benchmark-Ergebnis in Form von VM VM VM Web Database Java Idle applikationsspezifischen Transaktionsraten. Um hieraus einen Score für eine gegebene Tile-Anzahl zu bilden, werden die einzelnen Benchmark-Ergebnisse in Relation zu den jeweiligen Loadgen. Ergebnissen eines definierten Referenzsystems gesetzt, einer Loadgen. Load gen. Web PRIMERGY RX300 S3. Die daraus resultierenden diWeb Web mensionslosen Performance-Werte werden dann unter Berücksichtigung der Anzahl der virtuellen CPUs und der MemoryGröße gewichtet und über alle VMs und Tiles aufsummiert. Das Framework Controller Ergebnis ist der vServCon-Score für die betrachtete Tile-Anzahl. 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), MemoryVerbrauch und Leistungsaufnahme dokumentiert. Der Score soll eine virtualisierungs-spezifische 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. © Fujitsu Technology Solutions 2009 Seite 43 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Benchmark-Ergebnisse Die PRIMERGY RX600 S4 ist durch ihre vielfältige Ausbaufähigkeit auf bis zu 24 Prozessorkerne, 128 GB Hauptspeicher und sieben freie I/O-Steckplätze besonders für höhere Anzahlen von Anwendungs-VMs geeignet. So ist z. B. auf Basis des zuvor beschriebenen vServCon-Profils bei Vollausbau mit vier Xeon X7460 Prozessoren durch 18 echte Anwendungs-VMs (entsprechend sechs Tiles) eine nahezu optimale Auslastung der CPU-Ressourcen des Systems möglich. Das erste Diagramm veranschaulicht dies für die PRIMERGY RX600 S4 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 Xeon E7430 Prozessor allein durch die Verdreifachung der Anzahl der echten Anwendungs-VMs von 3 auf 9 die Virtualisierungs-Performance um 162% steigern, während gleichzeitig die elektrische Leistungsaufnahme nur um ca. 14% 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 44 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Im Vorangegangenen wurde die Virtualisierungs-Performance des Systems in Gänze betrachtet. 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 Xeon X7460 betrachtet. Wenn die Anzahl der AnwendungsVMs 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 VMAnzahlen. Die jeweils erste Säule einer Gruppe betrachtet eine VM im Verbund von insgesamt drei Anwendungs-VMs (1 Tile), die jeweils zweite im Verbund von 6 Anwendungs-VMs (2 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 GesamtOptimums 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. Jenseits des Optimums bricht die Performance der DB-VM 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. 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. 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 CGIProgramme (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 ähnlichen 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 nebenstehende Diagramm für einen unmodifizierten Linux-Kernel in der VM. Die beiden verglichenen Lastprofile sind: Lastprofile für Webserver STD-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. MIN-CGI 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. © Fujitsu Technology Solutions 2009 Seite 45 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Der zweite Optimierungsweg setzt unterhalb der Anwendungsebene in der VM an. Prinzipiell möglich sind PerformanceSteigerungen 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. 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 Performance-Vergleich einer einzeln vermessenen Webserver-VM mit 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 wurde. 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 RX600 S4 freigegebenen Prozessoren liegen die prozentualen Performance-Abstände zwischen den Kerneln im Bereich 64% - 72%. 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. Wählt man beide Optimierungswege, so profitiert man von beiden Effekten und erzielt die bestmögliche Performance. © Fujitsu Technology Solutions 2009 Seite 46 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Benchmark-Umgebung* Die Messungen wurden mit der im Folgenden beschriebenen Umgebung durchgeführt: Fehler! Unbekannter Name für Dokument-Eigenschaft. Benchmark Environment System under Test (SUT) 1 GBit LAN Tile n … VM Web VM Database VM Java VM Idle VM Web VM Database VM Java VM Idle Tile 1 1 GBit LAN Fehler! Unbekannter Name für DokumentEigenschaft. Framework Controller Disk-Subsystem FibreCAT CX500 Load generator BX600 SUT-Hardware Modell PRIMERGY RX600 S4 Prozessor 4 × Xeon E7330 (2.40 GHz) 4 × Xeon X7350 (2.93 GHz) 4 × Xeon E7430 (2.13 GHz) 4 × Xeon E7450 (2.40 GHz) 4 × Xeon X7460 (2.67 GHz) Speicher 32 GB 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 ST373454Disks (15 krpm) Storage-Anbindung Über FC-Controller Qlogic QLE 2460 SUT-Software Betriebssystem Version BIOS Hypervisor VMware ESX Server. Für Hexa-Core Prozessoren: Vmkernel.Boot.cpuCellSize = 6 (*) Version 3.5.0 build 110268, Update 2 Version 1.16A; Default-Einstellungen SUT: Virtualisierungsspezifisches Webserver-VM-Kernel SLES10 SP2, 32-bit, 2.6.16.60-0.23-smp original Webserver-VM-Kernel SLES10 SP2, 32-bit, 2.6.16.60-0.23-vmi angepasst (Kernel mit VMware-VMI-Interface) Generelles 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 (*) Performance-relevant, siehe: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1007361 * Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. © Fujitsu Technology Solutions 2009 Seite 47 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Literatur PRIMERGY Systems http://de.ts.fujitsu.com/primergy PRIMERGY RX600 S4 Datenblatt http://docs.ts.fujitsu.com/dl.aspx?id=0f5f9d85-529f-460c-8877-feab81341e76 PRIMERGY Performance http://de.ts.fujitsu.com/products/standard_servers/primergy_bov.html OLTP-2 Benchmark Überblick OLTP-2 http://docs.ts.fujitsu.com/dl.aspx?id=743d7d46-56e8-41d2-9d50-9ab29ccf4d18 http://www.sap.com/benchmark SAP SD Benchmark Überblick SAP SD http://docs.ts.fujitsu.com/dl.aspx?id=ae039b1d-73d8-4946-ae60-08dcef54cfa8 http://www.spec.org/osg/cpu2006 SPECcpu2006 Benchmark Überblick SPECcpu2006 http://docs.ts.fujitsu.com/dl.aspx?id=04351fd2-8a69-42a3-ba1c-4342dcc89b89 http://www.spec.org/jbb2005 SPECjbb2005 Benchmark Überblick SPECjbb2005 http://docs.ts.fujitsu.com/dl.aspx?id=e8477909-3a17-40dd-8c64-ff338b6457a0 http://www.spec.org/web2005 SPECweb2005 StorageBench Benchmark Überblick SPECweb2005 http://docs.ts.fujitsu.com/dl.aspx?id=e8d3b50b-04c5-4bcd-b076-2b24dd0757ee Performance Report – Modular RAID für PRIMERGY http://docs.ts.fujitsu.com/dl.aspx?id=2d0d20d8-7c14-407c-b904-6112f4c7821c http://www.iometer.org Terminal Server Sizing Guide (DE) http://docs.ts.fujitsu.com/dl.aspx?id=278825c9-7644-49c1-9848-f2a5c8c694cd Terminal Server Sizing Guide - 64-bit Technologie (DE) http://docs.ts.fujitsu.com/dl.aspx?id=5216e667-a708-414f-b486-a39fb56a07c1 Terminal Server Microsoft Windows 2003 und Terminal Services http://www.microsoft.com/terminalserver Citrix http://www.citrix.de http://www.tpc.org/tpce TPC-E vServCon Benchmark Überblick TPC-E http://docs.ts.fujitsu.com/dl.aspx?id=08c95eef-5f18-4453-bed6-cbf9363f4e2f Benchmark Überblick vServCon http://docs.ts.fujitsu.com/dl.aspx?id=214ee9dc-9239-4985-86e4-f0f9ac78ea25 © Fujitsu Technology Solutions 2009 Seite 48 (49) White Paper Performance Report PRIMERGY RX600 S4 Version: 2.2b, November 2009 Kontakt PRIMERGY Hardware PRIMERGY Product Marketing mailto:[email protected] PRIMERGY Performance und Benchmarks PRIMERGY Performance und Benchmarks mailto:[email protected] Lieferung vorbehaltlich Verfügbarkeit, technische Änderungen ohne Vorankündigung möglich, Korrektur von Irrtümern und Auslassungen vorbehalten. Alle angegebenen Konditionen (TCs) sind empfohlene Einstandspreise in Euro ohne MwSt. (sofern im Text nicht anderweitig angegeben). Sämtliche verwendete Hardware- und Software- Namen sind Handelsnamen und/oder Warenzeichen ihrer jeweiligen Hersteller. Copyright © Fujitsu Technology Solutions GmbH 2009 Herausgegeben durch: Internet: http://ts.fujitsu.com/primergy Enterprise Products PRIMERGY Server PRIMERGY Performance Lab mailto:[email protected] Extranet: http://partners.ts.fujitsu.com/com/products/serv ers/primergy
