Performance Report PRIMERGY RX200 S5 - …DE).pdf · Performance Report PRIMERGY RX200 S5 . ... und...

Abstract

In diesem Dokument sind alle Benchmarks, die für die PRIMERGY RX200 S5 durchgeführt wurden, zusam-mengefasst.

Ferner werden die Leistungsdaten der PRIMERGY RX200 S5 mit denen anderer PRIMERGY Modelle ver-glichen und diskutiert. Neben den Benchmark-Ergebnissen als solchen wird jeder Benchmark und die Um-gebung, in der der Benchmark durchgeführt wurde, kurz erläutert.

Inhalt Dokumenthistorie .................................................................................................................................... 2

Technische Daten ................................................................................................................................... 3

SPECcpu2006 ........................................................................................................................................ 4

SPECjbb2005 ....................................................................................................................................... 12

StorageBench ....................................................................................................................................... 15

OLTP-2 ................................................................................................................................................. 21

Terminal Server .................................................................................................................................... 25

VMmark................................................................................................................................................. 30

vServCon .............................................................................................................................................. 33

Literatur ................................................................................................................................................. 39

Kontakt .................................................................................................................................................. 40

Version 2.0a März 2010

Seiten 40

Performance Report

PRIMERGY RX200 S5

White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010

© Fujitsu Technology Solutions 2009-2010 Seite 2 (40)

Dokumenthistorie

Version 1.0

Erste Reportversion mit den Benchmark-Kapiteln

SPECcpu2006 Messungen mit Xeon E5502, E5504, E5506, E5520, E5540, X5550 und X5570

SPECjbb2005 Messung mit Xeon X5570

StorageBench Messungen mit LSI MegaRAID SAS 1064/1068 Controller Messungen mit LSI MegaRAID SAS 1078 Controller

OLTP-2 Messungen mit Xeon E5502, E5504, E5506, E5520, E5540, X5550 und X5570

Version 1.1

Neue Benchmark-Kapitel:

Terminal Server Messungen mit Xeon E5504 und X5570

Version 1.2


vServCon Messungen mit Xeon L5520, E5520, E5540, X5550 und X5570

Geänderte Benchmark-Kapitel:

Technische Daten, StorageBench, OLTP-2, Literatur (Korrekturen) Version 2.0

in allen Benchmark-Kapiteln: zusätzliche Fußnote zur Verfügbarkeit von Komponenten

Überarbeitete Benchmark-Kapitel:

SPECcpu2006 Messungen mit Xeon L5530, E5530 und X5560 Zusätzliche Messungen mit Xeon E5502, E5504, E5506, E5520, E5540, X5550 und X5570

SPECjbb2005: Messung mit Oracle JRockit(R) 6 P28.0.0 (build P28.0.0-29-114096-1.6.0_11-20090427-1759-windows-x86_64)

OLTP-2 Werte für Xeon L5530, E5530 und X5560

StorageBench (Korrekturen)

vServCon (Korrekturen, aktualisierte Grafiken)


VMmark Version 2.0a

Überarbeitete Benchmark-Kapitel:

SPECcpu2006 Tabellenformatierung geändert

SPECjbb2005 (Korrekturen)

StorageBench (Korrekturen)

OLTP-2 (Korrekturen)

Terminal Server (Literatur)

VMmark (Korrekturen)

vServCon (Korrekturen)



Technische Daten

Die PRIMERGY RX200 S5 ist ein mit nur einer Höheneinheit besonders Platz sparender Dual-Socket Rack-Server, der die PRIMERGY RX200 S4 ablöst. Sie besitzt einen Intel 5500 Chipsatz, zwei Intel Dual-Core oder Quad-Core Xeon Prozessoren, bis zu 96 GB PC3-10600 oder PC3-8500 registered ECC DDR3-SDRAM oder bis zu 24 GB PC3-8500 unbuffered ECC DDR3-SDRAM, einen abhängig vom verwendeten Prozessor mit 800, 1067 oder 1333 MHz getakteten Bus, einen onboard 2-Port SATA-Controller mit RAID 0 und RAID 1, einen SAS-Controller mit RAID 0 und RAID 1 oder einen SAS-Controller mit RAID 5 und RAID 6 für bis zu acht interne SATA- oder SAS-Festplatten, einen onboard 2-Port 1-GBit Ethernet-Controller und drei PCI-Steckplätze (2 mal PCIe-2 x8 und 1 mal PCIe-2 x4).

Detaillierte technische Informationen finden Sie im Datenblatt PRIMERGY RX200 S5.

http://docs.ts.fujitsu.com/dl.aspx?id=c2be12e9-8512-4f72-8d12-805d2dc1c6d2



SPECcpu2006

Benchmark-Beschreibung

SPECcpu2006 ist ein Benchmark, der die Systemeffizienz bei Integer- und Fließkomma-Operationen misst. Er besteht aus einer Integer-Testsuite (SPECint2006), die 12 Applikationen enthält, und einer Fließkomma-Testsuite (SPECfp2006), die 17 Applikationen enthält. Beide Testsuiten sind extrem rechenintensiv und konzentrieren sich auf die CPU und den Speicher. Andere Komponenten, wie Disk-I/O und Netzwerk, werden von diesem Benchmark nicht vermessen.

SPECcpu2006 ist nicht an ein spezielles Betriebssystem gebunden. Der Benchmark ist als Source-Code verfügbar und wird vor der eigentlichen Messung kompiliert. Daher beeinflussen auch die verwendete Compiler-Version und deren Optimierungseinstellungen das Messergebnis.

SPECcpu2006 beinhaltet zwei verschiedene Methoden der Performance-Messung: Die erste Methode (SPECint2006 bzw. SPECfp2006) ermittelt die Zeit, die für die Bearbeitung einer einzelnen Aufgabe benötigt wird. Die zweite Methode (SPECint_rate2006 bzw. SPECfp_rate2006) ermittelt den Durchsatz, d.h. wie viele Aufgaben parallel erledigt werden können. Beide Methoden werden zusätzlich noch in zwei Messläufe unterteilt, „base“ und „peak“, die sich in der Verwendung der Compiler-Optimierung unterscheiden. Bei der Publikation von Ergebnissen werden immer „base“-Werte verwendet, „peak“-Werte sind optional.

Benchmark Arithmetik Typ Compiler-Optimierung

Messergebnis Anwendung

SPECint2006 Integer peak aggressiv Geschwindigkeit Singlethreaded

SPECint_base2006 Integer base konservativ

SPECint_rate2006 Integer peak aggressiv Durchsatz Multithreaded

SPECint_rate_base2006 Integer base konservativ

SPECfp2006 Fließkomma peak aggressiv Geschwindigkeit Singlethreaded

SPECfp_base2006 Fließkomma base konservativ

SPECfp_rate2006 Fließkomma peak aggressiv Durchsatz Multithreaded

SPECfp_rate_base2006 Fließkomma base konservativ

Bei den Messergebnissen handelt es sich um das geometrische Mittel aus normalisierten Verhältniswerten, die für die Einzel-Benchmarks ermittelt wurden. Das geometrische Mittel führt gegenüber dem arithmetischen Mittel dazu, dass bei unterschiedlich hohen Einzelergebnissen eine Gewichtung zugunsten der niedrigeren Einzelergebnisse erfolgt. Normalisiert heißt, dass gemessen wird, wie schnell das Testsystem verglichen mit einem Referenzsystem ist. Der Wert „1“ wurde für die SPECint_base2006-, SPECint_rate_base2006, SPECfp_base2006 und SPECfp_rate_base2006-Ergebnisse des Referenzsystems festgelegt. So bedeutet beispielsweise ein SPECint_base2006-Wert von 2, dass das Messsystem diesen Benchmark etwa doppelt so schnell wie das Referenzsystem bewältigt hat. Ein SPECfp_rate_base2006-Wert von 4 bedeutet, dass das Messsystem diesen Benchmark etwa 4/[# base copies] mal so schnell wie das Referenzsystem bewältigt hat. „# base copies“ gibt hierbei an, wie viele parallele Instanzen des Benchmarks ausgeführt worden sind.

Nicht alle SPECcpu2006-Messungen werden von uns zur Veröffentlichung bei SPEC eingereicht. Daher erscheinen auch nicht alle Ergebnisse auf den Web-Seiten von SPEC. Da wir für alle Messungen die Protokolldateien archivieren, können wir jederzeit den Nachweis für die korrekte Durchführung der Messungen erbringen.

Benchmark-Ergebnisse

Die PRIMERGY RX200 S5 wurde mit den Prozessoren Xeon E5502, E5504, L5506, E5506, L5520, E5520, L5530, E5530, E5540, X5550, X5560 und X5570 vermessen. Die Benchmark-Programme wurden mit dem Intel C++/Fortran-Compiler 11.0 kompiliert und unter SUSE Linux Enterprise Server 10 SP2 (64-bit)

SPEC®, SPECint®, SPECfp® und das SPEC-Logo sind eingetragene Warenzeichen der Standard

Performance Evaluation Corporation (SPEC).



ausgeführt. In den folgenden Tabellen sind alle fett gedruckten Ergebnisse veröffentlicht bei http://www.spec.org. Die mit „(est.)“ gekennzeichneten Ergebnisse sind Schätzwerte.

Prozessor Cores GHz L3-Cache Bus TDP SPECint_base2006

2 Chips SPECint2006

2 Chips

Xeon E5502 2 1.87 4 MB 800 MHz 80 Watt 18.0 20.0

Xeon E5504 4 2 4 MB 800 MHz 80 Watt 19.3 21.4

Xeon L5506 4 2.13 4 MB 800 MHz 60 Watt 20.4 (est.) 22.6 (est.)

Xeon E5506 4 2.13 4 MB 800 MHz 80 Watt 20.4 22.6


Xeon E5520 4 2.27 8 MB 1067 MHz 80 Watt 24.3 27.0


Xeon E5530 4 2.40 8 MB 1067 MHz 80 Watt 25.7 28.7

Xeon E5540 4 2.53 8 MB 1067 MHz 80 Watt 26.9 29.8

Xeon X5550 4 2.67 8 MB 1333 MHz 95 Watt 29.6 33.0

Xeon X5560 4 2.80 8 MB 1333 MHz 95 Watt 30.5 34.2

Xeon X5570 4 2.93 8 MB 1333 MHz 95 Watt 31.8 35.3

http://www.spec.org/



Prozessor Cores GHz L3-Cache Bus TDP

SPECint_rate_base2006 SPECint_rate2006

1 Chip 2 Chips 1 Chip 2 Chips

Xeon E5502 2 1.87 4 MB 800 MHz 80 Watt 33.6 66.2 36.2 71.3

Xeon E5504 4 2 4 MB 800 MHz 80 Watt 65.1 126 69.7 136

Xeon L5506 4 2.13 4 MB 800 MHz 60 Watt 68.1 (est.) 132 72.9 (est.) 141

Xeon E5506 4 2.13 4 MB 800 MHz 80 Watt 68.1 132 72.9 141

Xeon L5520 4 2.27 8 MB 1067 MHz 60 Watt 95.8 (est.) 184 103 (est.) 199

Xeon E5520 4 2.27 8 MB 1067 MHz 80 Watt 95.8 186 103 201

Xeon L5530 4 2.40 8 MB 1067 MHz 60 Watt 99.6 (est.) 193 107 (est.) 208

Xeon E5530 4 2.40 8 MB 1067 MHz 80 Watt 99.6 193 107 209

Xeon E5540 4 2.53 8 MB 1067 MHz 80 Watt 103 198 111 214

Xeon X5550 4 2.67 8 MB 1333 MHz 95 Watt 111 221 120 237

Xeon X5560 4 2.80 8 MB 1333 MHz 95 Watt 116 230 125 248

Xeon X5570 4 2.93 8 MB 1333 MHz 95 Watt 118 236 127 254



Prozessor Cores GHz L3-Cache Bus TDP SPECfp_base2006

2 Chips SPECfp2006

2 Chips

Xeon E5502 2 1.87 4 MB 800 MHz 80 Watt 21.6 23.1

Xeon E5504 4 2 4 MB 800 MHz 80 Watt 23.4 25.1


Xeon E5506 4 2.13 4 MB 800 MHz 80 Watt 24.7 26.2


Xeon E5520 4 2.27 8 MB 1067 MHz 80 Watt 29.7 31.4


Xeon E5530 4 2.40 8 MB 1067 MHz 80 Watt 30.9 32.9

Xeon E5540 4 2.53 8 MB 1067 MHz 80 Watt 32.1 34.1

Xeon X5550 4 2.67 8 MB 1333 MHz 95 Watt 35.8 38.1

Xeon X5560 4 2.80 8 MB 1333 MHz 95 Watt 36.7 39.1

Xeon X5570 4 2.93 8 MB 1333 MHz 95 Watt 37.4 40.1



Prozessor Cores GHz L3-Cache Bus TDP

SPECfp_rate_base2006 SPECfp_rate2006

1 Chip 2 Chips 1 Chip 2 Chips

Xeon E5502 2 1.87 4 MB 800 MHz 80 Watt 35.1 68.2 36.4 70.9

Xeon E5504 4 2 4 MB 800 MHz 80 Watt 57.6 111 59.5 116


Xeon E5506 4 2.13 4 MB 800 MHz 80 Watt 59.3 115 61.5 119


Xeon E5520 4 2.27 8 MB 1067 MHz 80 Watt 79.9 155 82.9 161


Xeon E5530 4 2.40 8 MB 1067 MHz 80 Watt 82.4 159 85.1 165

Xeon E5540 4 2.53 8 MB 1067 MHz 80 Watt 83.2 161 86.4 167

Xeon X5550 4 2.67 8 MB 1333 MHz 95 Watt 93.0 181 96.3 189

Xeon X5560 4 2.80 8 MB 1333 MHz 95 Watt 96.1 186 99.3 194

Xeon X5570 4 2.93 8 MB 1333 MHz 95 Watt 96.9 189 101 197



Der Durchsatz mit zwei Prozessoren ist sowohl bei der Integer- als auch bei der Floating-Point-Testsuite etwa doppelt so groß wie der mit einem Prozessor.



Die folgenden Grafiken verdeutlichen den Durchsatz der PRIMERGY RX200 S5 im Vergleich zu ihrem Vorgänger, der PRIMERGY RX200 S4, in jeweils performantester Ausstattung.



Benchmark-Umgebung

Alle SPECcpu2006-Messungen wurden auf einer PRIMERGY RX200 S5 mit folgender Hard- und Software-Ausstattung vorgenommen:

Hardware

Modell PRIMERGY RX200 S5

CPU Xeon E5502, E5504, L5506, E5506, L5520, E5520, L5530, E5530, E5540,

X5550, X5560 und X5570

Anzahl CPUs

1 Chip: Xeon E5502: 2 Cores, 2 Cores/Chip alle anderen: 4 Cores, 4 Cores/Chip

2 Chips: Xeon E5502: 4 Cores, 2 Cores/Chip alle anderen: 8 Cores, 4 Cores/Chip

Primary Cache 32 KB instruction + 32 KB data on chip, pro Core

Secondary Cache 256 kB on chip, pro Core

Other Cache Xeon E5502, E5504, L5506 und E5506: 4 MB (I+D) on chip, pro Chip alle anderen: 8 MB (I+D) on chip, pro Chip

Software

Betriebssystem SUSE Linux Enterprise Server 10 SP2 (64-bit)

Compiler Intel C++/Fortran Compiler 11.0

Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar.



SPECjbb2005


SPECjbb2005 ist ein Java Business Benchmark, dessen Fokus auf der Leistung von Java Server Plattformen liegt. Im Wesentlichen ist SPECjbb2005 ein modernisierter SPECjbb2000. Die Hauptunterschiede sind:

Die Transaktionen sind komplexer geworden, um einen größeren Bereich an Funktionalität abzudecken.

Der Working Set des Benchmarks ist vergrößert worden, so dass die Systemlast insgesamt gestiegen ist.

SPECjbb2000 erlaubt nur eine aktive Java Virtual Machine Instanz (JVM), während SPECjbb2005 mehrere Instanzen zulässt, was eine größere Realitätsnähe insbesondere bei großen Systemen bewirkt.

Softwareseitig misst SPECjbb2005 die Effizienz der Implementierungen der JVM, Just-In-Time (JIT) Compilers, Garbage Collection, Threads sowie einige Aspekte des Betriebssystems. Hardwareseitig wird die Effizienz der CPUs und Caches, des Speichersubsystems und die Skalierbarkeit von Shared Memory Systemen (SMP) gemessen. Disk- und Netzwerk-I/O spielen keine Rolle.

SPECjbb2005 emuliert ein für moderne Geschäftsprozess-Applikationen typisches Three-Tier Client/Server System mit Augenmerk auf das Middle-Tier System:

Clients erzeugen die Last, bestehend aus Driver Threads, die angelehnt an den TPC-C Benchmark OLTP Zugriffe auf eine Datenbank ohne Denkzeiten generieren.

Das Middle-Tier System implementiert die Geschäftsprozesse und Aktualisierung der Datenbank.

Die Datenbank übernimmt die Datenverwaltung und wird emuliert durch Java-Objekte, die im Memory liegen. Transaktions-Logging ist implementiert auf XML Basis.

Der große Vorteil dieses Benchmarks ist, dass er alle drei Tiers beinhaltet, die gemeinsam auf einem Single-Host laufen. Gemessen wird die Performance des Middle-Tier. So werden große Hardware-Installationen vermieden und direkte Vergleiche von SPECjbb2005-Ergebnissen unterschiedlicher Systeme sind möglich. Client- und Datenbank-Emulation sind ebenfalls in Java geschrieben.

SPECjbb2005 benötigt nur das Betriebssystem sowie eine Java Virtual Machine mit J2SE 5.0 Eigenschaften.

Die Skalierungseinheit ist ein Warenhaus mit ca. 25 MB Java Objekten. Genau ein Java-Thread pro Warenhaus führt die Operationen auf diesen Objekten aus. Die Geschäftsoperationen sind von TPC-C übernommen:

New Order Entry

Payment

Order Status Inquiry

Delivery

Stock Level Supervision

Customer Report

Das sind aber auch die einzigen Gemeinsamkeiten von SPECjbb2005 und TPC-C. Die Ergebnisse beider Benchmarks sind nicht vergleichbar.

SPECjbb2005 besitzt 2 Performance-Metriken:

bops (business operations per second) ist die Gesamtrate aller Geschäftsoperationen, die pro Sekunde durchgeführt werden.

bops/JVM ist der Quotient der ersten Metrik und der Anzahl der aktiven JVM Instanzen.

In Vergleichen verschiedener SPECjbb2005-Ergebnisse müssen beide Metriken angegeben werden.

SPEC®, SPECjbb® und das SPEC-Logo sind eingetragene Warenzeichen der Standard Performance

Evaluation Corporation (SPEC).



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.


Im März 2009 wurde die PRIMERGY RX200 S5 mit zwei Xeon X5570 Prozessoren bei einem Speicherausbau mit 24 GB PC3-10600R DDR3-SDRAM vermessen. Die Messung wurde unter Windows Server 2008 Enterprise x64 Edition durchgeführt. Als JVM wurden zwei Instanzen von JRockit(R) 6 P28.0.0 (build P28.0.0-14-111048-1.6.0_05-20090303-1104-windows-x86_64) von Oracle verwendet. Bei der Messung flossen alle Messwerte von 8 bis 16 Warenhäusern in das Benchmark-Ergebnis ein.

Im August 2009 wurde die PRIMERGY RX200 S5 in gleicher Hardware-Konfiguration, aber anderer Software-Konfiguration vermessen. Die Messung wurde unter Windows Server 2008 Enterprise x64 Edition SP2 durchgeführt. Als JVM wurden vier Instanzen von JRockit(R) 6 P28.0.0 (build P28.0.0-29-114096-1.6.0_11-20090427-1759-windows-x86_64) von Oracle verwendet. Bei der Messung flossen alle Messwerte von 4 bis 8 Warenhäusern in das Benchmark-Ergebnis ein.



Vergleicht man die PRIMERGY RX200 S5 mit ihrem Vorgänger, der PRIMERGY RX200 S4, in jeweils performantester Ausstattung, so ergibt sich eine Durchsatzsteigerung von +55%.

Benchmark-Umgebung

Die SPECjbb2005-Messungen wurden auf einer PRIMERGY RX200 S5 mit folgender Hard- und Software-Ausstattung durchgeführt:

Messung vom März 2009

Hardware


CPU Xeon X5570

Anzahl Chips 2 Chips, 8 Cores, 4 Cores pro Chip

Primary Cache 32 kB instruction + 32 kB data on chip, pro Core

Secondary Cache ¼ MB (I+D) on chip, pro Core

Other Cache 8 MB (I+D) on chip, pro Chip

Memory 6 x 4 GB PC3-10600R DDR3-SDRAM

Software

Betriebssystem Windows Server 2008 Enterprise x64 Edition

JVM Version Oracle JRockit(R) 6 P28.0.0 (build P28.0.0-14-111048-1.6.0_05-20090303-1104-windows-x86_64)

Messung vom August 2009

Hardware

wie im März 2009

Software

Betriebssystem Windows Server 2008 Enterprise x64 Edition SP2

JVM Version Oracle JRockit(R) 6 P28.0.0 (build P28.0.0-29-114096-1.6.0_11-20090427-1759-windows-x86_64)




StorageBench


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. Zusätzlich lässt sich die Anzahl simultaner Zugriffe (»Outstanding IOs«) einstellen. 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 Block-größe

Outstanding IOs

Last-Tool

read write

Streaming sequentiell 100% 64 KB 3 Iometer

Restore sequentiell 100% 64 KB 3 Iometer

Database random 67% 33% 8 KB 3 Iometer

File-Server random 67% 33% 64 KB 3 Iometer

Alle vier Profile wurden mit Iometer generiert.

http://sourceforge.net/

http://www.iometer.org/

http://sourceforge.net/projects/iometer



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.

http://docs.ts.fujitsu.com/dl.aspx?id=2d0d20d8-7c14-407c-b904-6112f4c7821c





Die PRIMERGY RX200 S5 ist mit den Controllern der »Modular RAID« Familie ausgestattet. Die Vielfalt der RAID-Lösungen ermöglicht dem Anwender, den passenden Controller für sein Anwendungsszenario zu wählen.

Die PRIMERGY RX200 S5 bietet folgende RAID-Lösungen an:

1. RAID-Controller LSI MegaRAID SAS 1064/1068

Der Controller wird als PCI-Express-Karte geliefert. Es werden die RAID-Levels 0, 1 und 1E unterstützt. Dieser Controller-Typ hat keinen Cache. Die maximale Anzahl der Festplatten, die man an den Controller LSI MegaRAID SAS 1064 anschließen kann, ist vier, während der LSI MegaRAID SAS 1068 Controller acht Ports für bis zu acht Festplatten bietet.

2. RAID-Controller LSI MegaRAID SAS 1078

Der Controller wird als PCI-Express-Karte geliefert und bietet dem Anwender eine komplette RAID-Lösung. Es werden die RAID-Levels 0, 1, 5, 6, 10, 50 und 60 unterstützt. Es werden zwei unterschiedliche Versionen dieses Controllers mit entweder 256 MB oder 512 MB 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 diese Controller können unterschiedliche Festplatten angeschlossen werden. In Abhängigkeit von der benötigten Performance kann das Disk-Subsystem passend ausgewählt werden. Die PRIMERGY RX200 S5 bietet je nach Modellvariante bis zu acht hot-plug Einschübe für 2½" SAS-Festplatten.

Für die PRIMERGY RX200 S5 stehen folgende Festplatten zur Auswahl:

2½" SAS Festplatten mit einer Kapazität von 73 GB und 146 GB (10 krpm)

2½" SAS Festplatten mit einer Kapazität von 36 GB und 73 GB (15 krpm)

LSI MegaRAID SAS 1064/1068

Im Folgenden wird die Leistung der verfügbaren Festplattentypen am LSI MegaRAID SAS 1068 Controller verglichen. Die Ergebnisse sind auf den LSI MegaRAID SAS 1064 Controller übertragbar.

Dieser Controller hat keinen Controller-Cache. Deshalb wurden bei den Messungen nur die Auswirkungen der Disk-Cache-Parameter untersucht und die Messungen wurden jeweils mit und ohne Disk-Cache durchgeführt.

Der Cache der Festplatten hat Einfluss auf die Disk-I/O-Performance. Er wird häufig als Sicherheitsproblem bei Stromausfall angesehen und daher abgeschaltet. Dennoch wurde er von den Festplattenherstellern aus gutem Grund zur Steigerung der Schreib-Performance integriert. Der weitaus größere Cache für I/O-Zugriffe und damit ein potentielles Sicherheitsrisiko für Datenverluste bei Stromausfall befindet sich im Arbeitsspeicher und wird vom Betriebssystem verwaltet. Um Datenverlusten vorzubeugen, empfiehlt es sich, das System mit einer USV auszustatten.

Im Testaufbau wurden zwei Festplatten an den Controller angeschlossen und als RAID 1 konfiguriert. Bei den Messungen wurden alle heute für die PRIMERGY RX200 S5 verfügbaren Festplattentypen untersucht. Im Folgenden werden die Durchsätze der einzelnen Festplattentypen im RAID 1 bei unterschiedlichen Zugriffsmustern verglichen.

Die Grafik zeigt, dass der Durchsatz beim sequentiellen Lesen und Schreiben mit 64 KB Blockgröße mit steigender Umdrehungsgeschwindigkeit steigt.

Wird beim sequentiellen Lesen statt einer Festplatte mit einer Umdrehungsgeschwindigkeit von 10 krpm eine Festplatte mit 15 krpm verwendet, ergibt sich eine Durchsatzsteigerung von etwa 19%.

Verwendet man beim sequentiellen Schreiben und eingeschaltetem Disk-Cache statt einer Festplatte mit einer Umdrehungsgeschwindigkeit von 10 krpm eine Festplatte mit 15 krpm, führt dieses zu einer Durch-satzsteigerung von etwa 21%. Wenn der Disk-Cache nicht eingeschaltet ist, beträgt die Steigerung sogar 52%.

LSI MegaRAID SAS 1068



Eine relevante Durchsatzsteigerung beim sequentiellen Schreiben kann man, wie im Diagramm oben zu sehen ist, durch das Einschalten des Disk-Cache erreichen: bei den Festplatten mit 10 krpm steigt der Durchsatz um ca. 84% und bei den Festplatten mit 15 krpm steigt der Durchsatz um etwa 46%.

Die folgende Grafik zeigt, dass auch bei wahlfreiem Zugriff mit 67% Leseanteil der Disk-Cache eine wichtige Rolle bei der Verbesserung des Durchsatzes spielt. Die Durchsatzsteigerung durch das Einschalten des Disk-Cache liegt etwa bei 23%.

Auch beim wahlfreien Zugriff zeigt die schneller drehende Festplatte eine bessere Leistung, die Umdrehungsgeschwindigkeit von 15 krpm macht sich in einem Performance-Gewinn von etwas über 22% bemerkbar.


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 wesentlich vom Datendurchsatz der Festplatten ab. Abhängig vom RAID-Level wurde die Anzahl der Festplatten festgelegt, die für die Messungen in einem RAID-Verband konfiguriert wurden. Es wurden zwei und drei Festplatten verwendet. Damit die Festplatten keinen Engpass bei der Ermittlung der Leistungsfähigkeit des Controllers unter verschiedenen Cache-Einstellungen darstellen, wurden die Messungen mit Festplatten mit einer Umdrehungszahl von 15 krpm durchgeführt.

Der Durchsatz der Festplatten lässt sich durch die Anpassung der Controller-Cache-Einstellungen in bestimmten Fällen erheblich erhöhen. Die Durchsatzsteigerungen fallen allerdings je nach Datenstruktur und Zugriffsmuster unterschiedlich aus. Bei den Messungen wurde die Controller-Cache-Option »Read-Mode« immer auf »No Read-ahead« und die Option »I/O cache« auf »I/O direct« gesetzt. Die Optionen »Write-Mode« und »Disk cache« wurden variiert.

Die folgende Grafik stellt die Durchsätze beim sequentiellen Lesen und Schreiben mit 64 KB Blöcken und bei unterschiedlichen Cache-Einstellungen im RAID 1 mit zwei und im RAID 5 mit drei 2½" SAS-Festplatten dar.

Der Lesedurchsatz liegt etwa im Bereich des maximal möglichen Durchsatzes von etwas über 100 MB/s beim RAID 1 und 200 MB/s beim RAID 5.

Der Schreibdurchsatz dagegen hängt von den Cache-Einstellungen ab. Um die Leistung bei RAID 1 zu maximieren, ist es notwendig, die Option »Disk cache enabled« als optimale Cache-Einstellung zu verwenden. In unserem Fall hat sich der Durchsatz damit etwa um den Faktor 1.7 beim sequentiellen Schreiben verbessert.

Dass die optimalen Cache-Einstellungen für eine verbesserte Performance wichtig sind, ist bei RAID 5 besonders deutlich zu sehen. Die Grafik zeigt, dass der sequentielle Schreibdurchsatz durch das Einschalten des Controller-Cache mit der Option »Write-back« und des Disk-Cache mit der Option »enabled« erheblich, um den Faktor 22, steigt.


LSI MegaRAID SAS 1078 mit 512 MB Cache



Um mit RAID 1 einen optimalen Durchsatz beim wahlfreien Zugriff zu erreichen, ist es wichtig, die Write-Mode-Option des Controller-Cache auf »Write-through« zu setzen und den Disk-Cache der Festplatte einzuschalten. Durch diese optimalen Cache-Einstellungen werden Durchsatzverbesserungen von 19% und 14% erreicht, je nachdem, ob man beim wahlfreien Zugriff 8 KB oder 64 KB große Blöcke verwendet.

Um mit RAID 5 einen optimalen Durchsatz beim wahlfreien Zugriff zu erreichen, ist es wichtig, die Write-Mode-Option des Controller-Cache auf »Write-back« zu setzen und den Disk-Cache der Festplatte einzuschalten. Durch diese optimalen Cache-Einstellungen werden Durchsatz-verbesserungen von 56% und 47% erreicht, je nach Blockgröße.

Umfangreichere Informationen zu diesem Thema sind im Papier Performance Report - Modular RAID für PRIMERGY zu finden.

Controller-Vergleich

Bei der folgenden Gegenüberstellung werden die Durchsätze der unterschiedlichen Controller verglichen. Die Messungen erfolgten jeweils mit den gleichen Festplattentypen in dem gleichen RAID 1-Verband. Die Grafik zeigt die Durchsätze, die bei ausgeschalteten Caches (Off) und bei den optimalen Cache-Einstellungen (Optimal) erreicht wurden.

Die Leistungsunterschiede der verwendeten Controller sind beim rein sequentiellen Zugriff und optimalen Cache-Einstellungen minimal. Beim sequentiellen Lesen erreichen alle Controller unabhängig von den Cache-Einstellungen den maximalen Datendurchsatz. Auch beim sequentiellen Schreiben sind alle Controller im gleichen Leistungsbereich, wobei der Datendurchsatz durch optimale Cache-Einstellungen um bis zu 65% gesteigert werden kann.

Beim wahlfreien Zugriff im RAID 1 zeigt der Einstiegs-Controller LSI MegaRAID SAS 1064/1068 bei diesem Lastprofil einen etwas höheren Datendurchsatz als der LSI MegaRAID SAS 1078 Controller, der mit seinem Controller-Cache und der erweiterten Funktionalität für die höheren RAID-Level optimal ausgestattet ist und auch bei RAID 1 eine gute Leistung bietet.

LSI MegaRAID SAS 1078 mit 512 MB Cache





Fazit

Mit dem »Modular RAID« Konzept bietet die PRIMERGY RX200 S5 eine Fülle von Möglichkeiten, um den verschiedenen Anforderungen unterschiedlichster Anwendungsszenarien gerecht zu werden.

Der Einstiegs-Controller, repräsentiert durch den LSI MegaRAID SAS 1064 bzw. 1068 Controller, bietet die Basis-RAID-Lösungen RAID 0, RAID 1 und RAID 1E an, wobei er diese RAID-Levels bei sehr guter Performance unterstützt.

Der »High End« Controller, repräsentiert durch den LSI MegaRAID SAS 1078 Controller, bietet alle heute gängigen RAID-Lösungen an: das sind für die PRIMERGY RX200 S5, die mit maximal acht internen Festplatten ausgebaut werden kann, die RAID-Level 0, 1, 5, 6, 10, 50 und 60. Dieser Controller wird mit 256 MB oder 512 MB großem Controller-Cache ausgeliefert und kann optional mit einer BBU gesichert werden. Vielfältige Möglichkeiten die Nutzung des Cache einzustellen erlauben eine flexible Anpassung der Controller-Leistung an den verwendeten RAID-Level.

Die Verwendung von RAID 5 oder RAID 6 ermöglicht eine wirtschaftliche Ausnutzung der vorhandenen Festplattenkapazität bei guter Performance. Für optimale Performance und Sicherheit ist jedoch ein RAID 10 zu empfehlen.

Die PRIMERGY RX200 S5 bietet 2½"-SAS-Festplatten mit Umdrehungsgeschwindigkeiten von 10 krpm und 15 krpm. In Abhängigkeit von der benötigten Performance ist zu entscheiden, welche Umdrehungs-geschwindigkeit zum Einsatz kommen soll. Festplatten mit 15 krpm bieten eine bis zu 52% bessere Performance.

Für maximale Performance empfiehlt es sich, insbesondere bei der Verwendung eines Controllers ohne Controller-Cache, den Disk-Cache einzuschalten. Je nach verwendetem Plattentyp und Zugriffsmuster verbessert sich damit die Performance um bis zu etwa 85%. Entscheidet man sich für die Aktivierung des Disk-Cache, ist der Einsatz einer USV empfehlenswert.

Benchmark-Umgebung

Alle hier vorgestellten Messungen wurden mit den im Folgenden aufgelisteten Hardware- und Software-Komponenten durchgeführt.

Komponente Details

Server PRIMERGY RX200 S5

Betriebssystem Windows Server 2008, Enterprise Edition Version: 6.0.6001 Service Pack 1 Build 6001

Dateisystem NTFS

Messwerkzeug Iometer 27.07.2006

Messdaten Messdatei von 8 GB

Controller LSI MegaRAID SAS 1068

Produkt: LSI RAID 0/1 SAS 1068 Driver Name: lsi_sas.sys, Driver Version: 1.29.03.00 Firmware Version: 01.27.00.00 BIOS Version: 06.26.00.00

Controller LSI MegaRAID SAS 1078

Produkt: LSI RAID 5/6 SAS 1078 Driver Name: megasas.sys, Driver Version: 3.9.0.64 Firmware-Paket: 11.0.1-0008 Firmware Version: 1.40.32-0580 BIOS Version: 2.06.00 Controller Cache: 256 MB oder 512 MB

Hard Disk SAS, 2½", 10 krpm Seagate ST973402SS, 73 GB

Hard Disk SAS, 2½", 15 krpm Seagate ST973451SS, 73 GB




OLTP-2


OLTP steht für Online Transaction Processing. Dem OLTP-2-Benchmark liegt das typische Anwendungs-szenario 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-E-Werten ä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.


Die PRIMERGY RX200 S5 wurde mit Xeon Prozessoren der Serie 5500 bei Speicherausbauten von 24 GB, 36 GB, 48 GB, 72 GB und 96 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 Sys-tems mit Festplatten und deren Controllern. Für die Messungen wurden daher zwei 2-Kanal Fibre Channel Controller verwendet, über die fünf FibreCAT CX500 mit insgesamt 450 Festplatten angeschlossen waren. Das Disk-Subsystem wurde derart dimensioniert, dass es in der Messung kein Engpass ist. Es können vergleichbare Ergebnisse mit anderen Disk-Subsystemen erreicht werden, wenn diese ebenfalls keinen Engpass darstellen. Weitere Informationen über die Systemkonfiguration können dem Abschnitt Benchmark-Umgebung entnommen werden.

In der maximalen Speicherausbaustufe der PRIMERGY RX200 S5 mit 6 Speichermodulen bei einem Pro-zessor und 12 Speichermodulen bei 2 Prozessoren erfolgt die Speicheransteuerung mit 1067 MHz für die Prozessortypen Xeon E5520, E5530, E5540, X5550, X5560 und X5570. Bei den Prozessortypen Xeon E5502, E5504 und E5506 erfolgt die Speicheransteuerung mit 800 MHz.

Die folgenden Grafiken zeigen die OLTP-2-Leistungsdaten der PRIMERGY RX200 S5 in zwei Gruppen mit einem und zwei Prozessoren der Xeon Serie 5500 (E5502, E5504, E5506, E5520, E5530, E5540, X5550, X5560 und X5570). Die Leistungswerte des Xeon L5530 sind denen des Xeon E5530, die des Xeon L5520 denen des Xeon E5520 und die des Xeon L5506 denen des Xeon E5506 gleichzusetzen.

Die größte Leistungssteigerung bei den Prozessortypen ist von Xeon E5502 nach Xeon E5504 mit +95% bis +98% durch die Verdopplung der Anzahl Cores von zwei auf vier. Ebenfalls deutlich ist die Steigerung von Xeon E5506 nach Xeon E5520 mit +56% bzw. +57% durch die Verdopplung des Prozessor-Caches von 4 MB auf 8 MB und die Nutzung von Hyper-Threading. Der Leistungsgewinn von Xeon E5520 nach Xeon X5570 beträgt +22% und +24%. Die Speicherskalierung von 36 GB auf 48 GB ist ca. +8% und von 72 GB auf 96 GB ca. +3%. Dies ist sehr stark vom Lastprofil des OLTP-2-Benchmarks abhängig und kann nicht auf alle Datenbankanwendungen übertragen werden.



105.00

207.94 213.94

335.45 345.43 355.40

395.83 404.22 412.60

98.32

191.35 197.75

315.44 322.79 330.14364.50 372.33 380.16

87.93

169.64 173.79

285.47 292.49 299.52326.91 335.42 343.94

0

100

200

300

400

500

600

700

800

tps

Xeon

E5502

Xeon

E5504

Xeon

E5506

Xeon

E5520

Xeon

E5530

Xeon

E5540

Xeon

X5550

Xeon

X5560

Xeon

X5570

24 GB

36 GB

48 GB

RAM

OLTP-2: PRIMERGY RX200 S5 with 1 Xeon processor 55xx

bold numbers: measured results

others: calculated results

+57% +23%

+98%

105.00

207.94 213.94

335.45 345.43 355.40

395.83 404.22 412.60

98.32

191.35 197.75

315.44 322.79 330.14364.50 372.33 380.16

87.93

169.64 173.79

285.47 292.49 299.52326.91 335.42 343.94

0

100

200

300

400

500

600

700

800

tps

Xeon

E5502

Xeon

E5504

Xeon

E5506

Xeon

E5520

Xeon

E5530

Xeon

E5540

Xeon

X5550

Xeon

X5560

Xeon

X5570

24 GB

36 GB

48 GB

RAM

OLTP-2: PRIMERGY RX200 S5 with 1 Xeon processor 55xx



+57% +23%

+98%

207.43

405.04 412.02

642.70658.63 674.56

749.74 767.39785.03

202.10

391.19 401.78

624.07639.84 655.61

731.78746.09 760.40

184.86

350.21 356.55

574.65 589.05603.45

673.21 686.29 699.37

0

100

200

300

400

500

600

700

800

tps

Xeon

E5502

Xeon

E5504

Xeon

E5506

Xeon

E5520

Xeon

E5530

Xeon

E5540

Xeon

X5550

Xeon

X5560

Xeon

X5570

48 GB

72 GB

96 GB

RAM

OLTP-2: PRIMERGY RX200 S5 with 2 Xeon processors 55xx

+56% +22%

+95%



207.43

405.04 412.02

642.70658.63 674.56

749.74 767.39785.03

202.10

391.19 401.78

624.07639.84 655.61

731.78746.09 760.40

184.86

350.21 356.55

574.65 589.05603.45

673.21 686.29 699.37

0

100

200

300

400

500

600

700

800

tps

Xeon

E5502

Xeon

E5504

Xeon

E5506

Xeon

E5520

Xeon

E5530

Xeon

E5540

Xeon

X5550

Xeon

X5560

Xeon

X5570

48 GB

72 GB

96 GB

RAM

OLTP-2: PRIMERGY RX200 S5 with 2 Xeon processors 55xx

+56% +22%

+95%





Vergleicht man die PRIMERGY RX200 S5 mit ihren Vorgängern, der PRIMERGY RX200 S3 und RX200 S4, in jeweils performantester Ausstattung, so ergibt sich eine Durchsatzsteigerung von 179% bzw. 135%.

OLTP-2: PRIMERGY RX200 S3 vs. RX200 S4 vs. RX200 S5

281.8

334.62

785.03

0

100

200

300

400

500

600

700

800

PRIMERGY RX200 S3

2 x Xeon X5365

32 GB RAM

PRIMERGY RX200 S4

2 x Xeon X5460

64 GB RAM

PRIMERGY RX200 S5

2 x Xeon X5570

96 GB RAM

+179%

+135%

OLTP-2: PRIMERGY RX200 S3 vs. RX200 S4 vs. RX200 S5

281.8

334.62

785.03

0

100

200

300

400

500

600

700

800

PRIMERGY RX200 S3

2 x Xeon X5365

32 GB RAM

PRIMERGY RX200 S4

2 x Xeon X5460

64 GB RAM

PRIMERGY RX200 S5

2 x Xeon X5570

96 GB RAM

+179%

+135%



Benchmark-Umgebung

System Under Test (SUT)

Hardware

Server PRIMERGY RX200 S5

Processor Xeon E5502, E5504, E5506, E5520, E5530, E5540, X5550, X5560,

X5570

Memory Up to 12 x 8 GB DDR3 PC3-8500R

Settings (default) Turbo Mode enabled, NUMA Support enabled, Hyper-Threading enabled

Network Interface 2 x 1-GBit LAN (onboard)

Disk Subsystem

PRIMERGY RX200 S5: 1 x LSI SAS with 1068E 2x 2.5" 36GB 15K Fujitsu MAY2073RC RAID-1, OS 6x 2.5" 73GB 15K Fujitsu MAY2073RC RAID-0, log 2 x dual-channel FC controller QLE2462

5 x FibreCAT CX500: 315 x Seagate 36 GB 15 krpm 135 x Seagate 73 GB 15 krpm RAID-0, data

Software

Operating System Windows Server 2008 Enterprise x64 Edition

Database SQL Server 2008 Enterprise x64 Edition

Load Generators

Hardware

Model 4 x PRIMERGY Econel 200

Processor 2 x Xeon 3.40 GHz, 2 MB L2 cache

Memory 2 GB DDR-SDRAM PC2700

Network Interface 1 x 1-GBit LAN (onboard)

Software

Operating System Windows Server 2003 Standard Edition SP1 (x86)

OLTP-2 Software EGen version 1.6.0-1011


LAN Switch

Load generators System Under Test



Terminal Server


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 werden während der Messung als Lastprofil verwendet.

Der Lastsimulator von T4US besteht aus drei Komponenten.

T4US-Control steuert und überwacht den gesamten Simulationslauf zentral und ermittelt Messwerte bereits während der Messung. Auf jedem der Lastgeneratoren laufen mehrere Instanzen des T4US-Playback. Jedes T4US-Playback »füttert« einen Terminal Server Client in Echtzeit mit Tastatur- und Mauseingaben anhand der mit T4US-Record aufgezeichneten Skripte und überwacht die Bildschirminhalte des Terminal Server Clients. Durch hoch auflösende Timer wird so die Antwortzeit des Terminal Servers 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 wenigen 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. Diese Zahl sollte man jedoch nicht absolut nehmen, da die Anzahl Benutzer, die ein System unterstützen kann, immer abhängig ist vom tatsächlichen Benutzerprofil. Stattdessen sollten die Ergebnisse relativ betrachtet werden, 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«.

T4US Record

T4US Skript

Benutzer bei der Arbeit

T4US Play

T4US Agent

Lastgenerator

…

T4US Play

T4US Play

TS Client

TS Client

Terminal Server

…

TS Client

System under Test (SUT)

SUT

T4US Control

Controller



Lastprofil V2

Das bisher in den Terminal Server Messungen benutzte Lastprofil V1, bei dem sich jeder Benutzer zyklisch beim Terminal Server anmeldet, einen bebilderten Text erstellt und sich dann wieder abmeldet, kann nicht mehr weiter verwendet werden. Durch die verbesserte Leistung der zu vermessenden Systeme kommt der Benchmark in eine Größenordnung, bei der die Benutzeranzahl durch die durchzuführenden An- und Abmeldevorgänge, also Restriktionen im Betriebssystem, erreicht wird und nicht mehr durch die Prozessorleistung des Systems. Das bedeutet, der Benchmark erreicht seine Grenzwerte schon, ohne den Prozessor auszulasten. Verbesserte Prozessorleistung wird durch den Benchmark nicht messbar. Deshalb wird bei den hier durchgeführten Messungen ein neues Lastprofil V2 eingesetzt.

Das neue Lastprofil V2 zeichnet sich dadurch aus, dass ein zu simulierender Benutzer mit verschiedenen Microsoft Office Anwendungen arbeitet. Neben der Erstellung eines Microsoft Word Dokumentes wird auch eine Powerpoint Präsentation kreiert. Ebenso werden Berechnungen auf einem neu angelegten Excel Arbeitsblatt durchgeführt. Die Anzahl der An- und Abmeldevorgänge ist im Vergleich zum alten Lastprofil reduziert. Im Schnitt meldet sich nur jeder sechste Benutzer zyklisch am Terminal Server ab und wieder an. Ebenso druckt durchschnittlich jeder sechste Benutzer ein Word Dokument aus. Zusätzliche CPU-Last wird durch Verpacken und Entpacken von Dateien im Speicher erreicht. Die Tippgeschwindigkeit des simulierten Benutzers beträgt zwischen 330 und 440 Anschlägen pro Minute.

Der Speicherbedarf beim Terminal Server Benchmark wächst linear mit der Anzahl der Benutzer. Er ist abhängig von dem unterliegenden Betriebssystem, ins-besondere ergeben sich Unterschiede bei 32-bit- und 64-bit-Betriebssystemen. Ausführlich behandelt wird dieser Aspekt in dem Dokument Terminal Server Sizing Guide (siehe Literaturverzeichnis).

In der nebenstehenden Grafik ist der Speicherbedarf des Benchmarks mit dem Lastprofil V2 auf einem 64-bit Windows Server 2008 System dargestellt. Dadurch dass die Benutzer nun mit verschiedenen Anwendungen arbeiten, fällt der Speicherverbrauch beim Lastprofil V2 höher aus als beim ursprünglichen Lastprofil V1.

In den weiteren Grafiken werden die durchschnittlichen IO-Raten der Platten und des Netzwerkes sowie die zugehörigen Datendurchsätze aufgeführt, die dieses Lastprofil V2 auf einem Windows Server 2008 x64 System erzeugt.

http://docs.ts.fujitsu.com/dl.aspx?id=278825c9-7644-49c1-9848-f2a5c8c694cd





Bei allen durchgeführten Messungen war das Terminal Server System mit dem Betriebssystem »Windows Server 2008 x64 Enterprise Edition SP1« ausgestattet. Auf Messungen mit einem 32-bit Betriebssystem wurde wegen der Limitierungen bei der Adressierung des Arbeitsspeichers und bei den Kernelstrukturen und der damit einhergehenden Beschränkung der Benutzeranzahl verzichtet.

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 28 GB eingestellt.

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 auf einer Partition eines RAID 0-Verbandes zweier Festplatten, die Daten der Benutzer und das Pagefile werden auf Partitionen eines RAID 0-Verbandes weiterer zweier Festplatten des Terminal Servers gespeichert. Diese Konfiguration wird verwendet, damit die Messergebnisse zwischen den verschiedenen PRIMERGY Systemen vergleichbar sind und das Disk-Subsystem nicht zum Engpass bei der Messung wird. Dies entspricht jedoch nicht zwingend der realen Kundenkonfiguration, denn dort wird man die Benutzerdaten typischerweise auf entsprechende Disk-Subsysteme oder externe File Server legen und nicht auf lokale Festplatten eines Terminal Servers. Um einen maximalen Durchsatz zu erreichen, wurden alle Caches, auch die Write-Caches, eingeschaltet. Write-Caches der Festplatten tragen erheblich zur Performance-Steigerung bei, und es empfiehlt sich, diese bei allen Festplatten vorhandene Funktionalität auch im produktiven Einsatz zu nutzen. Dabei ist die Verwendung einer USV zum Schutz gegen Stromausfälle und damit verbundenem Datenverlust empfehlenswert.

Arbeitsspeicher

Den stärksten Einfluss auf die Leistungsfähigkeit eines Terminal Servers übt der Arbeitsspeicher aus. Das spiegelt sich 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.

Da ein Terminal Server mit vielen Benutzern und verschiedenen Anwendungen arbeitet, kommt es also in erster Linie darauf an, das System mit ausreichend Speicher bestückt zu haben. Die Speicherzugriffsgeschwindigkeit ist dann ein nachrangiger Faktor. Die PRIMERGY RX200 S5 bietet mit einem maximalen Speicherausbau von bis zu 96 GB eine gute Plattform für Terminal Server.

Die Speicherzugriffsgeschwindigkeit bei der PRIMERGY RX200 S5 ist sowohl abhängig vom Prozessor als auch von der Speicherbestückung. Die beste Zugriffsgeschwindigkeit wird erreicht, wenn die Speicherstreifen nur auf eine Bank, verteilt über die der CPU zugeordneten Kanäle, gesteckt werden.

Bei den hier durchgeführten Messungen waren die vermessenen Terminal Server Systeme mit ausreichend Speicher ausgestattet. Die PRIMERGY RX200 S5 war mit 6 × 4 GB Memory, verteilt auf je drei Kanäle pro CPU, optimal für die Anzahl simulierter Benutzer und auch optimal für geringe Speicherzugriffszeiten bestückt. Eine Verdopplung des Speichers auf 48 GB brachte keine Verbesserung der Benchmark-Ergebnisse.



Rechenleistung

Die PRIMERGY RX200 S5 kann je nach Bedarf mit verschiedenen Prozessoren ausgestattet werden, die sich hinsichtlich Taktfrequenz, Cache, Transferrate des Quick Path Interconnects (Gigatransfer, GT) und Anzahl Kerne unterscheiden.

Für den Terminal Server Benchmark wurde das System sowohl mit dem kleinsten Quad-Core Prozessor, dem Xeon E5504, und dem zurzeit stärksten Quad-Core Prozessor für dieses System, dem Xeon X5570, vermessen. Im Gegensatz zum Xeon E5504 verfügt der Xeon X5570 sowohl über Hyper-Threading als auch über die Turbo Boost Technologie, die abhängig von der Anwendung den Prozessor automatisch beim Arbeiten unterhalb der maximalen Energieaufnahme (Thermal Design Power (TDP)) übertaktet.

Weitere Kennzeichen der vermessenen Prozessoren sind

Xeon E5504, 2.00 GHz, 4.8 GT, max. 800 MHz DDR3 Bus Speed, 4 MB L3-Cache, 80 Watt

Xeon X5570, 2.93 GHz, 6.4 GT, max. 1333 MHz DDR3 Bus Speed, 8 MB L3-Cache, 95 Watt

Die mit dem neuen Lastprofil V2 erreichten maximalen Benutzerzahlen pro System sind nicht vergleichbar mit den Benutzerzahlen, die durch das frühere Lastprofil V1 erreicht wurden. Um Konfusion zu vermeiden, werden die Ergebnisse des Benchmarks deshalb nicht mehr in absoluten Benutzerzahlen dargestellt, sondern nur noch relativ zu einem zuvor gemessenen Referenzsystem, hier eine PRIMERGY TX200 S4 bestückt mit bis zu zwei Xeon E5430 Prozessoren, die weder über Hyper-Threading noch über Turbo Boost Technologie verfügen.

Xeon E5430, 2.67 GHz, 1333 MHz Front-Side-Bus, 2 × 6 MB L2-Cache, 80 Watt

Der Terminal Server Benchmark mit dem neuen Lastprofil V2 skaliert gut. Sowohl bei dem Referenzsystem als auch bei der PRIMERGY RX200 S5 mit dem Xeon E5504 wird durch eine Verdoppelung der Prozessoranzahl, d.h. von vier auf acht Kerne, eine Steigerung der System-Performance um den Faktor 1.8 erreicht.

Der Xeon X5570 besitzt bei Einschalten des Hyper-Threadings acht logische CPU-Kerne. Die Hinzunahme einer zweiten CPU bedeutet also die Steigerung von acht auf 16 logische Kerne. Selbst bei diesen Messungen erreicht der Benchmark noch eine gute Skalierung der System-Performance von über 1.7.

Das PRIMERGY RX200 S5 System mit dem Xeon E5504 liegt in der System-Performance in der gleichen Größen-ordnung wie das Referenzsystem.

Wird das PRIMERGY RX200 S5 System mit den stärkeren Xeon X5570 Prozessoren bestückt, so wird bei dem Terminal Server Benchmark mehr als eine Verdoppelung der System-Performance erreicht. Neben der höheren Taktfrequenz und dem größeren Second Level Cache ist auch der Memory Zugriff schneller. Bei beiden Messungen war das System mit 6 × 4 GB Speicher ausgestattet. Der Terminal Server Benchmark profitiert dabei sehr gut von den zusätzlichen logischen Kernen. Bei der auftretenden Lastspitzen des Terminal Server Benchmarks wirkt auch die Turbo Boost Technologie des Xeon X5570 Performance-steigernd.

Insgesamt zeigt sich die PRIMERGY RX200 S5 gut für Terminal Server Anwendungen geeignet. Durch Technologien wie Hyper-Threading und Turbo Boost ergibt sich eine starke Prozessorleistung, die in Verbindung mit einem großen Speicherausbau in der Praxis eine hohe Anzahl an Terminal Server Benutzern erlaubt. Dabei muss sich die tatsächliche Anzahl Benutzer jedoch immer nach dem aktuellen Kundenlastprofil richten.



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.


System Under Test (SUT): Der Terminal Server wurde mit den Microsoft Terminal Services betrieben, die im Windows Betriebssystem enthalten sind. Auf dem Terminal Server wurde neben den in der Tabelle aufgeführten Anwendungen keine weitere Software installiert.

Hardware

Modell PRIMERGY RX200S5 // PRIMERGY TX200S4

Prozessor 1-2 Xeon E5504 // 1-2 Xeon E5430

1-2 Xeon X5570

Speicher 24 GB // 12 GB

Netzwerk-Interface 1×1-GBit LAN Intel (onboard) // Broadcom

Disk Subsystem 2 × SAS Controller: LSI 1078 Modular RAID

4 × SAS Festplatten, 15 krpm, RAID 0

Software

Betriebssystem Windows Server 2008 x64 Enterprise Edition

Version Service Pack 1

Netzwerkprotokoll TCP/IP

Disk Organisation 1 Volume für das Betriebssystem je 1 Volume für Daten und Pagefile

Terminal Server Software

Microsoft Terminal Services

Anwendung Microsoft Office 2003 (32-bit), 7-Zip 4.57

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 // PRIMERGY BX300

# Lastgeneratoren 20 // 20

Prozessor Pentium D 940 // 2 × Pentium III 933 MHz

Memory 2 GB // 1 GB

Netzwerk-Interface 2 × 1 GBit LAN

T4US Controller- und Infrastrukturserver-Hardware

Model PRIMERGY C200

Prozessor 2 × Pentium III 1.40 GHz

Memory 1.5 GB

Netzwerk-Interface 2 × 100 MBit LAN

Software

Betriebssystem Windows Server 2003 Standard Edition SP2

Netzwerkprotokoll TCP/IP

RDP Client 6.0.6000.16459

T4US Version 3.3

T4US Lastprofil T4US Lastprofil V2

PRIMERGY C200 T4US-Control

SUT-Netzwerk

ca. 40 PRIMERGY Dual Server Windows Server 2003

TS-Client T4US-Agent, T4US-Playback

Jeder simuliert bis zu 12 Benutzer

Simulations- netzwerk

PRIMERGY C200 Windows Server 2003

Active Directory Terminal Server

Licensing Service

PRIMERGY Windows Server 2008

Enterprise Edition

Infrastruktur- Server

switched 100 Mbit

Lastgeneratoren Controller für die

Simulation

switched 100 Mbit

System under test

(SUT)



VMmark1


VMmark ist ein von VMware entwickelter Benchmark zum Vergleich von Serverkonfigurationen mit Hypervisor-Lösungen von VMware in Bezug auf ihre Eignung für Server-Konsolidierung. VMmark ist derzeit der einzige etablierte Benchmark für diesen Zweck. Neben der Software zur Lastgenerierung besteht der Benchmark aus einem definierten Lastprofil und aus einem verbindlichen Regelwerk. Mit VMmark erzielte Benchmark-Ergebnisse können bei VMware eingereicht werden und werden nach einem erfolgreich durchlaufenen Review-Prozess auf deren Internet-Seite veröffentlicht.

Damit ein Benchmark wie VMmark seinem Ziel gerecht wird, muss er die Realität in den Rechenzentren bei der Serverkonsolidierung abbilden, er muss also Bestandsserver mit solchen Anwendungsszenarien betrachten, die typischerweise virtualisiert werden. Diese Server sind schwach ausgelastet, und man strebt deswegen an, möglichst viele von ihnen als VMs zu konsolidieren. Ein solcher Benchmark muss also für einen Virtualisierungs-Host sowohl den geeignet gemittelten Gesamtdurchsatz über verschiedene Anwendungs-VMs bewerten als auch die Anzahl der effizient betreibbaren VMs.

Für diese zweiteilige Zielsetzung hat sich folgendes Lösungskonzept etabliert: Man definiert im Benchmark eine repräsentative Auswahl von Anwendungsszenarien. Diese werden bei einer Messung gleichzeitig als VMs auf einem Virtualisierungs-Host gestartet. Jede dieser VMs wird mit einem geeigneten Last-Tool auf einem definierten niedrigen Lastniveau betrieben. Eine solche Gruppe von VMs nennt man eine »Tile« (engl. für Kachel).

Bei VMmark besteht eine Tile aus sechs VMs, von denen fünf dediziert den ausgewählten Anwendungsszenarien zugeordnet sind. Hinzu kommt eine sechste, so genannte Standby-VM. Jeder VM sind von VMmark her zwingend bestimmte Ressourcen an logischen Prozessoren, Memory und Festplattenplatz zuge-ordnet. Die nebenstehende Tabelle beschreibt diese sechs VMs und die Last-Tools, mit denen sie jeweils vermessen werden.

Je nach Leistungsfähigkeit der zugrunde liegenden Server-Hardware ist es meist notwendig, dass im Rahmen einer Messung mehrere identische Tiles parallel gestartet werden um eine maximale Gesamt-Performance zu erreichen.

1 Zur Information über VMmark und seine Benutzungsregeln folgen Sie bitte dem Link

http://www.vmware.com/products/vmmark. VMware und VMmark sind Warenzeichen bzw. eingetragene Warenzeichen von VMware, Inc. VMware® VMmark™ ist ein Produkt von VMware, Inc. VMmark benutzt SPECjbb®2005 und SPECweb®2005, welche bei der Standard Performance Evaluation Corporation (SPEC®) verfügbar sind.

Anwendungsszenario Last-Tool

Database-Server Sysbench

File-Server Dbench (angepasst)

Java-Applikationsserver SPECjbb2005 (angepasst)

Mail-Server LoadSim 2003

Web-Server SPECweb2005 (angepasst)

Standby-Server -

System under Test

Tile n

Tile 3

Tile 2

Tile 1

Database VM

Java VM

Mail VM

Fileserver VM

Web VM

Standby VM

Database VM

Java VM

Mail VM

Fileserver VM

Web VM

Standby VM

Database VM

Java VM

Mail VM

Fileserver VM

Web VM

Standby VM

Database VM

Java VM

Mail VM

Fileserver VM

Web VM

Standby VM

… …

http://www.vmware.com/products/vmmark

http://www.vmware.com/

http://www.spec.org/



Jedes der fünf VMmark-Anwendungsszenarien ergibt für jede VM ein spezifisches Ergebnis. Um hieraus eine Bewertungszahl (Score) zu bilden, werden die einzelnen Ergebnisse über alle VMs geeignet zusammengefasst. Das Ergebnis ist dann der VMmark-Score für diese Tile-Anzahl, daher wird neben dem eigentlichen Score immer die Tile-Anzahl genannt, z.B. »12.34@5 tiles«.

Eine ausführliche Beschreibung von VMmark ist im Übersichtsdokument VMmark - Benchmark Überblick zu finden.


Am 11. August 2009 erzielte Fujitsu mit einer PRIMERGY RX200 S5 und VMware ESX 4.0 einen VMmark-Score von »24.20@17tiles«.

Dieses Messergebnis sowie die ausführlichen Resultate und Konfigurationsdaten sind unter http://www.vmware.com/products/vmmark/results.html veröffentlicht. Mit dem Score von »24.20@17 tiles« ist die PRIMERGY RX200 S5 aus VMmark-Sicht der leistungsstärkste 1U-Rackserver mit acht Cores und belegt zugleich den dritten Platz in der VMmark-Rangliste der Server in der Acht-Core-Kategorie (zum Zeitpunkt der Veröffentlichung des Benchmark-Ergebnisses).

Wesentliche Voraussetzungen zur Erreichung dieses Ergebnisses waren der verwendete Prozessor, ein Xeon X5570, und die verwendete Hypervisor-Version, die die Prozessor-Features optimal nutzt. Zu diesen Features gehören die »erweiterten Seitentabellen« (englisch »Extended Page Tables«, kurz EPT)

2, das

Hyper-Threading und die schnelle Speicheranbindung dieser Prozessorarchitektur. All dies wirkt sich speziell bei der Virtualisierung positiv aus.

Zum Betrieb der 17 Tiles war ein Speicherausbau von 96 GB (12 × 8 GB) notwendig.

Alle VMs, deren Anwendungsdaten, das Host-Betriebssystem sowie weitere erforderliche Daten befanden sich auf einem leistungsfähigen Fibre-Channel Disk-Subsystem mit 37 LUNS.

Bemerkenswert ist, dass bei der vermessenen PRIMERGY RX200 S5 die VMs für ihre Netzwerkzugriffe mit zwei physikalischen 1Gb-LAN-Ports auskamen. Fast alle vergleichbaren veröffentlichten VMmark-Resultate der Mitbewerber verwendeten hierfür mehr physikalische LAN-Ports oder die 10Gb-Technologie.

2 EPT beschleunigt die Virtualisierung von Memory durch eine Hardware-Unterstützung für die Umsetzung

zwischen Host- und Gast-Memory-Adressen.

http://www.vmware.com/products/vmmark/results.html



Benchmark-Umgebung

Der Messaufbau wird symbolisch durch folgende Grafik veranschaulicht:


Mehrere

1Gb oder 10Gb Netzwerke

Controller

Lastgeneratoren

Server Storage-System


SUT-Hardware


Prozessor 2 × Xeon X5570 (2.93 GHz)

Memory 96 GB (12 × 8 GB per DIMM), 1066 MHz registered ECC DDR3

Netzwerk-Interface

Integrierter Intel 82575EB dual port 1GbE Adapter und ein Intel 82571EB quad port Adapter. Davon 1 Port für die Service Console, 1 Port für die Webserver-VMs und 1 Port für alle übrigen VMs.

Disk-Subsystem Es wurden keine internen Festplatten verwendet, sondern ausschließlich vier Storage-Systeme FibreCAT CX500, insgesamt 291 Festplatten.

Pro Tile eine 100 GB LUN über 11 Disks exklusiv und eine 24 GB LUN über 15 Disks geteilt mit je 2 anderen dieser LUNS.

Eine 11 GB LUN über 5 Disks für das Host-OS

Eine 120 GB LUN über 5 Disks für die Konfigurationen und als Swap-Bereich

Eine 150 GB LUN über 5 Disks für Backup

Alle LUNs sind RAID 0 Verbände aus Seagate ST373454FCV-Disks (15 krpm)

Storage-Anbindung

Über dual port FC-Controller Qlogic QLE 2462

SUT-Software

Betriebssystem Hypervisor VMware ESX Server

Version Version 4.0.0 build 164009

BIOS Version 6.00 R1.05A.2786; Default-Einstellungen


Modell 17 Server-Blades PRIMERGY BX620 S4 (1 pro Tile)

Prozessor Intel Xeon 5130, 2 GHz

Memory 3 GB

Netzwerk-Interface Je 1 GBit LAN

Betriebssystem W2K3 R2 EE, SP2 + KB955839



vServCon


vServCon ist ein bei Fujitsu Technology Solutions verwendeter Benchmark zum Vergleich von Serverkonfigurationen mit Hypervisor in Bezug auf ihre Eignung für Server-Konsolidierung. Hiermit ist sowohl der Vergleich von Systemen, Prozessoren und I/O-Technologien möglich, wie auch der Vergleich von Hypervisor-en, Virtualisierungsformen und zusätzlichen Treibern für virtuelle Maschinen.

Bei vServCon handelt es sich um ein Framework, das bereits etablierte Benchmarks zusammenfasst, um die Last einer konsolidierten und virtualisierten Serverumgebung nachzubilden. Es kommen drei bewährte Benchmarks zum Einsatz, die die Anwendungsszenarien Datenbank, Applikationsserver und Webserver abdecken:

Anwendungsszenario Benchmark Anzahl logische CPU-Cores Memory

Database Sysbench (angepasst) 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 parallel gestartet werden müssen, um eine maximale Performance-Bewertungszahl (Score) zu erreichen.

Jedes der drei vServCon-Anwendungsszenarien ergibt für jede VM ein spezifisches Benchmark-Ergebnis in Form von applikationsspezifischen Transaktionsraten. Um hieraus einen Score für eine gegebene Tile-Anzahl zu bilden, werden die einzelnen Benchmark-Ergebnisse in Relation zu den jeweiligen Ergebnissen eines Referenzsystems gesetzt. Als Referenzsystem für vServCon ist eine PRIMERGY RX300 S3 definiert worden. Die daraus resultierenden dimensionslosen Performance-Werte werden dann unter Berücksichtigung der Anzahl der virtuellen CPUs und der Memory-Größe gewichtet und über alle VMs und Tiles aufsummiert. Das Ergebnis ist der vServCon-Score für diese 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) und soweit möglich die elektrische Leistungsaufnahme dokumentiert.

Der Score soll eine virtualisierungsspezifische Leistung eines Systems ausdrücken, die man bis zur möglichst vollständigen Ausnutzung der CPU-Ressourcen mittels vieler VMs erzielen kann. Der Score wäre also nicht aussagekräftig, wenn während einer vServCon-Messung schon bei einer unnötig kleinen Tile-Anzahl eine Limitierung eintreten würde, z. B. durch eine nicht ausreichend dimensionierte Disk-Anbindung oder nicht genügend Hauptspeicher. 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.

System Under Test

Loadgen. Web

Loadgen. Web

Load gen. Web

Framework Controller

Tile Tile Tile

VM Web

VM Java

VM Idle

VM Database

http://docs.ts.fujitsu.com/dl.aspx?id=214ee9dc-9239-4985-86e4-f0f9ac78ea25





Die PRIMERGY RX200 S5 ist durch erhebliche Fortschritte in der Prozessortechnologie gut für die Virtualisierung von Anwendungen geeignet. Verglichen mit dem Vorgängersystem ist eine etwa zweifache Virtualisierungs-Performance (gemessen in vServCon-Score) erreichbar. So ist auf Basis des zuvor beschriebenen vServCon-Profils bei Vollausbau mit zwei Xeon 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 RX200 S5 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.

Die Leistungsfähigkeit dieser aktuellen Xeon Prozessoren zeigt sich in einer Steigerung der Gesamt-Performance bis hin zu sechs Tiles. Die vServCon-Scores steigen zudem erkennbar mit der Prozessor-frequenz an.

Die hohe Tile-Anzahl wird insbesondere durch das Hyper-Threading ermöglicht, wobei bekanntermaßen ein physikalischer Prozessorkern in zwei logische Cores unterteilt wird, so dass für den Hypervisor 16 logische Cores verfügbar sind. Dieses standardmäßig eingestellte Feature steigert daher im Allgemeinen die Virtualisierungs-Performance eines Systems.

Spezifisch für Systeme mit Hyper-Threading ist der Verlauf dieser Skalierungskurven über die Tile-Anzahl. Aufgrund der pro Tile verwendeten etwa vier logischen CPUs (siehe Benchmark-Beschreibung) wird bis etwa zwei Tiles eine parallele Nutzung gleicher physikalischer Cores durch mehrere VMs vermieden. Daher skaliert die Performance in diesem Bereich nahezu ideal. Darüber verläuft der Performance-Zuwachs bis zur CPU-Sättigung flacher.

Als Richtschnur für die Auswahl von Arbeitsspeicher gilt im Virtualisierungsumfeld, dass eine ausreichende Menge wichtiger ist als die Geschwindigkeit der Speicherzugriffe.



Ein wesentlicher Aspekt der Server-Konsolidierung ist die Einsparung elektrischer Energie. So kann man z. B. beim Xeon E5540 Prozessor allein durch die Verdoppelung der Anzahl der echten Anwendungs-VMs von drei auf sechs die Virtualisierungs-Performance um 76% steigern, während gleichzeitig die elektrische Leistungsaufnahme nur um ca. 11% 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.

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 X5570 betrachtet.

Wenn die Anzahl der Anwen-dungs-VMs im optimalen Bereich aus Sicht der Gesamt-Performance liegt, ist die Performance einer einzelnen VM schon merklich geringer als im Betrieb in Niedrig-lastsituationen. Das nebenste-hende Diagramm verdeutlicht dies durch die relative Perfor-mance im Verhältnis zum Referenzsystem bei einer einzelnen Anwendungs-VM von jedem der drei Typen für wachsende VM-Anzahlen. Die jeweils erste Säule einer Gruppe betrachtet eine VM im Verbund von insgesamt drei Anwendungs-VMs (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.

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 CGI-Programme (bzw. Skripte) realisiert. Diese CGI-Programme erzeugen bei jedem Aufruf einen neuen Prozess, was für den Hypervisor recht aufwändig ist. Alternativ können dynamische Inhalte durch den Einsatz von PHP, ASP oder ä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 Diagramm unten 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 Virtualisierungs-lö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.

An dem Diagramm wird der Fortschritt der Prozessortechnologie im Bereich der Virtualisierung besonders gut deutlich. Es vergleicht eine PRIMERGY RX200 S5 (mit Xeon X5570) mit dem Vorgängersystem. Konnte eine Web-VM beim Vorgängersystem durch Optimierung des Anwendungsszenarios noch eine Performance-Verbesserung von 86% erzielen, so sind dies bei der aktuellen Prozessorgeneration nur noch 28%. Aufgrund der »Extended Page Tables« (EPT) bewährt sich das System auch bei dem anspruchsvollen Lastprofil »STD-CGI« so gut, dass die Optimierungsreserve auf Seite des Anwendungsszenarios abschmilzt. Der Performance-Zuwachs beim Übergang von »STD-CGI« nach »MIN-CGI« ähnelt schon dem Wert für ein nicht virtualisiertes System.

Fazit für Optimierungen auf Seite des Anwendungsszenarios: Diese bleiben zwar interessant, aber der Nutzen ist in der gleichen Größenordnung wie bei einem nicht virtualisierten System.



Der zweite Optimierungsweg setzt unterhalb der Anwendungsebene in der VM an. Prinzipiell möglich sind Performance-Steigerungen sowohl durch entsprechende Prozessorfunktionalitäten, als auch durch einen geeigneten Hypervisor oder auch durch ein speziell auf den Hypervisor angepasstes Betriebssystem oder Treiber in der VM. Eine so angepasste VM unterstützt den Hypervisor aktiv in seiner Arbeit, wodurch sich der Virtualisierungs-Overhead teilweise signifikant reduzieren lässt.

Bei den Vorgängergenerationen der PRIMERGY Server brachte die Verwendung eines für die Virtualisierung angepassten Kernels für die Webserver-VM einen großen Performance-Gewinn. Das folgende Diagramm

vergleicht eine PRIMERGY RX200 S5 (mit Xeon X5570) mit dem Vorgängersystem für zwei Kernel unter dem Lastprofil STD-CGI. Der eine Kernel ist der unmodifizierte LINUX-Kernel, und der andere ist der angepasste Kernel.

Das Diagramm zeigt, dass mit einem aktuellen Prozessor der Xeon 5500 Serie die Qualität der Virtualisierungs-unterstützung durch den Prozessor mittlerweile so exzellent ist, dass eine solche Kernel-Anpassung hier nicht mehr zu empfehlen ist. Beim Vorgängersystem mit einem Xeon X5460 Prozessor war hierdurch noch eine Leistungssteigerung von 65% möglich.

Der unmodifizierte LINUX-Kernel (SMP) ist der Standard für die zuvor beschriebenen Messungen, sofern nichts anderes gesagt wurde.

Die virtualisierungsrelevanten Fortschritte in der Prozessortechnologie gegenüber dem Vorgängersystem wirken zum einen auf eine einzelne VM (z. B. durch EPT), und zum anderen auf die maximal mögliche Anzahl von VMs bis zur CPU-Sättigung (durch Hyper-Threading). Die folgende Gegenüberstellung arbeitet die Anteile der beiden Arten von Verbesserungen heraus. Verglichen werden ein Vorgängersystem mit 2 × Xeon E5420 (2.5 GHz) und eine PRIMERGY RX200 S5 mit 2 × Xeon E5540 (2.53 GHz), beide mit gleicher Anzahl von physikalischen Cores.

Man sieht also insgesamt eine Steigerung des vServCon-Scores um den Faktor 2.03. Die eine Ursache dafür ist die für eine einzelne VM realisierbare Performance-Steigerung um den Faktor 1.32 (siehe Score bei einer Tile). Die andere Ursache liegt darin, dass mehr Tiles möglich sind. Allerdings ist dies keine vollwertige Verdreifachung (von zwei Tiles auf sechs Tiles), da bei höheren Tile-Anzahlen der Performance-Zuwachs abflacht.

Es sei daher noch einmal ausdrücklich davor gewarnt, die durch den Score ausgedrückte gesteigerte Virtualisierungs-Performance komplett als Verbesserung für eine einzelne VM zu erhoffen. Mehr als etwa 30% - 50% mehr Durchsatz gegenüber einem gleich getakteten Prozessor der Vorgängergeneration ist hier nicht möglich.



Benchmark-Umgebung

Die Messungen wurden mit der im Folgenden beschriebenen Umgebung durchgeführt:


Load generator BX600

Disk-Subsystem FibreCAT CX500

vServCon Framework Controller

vServCon Benchmark Environment


Tile 1

VM

Web

VM

Data

base

VM

Java

VM

Idle

…

Tile n

VM

Web

VM

Data

base

VM

Java

VM

Idle

1 GBit LAN 1 GBit LAN

SUT-Hardware


Prozessor 2 × Xeon L5520 (2.27 GHz) 2 × Xeon E5520 (2.27 GHz) 2 × Xeon E5540 (2.53 GHz) 2 × Xeon X5550 (2.67 GHz) 2 × Xeon X5570 (2.93 GHz)

Speicher 48 GB (Je ein PC3-10600R, 8 GB, in DIMM-1A bis DIMM-1F)

Netzwerk-Interface 2 × 1-GBit LAN; eins für Load, eins für Control

Disk Subsystem Es wurden keine internen Festplatten verwen-det, 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 ST373454-Disks (15 krpm)

Storage-Anbindung Über FC-Controller Qlogic QLE 2460

SUT-Software

Betriebssystem Hypervisor VMware ESX Server

Version Version 4.0.0 build 157368

BIOS Version 6.00 R1.05A.2786; Default-Einstellungen

SUT: virtualisierungsspezifische Details

Webserver-VM-Kernel original

SLES10 SP2, 32-bit, 2.6.16.60-0.23-smp

Webserver-VM-Kernel angepasst

SLES10 SP2, 32-bit, 2.6.16.60-0.23-vmi (Kernel mit VMware-VMI-Interface)

Generelles Beschrieben im Benchmark Überblick vServCon


Modell Pro Tile 3 Server-Blades 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





Literatur

PRIMERGY Systems

http://de.ts.fujitsu.com/primergy

PRIMERGY RX200 S5

Datenblatt http://docs.ts.fujitsu.com/dl.aspx?id=c2be12e9-8512-4f72-8d12-805d2dc1c6d2

Speicher-Performance Xeon 5500 (Nehalem EP) basierter PRIMERGY Server http://docs.ts.fujitsu.com/dl.aspx?id=3ba9fc71-4b0d-493f-b842-02a1d3645be0

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

SPECcpu2006

http://www.spec.org/osg/cpu2006

Benchmark Überblick SPECcpu2006 http://docs.ts.fujitsu.com/dl.aspx?id=04351fd2-8a69-42a3-ba1c-4342dcc89b89

SPECjbb2005

http://www.spec.org/jbb2005

Benchmark Überblick SPECjbb2005 http://docs.ts.fujitsu.com/dl.aspx?id=e8477909-3a17-40dd-8c64-ff338b6457a0

StorageBench

Performance Report - Modular RAID für PRIMERGY http://docs.ts.fujitsu.com/dl.aspx?id=2d0d20d8-7c14-407c-b904-6112f4c7821c

iometer http://www.iometer.org

Terminal Server

Terminal Server Sizing Guide http://docs.ts.fujitsu.com/dl.aspx?id=278825c9-7644-49c1-9848-f2a5c8c694cd

Microsoft Windows 2008 und Terminal Services http://www.microsoft.com/windowsserver2008/en/us/ts-product-home.aspx

VMmark

Benchmark Überblick VMmark http://docs.ts.fujitsu.com/dl.aspx?id=95e9ef39-b40c-4168-8270-8dc457dcb740

VMmark http://www.vmmark.com

VMmark Resultate http://www.vmware.com/products/vmmark/results.html

vServCon

Benchmark Überblick vServCon http://docs.ts.fujitsu.com/dl.aspx?id=214ee9dc-9239-4985-86e4-f0f9ac78ea25

http://de.ts.fujitsu.com/primergy

http://docs.ts.fujitsu.com/dl.aspx?id=c2be12e9-8512-4f72-8d12-805d2dc1c6d2

http://docs.ts.fujitsu.com/dl.aspx?id=3ba9fc71-4b0d-493f-b842-02a1d3645be0

http://de.ts.fujitsu.com/products/standard_servers/primergy_bov.html

http://docs.ts.fujitsu.com/dl.aspx?id=743d7d46-56e8-41d2-9d50-9ab29ccf4d18

http://www.spec.org/osg/cpu2006

http://docs.ts.fujitsu.com/dl.aspx?id=04351fd2-8a69-42a3-ba1c-4342dcc89b89

http://www.spec.org/jbb2005

http://docs.ts.fujitsu.com/dl.aspx?id=e8477909-3a17-40dd-8c64-ff338b6457a0


http://www.iometer.org/


http://www.microsoft.com/windowsserver2008/en/us/ts-product-home.aspx

http://docs.ts.fujitsu.com/dl.aspx?id=95e9ef39-b40c-4168-8270-8dc457dcb740

http://www.vmmark.com/

http://www.vmware.com/products/vmmark/results.html

http://docs.fujitsu-siemens.com/dl.aspx?id=214ee9dc-9239-4985-86e4-f0f9ac78ea25


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-2010

Herausgegeben durch: Enterprise Products PRIMERGY Server PRIMERGY Performance Lab mailto:[email protected]

Internet:

http://ts.fujitsu.com/primergy

Extranet:

http://partners.ts.fujitsu.com/com/products/servers/primergy

Kontakt

PRIMERGY Hardware

PRIMERGY Product Marketing mailto:[email protected]

PRIMERGY Performance und Benchmarks

mailto:[email protected]


http://ts.fujitsu.com/primergy





Performance Report PRIMERGY RX200 S5 - …DE).pdf · Performance Report PRIMERGY RX200 S5 . ... und...

Documents

Transcript of Performance Report PRIMERGY RX200 S5 - …DE).pdf · Performance Report PRIMERGY RX200 S5 . ... und...