Opteron 280: Test mit Windows, Linux & VMware

In unserem Test des ersten Opteron 275 setzte die Dual-Core-CPU bei grafiklastigen Workstation-Anwendungen eindrucksvoll den Maßstab. Zwei 3,60-GHz-Xeons streiten sich bereits mit einem Dual-Core-Opteron um die Plätze. Nimmt ein zweiter Opteron 275 im System Platz, so ist die Konkurrenz bei multithreaded-programmierten Anwendungen chancenlos.

Jetzt legt AMD mit dem beschleunigten Opteron 280 für den Einsatz in Servern und Workstations nach. Der Prozessor für 2-Sockel-Systeme arbeitet mit 2,4 GHz Taktfrequenz – 200 MHz mehr als beim Vorgänger. Bei Intel markiert weiterhin der Xeon 3,60 GHz mit 2 MByte L2-Cache die Spitze für Systeme mit zwei CPUs. Bei AMDs Single-Core-Opterons gibt es mit dem Modell 254 inzwischen eine Variante mit 2,8 GHz Taktfrequenz als Top-Modell.

Im tecCHANNEL-Testlabor müssen sich die Prozessoren nun in Server-Szenarien bewähren. Neben der „puren“ Performance bei Integer- und Floating-Point-Berechnungen, die wir unter Windows Server 2003 und SUSE Linux 10 überprüfen, interessiert die Leistungsfähigkeit in virtualisierten Umgebungen. Bei der Virtualisierungslösung VMware ESX Server müssen die Prozessoren ihre Ressourcen auf mehrere Betriebssysteme verteilen. Dies gelingt den Probanten unterschiedlich gut.

Außerdem überprüfen wir die Performance der CPUs bei der multithreaded programmierten Open-Source-Datenbank MySQL. Im Server-Umfeld ist Linux sehr beliebt, für die MySQL-Benchmarks setzen wir deshalb auf SUSE Linux 10 RC1 in der 64-Bit-Version.

Details zum Opteron

AMD bietet die Dual-Core-Opteron-CPUs als Modelle 265, 270, 275 und 280 für 2-Wege-Systeme an. Für Server und Workstations mit maximal acht CPUs gibt es die entsprechenden Modelle Opteron 8xx. Die Prozessoren für den Socket 940 arbeiten mit Taktfrequenzen von 1,8 (x65) bis 2,4 GHz (x80). Jeder Prozessorkern besitzt bei den Dual-Core-Opterons einen 1 MByte großen L2-Cache.

Mit den Opterons 260 HE und 265 HE sowie 860 HE und 865 HE produziert AMD stromsparende Varianten des Dual-Core-Opterons. Den TDP-Wert spezifiziert der Hersteller auf 55 Watt. Die Standard-Dual-Core-Opterons gibt AMD mit 95 Watt TDP an. Die Fertigung aller Doppelkern-Opterons erfolgt in einem 90-nm-Prozess mit SOI-Technik.

Für 1-Sockel-Systeme bietet AMD seit August 2005 die Dual-Core-Opterons 165 bis 175 an – ein Modell 180 ist ab Ende Oktober 2005 verfügbar. Diese CPUs nehmen ausschließlich im Socket 939 der Athlon-64-Prozessoren Platz. Bei allen Opterons-Serien erfolgt die Kommunikation zwischen den CPUs sowie zur Peripherie über HyperTransport-Schnittstellen mit 1000 MHz Taktfrequenz. Beim Speicher adressieren die 200er und 800er Opterons Dual-Channel-DDR400-Module in gepufferter Ausführung. Die Opteron-100-Modelle für den Socket 939 steuern ungepufferte DIMMs an.

In der Tabelle haben wir für Sie alle Single- und Dual-Core-Opteron-Modelle zusammengefasst.

Ausführliche Grundlagen über die AMD64-Architektur des Opteron können Sie ebenfalls bei tecCHANNEL nachlesen.

Details zum Xeon

Intel bietet den Xeon DP auf Irwindale-Basis mit vier Modellen von 3,00 bis 3,60 GHz Taktfrequenz an. Der L1-Daten-Cache mit 16 KByte bleibt gegenüber dem Vorgänger „Nocona“ unverändert, der L2-Cache verdoppelte sich von 1 auf 2 MByte. Die Irwindale-Xeons sind durch ein an die Taktfrequenz angehängtes „E“ in der Modellbezeichung zu erkennen.

Auf einen L3-Cache müssen die Irwindale-CPUs weiterhin verzichten. Der Prozessorbus arbeitet unverändert zum Nocona mit 800 MHz. Die Fertigung des Irwindale erfolgt in einem 90-nm-Prozess. Allen Xeon-DP-Prozessoren gemeinsam ist die Hyper-Threading-Technologie sowie der Socket 604.

Die Xeon-Modelle mit Irwindale- und Nocona-Core werden für eine Übergangszeit parallel von Intel angeboten. Bei den Nocona-Xeons mit 2,80, 3,00 und 3,20 GHz fügt Intel noch ein „D“ an die Taktfrequenz an. Dies soll die Unterscheidung zu den früheren Gallatin-Xeons erleichtern, die es ebenfalls mit diesen Taktfrequenzen gab.

In der Tabelle finden Sie alle von Intel angebotenen Xeon-CPUs für 2-Sockel-Systeme im Überblick.

Windows 32 Bit: SPECint_base2000

Wir setzen die SPEC-Benchmarks unter Windows Server 2003 praxisnah ein und kompilieren sie für das Base-Rating. Dazu verwenden wir Intel C++ 9.0 und MS Visual Studio .NET für alle Integer-Tests. Für alle Prozessoren finden Sie die bei den Benchmarks verwendeten CPU2000-Config-Files im Artikel SPEC CPU2000 Config-Files.

Der SPECint_base2000-Benchmark arbeitet singlethreaded und nutzt die Vorteile von Hyper-Threading und Dual-Core nicht. Die ermittelten Werte gelten als Indiz für die Integer-Performance der Prozessoren.

In der Tabelle finden Sie die Einzelergebnisse des SPEC-CPU2000-Integer-Benchmarks der wichtigsten Prozessoren im Vergleich:

Windows 32 Bit: SPECint_rate_base2000

Bei den Integer-Berechnungen von SPECint_rate_base2000 ermittelt die Benchmark-Suite den maximalen Durchsatz durch Verwendung mehrerer Tasks. Dabei arbeiten multiple Kopien des Benchmarks parallel. Typischerweise entspricht die Anzahl der Tasks/Kopien der Anzahl der - virtuellen - Prozessoren des Systems.

So läuft SPECint_rate_base2000 beim Opteron 254 mit einer Kopie, beim Opteron 280 (Dual-Core) und Xeon (Hyper-Threading) mit zwei Kopien. Bei zwei Opteron 280 (insgesamt 4 Cores) und zwei Xeons (jeweils zwei virtuelle CPUs durch HT) sind vier Kopien im Einsatz. Bei diesem Test wird der Vorteil von Dual-Core und einem zweiten Prozessor ausgenutzt. Bei Single-Core-Prozessoren wie dem Opteron 254 führen SPECint_rate_base2000-Tests mit einer und zwei Kopien zum gleichen Ergebnis - der maximale Durchsatz bleibt unverändert.

Zusätzlich haben wir das Xeon-Irwindale-Doppelpack mit ausgeschaltetem Hyper-Threading getestet. Hier sinkt der SPECint_rate_base2000-Wert von 38,6 auf 37,8 Punkten. Hyper-Threading führt somit zu zwei Prozent mehr Performance.

Windows 32 Bit: SPECfp_base2000

Wir setzen die SPEC-Benchmarks unter Windows Server 2003 praxisnah ein und kompilieren sie für das Base-Rating. Dazu verwenden wir Intel C++ 9.0 und MS Visual Studio sowie Intel Fortran 9.0 für alle Fließkommatests. Für alle Prozessoren finden Sie die bei den Benchmarks verwendeten CPU2000-Config-Files im Artikel SPEC CPU2000 Config-Files.

Der SPECfp_base2000-Benchmark arbeitet single-threaded und nutzt die Vorteile von Hyper-Threading und Dual-Core nicht. Die ermittelten Werte gelten als Indiz für die Floating-Point-Performance der Prozessoren.

AMDs Opteron-Prozessoren beherrschen wie die Intel-CPUs SSE3. Die Intel-Compiler verweigern aber mit eingestellter SSE3-Optimierung -QxP/fast die Zusammenarbeit mit den AMD-CPUs. Wir testen die AMD64-Prozessoren mit dem Compiler-Switch -QxW mit SSE2-Unterstützung.

Zwar lässt sich die Prozessorabfrage bei den Intel-Compilern per Patch „umgehen“, doch nach den strengen SPEC-Regeln dürfen nur Ergebnisse mit offiziell verfügbarerer Hard-/Software publiziert werden. So unterstützt Intel dieses „umgehen“ der CPU-Abfrage bei seinen Compilern nicht, wie der Hersteller mitteilt.

In der Tabelle finden Sie die Einzelergebnisse des SPEC-CPU2000-Floating-Point-Benchmarks der wichtigsten Prozessoren im Vergleich:

Windows 32 Bit: SPECfp_rate_base2000

Bei den Floating-Point-Berechnungen von SPECfp_rate_base2000 ermittelt die Benchmark-Suite den maximalen Durchsatz durch Verwendung mehrerer Tasks. Dabei arbeiten multiple Kopien des Benchmarks parallel. Typischerweise entspricht die Anzahl der Tasks/Kopien der Anzahl der - virtuellen - Prozessoren des Systems.

So läuft SPECfp_rate_base2000 beim Opteron 254 mit einer Kopie, beim Opteron 280 (Dual-Core) und Xeon (Hyper-Threading) mit zwei Kopien. Bei zwei Opteron 280 (insgesamt 4 Cores) und zwei Xeons (jeweils zwei virtuelle CPUs durch HT) sind vier Kopien im Einsatz. Bei diesem Test wird der Vorteil von Dual-Core und einer zweiten CPU ausgenutzt. Bei Single-Core-Prozessoren wie dem Opteron 254 führen SPECfp_rate_base2000-Tests mit einer und zwei Kopien zum gleichen Ergebnis - der maximale Durchsatz bleibt unverändert.

Zusätzlich haben wir das Xeon-Irwindale-Doppelpack mit ausgeschaltetem Hyper-Threading getestet. Jetzt steigt der SPECfp_rate_base2000-Wert von 26,8 auf 31,0 Punkten. Das Deaktivieren von Hyper-Threading führt in diesem Fall zu einer Performance-Steigerung von 16 Prozent. Bei den Integer-Tests wird der Xeon ohne Hyper-Threading langsamer.

Linux 64 Bit: Integer-Performance

Die modulare Benchmark-Suite SysBench für Linux ist multithreaded konzipiert. Neben dem Test von Datenbanken eignet sich SysBench zur Überprüfung der Integer-Performance der Prozessoren, des Speicherdurchsatzes oder der Scheduler-Performance des Betriebssystems.

Beim CPU-Test von SysBench berechnet der Benchmark die Primzahlen bis zu einer wählbaren Obergrenze. In unserem Fall lassen wir alle Primzahlen bis 100.000 berechnen. Als Ergebnis übergibt SysBench die benötigte Zeit. Die Berechnung der Primzahlen erfolgt mit 64-Bit-Integer-Operationen.

Die Thread-Anzahl ist beim CPU-Test von SysBench konfigurierbar. Wir führen den Benchmark mit einem und acht Threads durch. Damit wird der Vorteil sichtbar, den Hyper-Threading, Dual-Core oder ein zweiter Prozessor erwirken. Die Anzahl der Threads sollte bei diesem Test mindestens der Anzahl – virtueller – Prozessoren besitzen.

Linux 64 Bit: Floating-Point-Performance

Der Linpack-Benchmark wurde in den 70er Jahren ursprünglich für Supercomputer entwickelt. Bis heute dient Linpack aber als verbreitetes Tool zum Ermitteln der Floating-Point-Performance von Highend-Computern. Das Ergebnis wird in Flops (Fließkomma-Operationen pro Sekunde) angegeben.

Linpack löst komplexe lineare Gleichungssysteme. Die Anzahl der Gleichungen lässt sich dabei stark erhöhen, um auch massiv parallel operierende Systeme unter Last zu setzen. Der Bedarf an Arbeitsspeicher wächst entsprechend mit. Die Speicherzuweisung erfolgt über eine Matrix-Berechnung. Size x LDA x 8 (Anzahl der Gleichungen x Input x 8 bit) ergibt den zu allokierenden Speicher.

Unter SUSE Linux 10.0 64-Bit-Edition setzen wir die 64-Bit-Version von Linpack 2.1.2 ein. Der SMP-fähige Benchmark setzt EMT64-Prozessoren mit SSE3-Unterstützung voraus. AMDs Opteron-Prozessoren mit SSE3 arbeiten mit der Intel-kompilierten Linpack-Version ebenfalls problemlos zusammen.

Bei unseren Tests löst Linpack in verschiedenen Durchläufen 5000, 10.000, 15.000, 18.000 und 22.000 Gleichungssysteme. Damit benötigt der Benchmark zwischen 190 MByte (5000 Gleichungssysteme) und zirka 3,6 GByte Arbeitsspeicher (22.000 Gleichungssysteme). Im Diagramm finden die von den Prozessoren maximal erreichten GFlops.

Die Tabelle zeigt die erreichten GFlops bei den jeweils zu lösenden Gleichungssystemen. Mit zunehmender Gleichungsgröße – und somit Arbeitsspeicherbedarf – steigt die GFlops-Leistung bis zu einem Peak-Wert leicht an.

Am Ende der Tabelle finden Sie zwei Xeon 3,60 GHz 2M L2 mit deaktiviertem Hyper-Threading. Das Doppelpack ist ohne HT mit maximal 12,49 GFlops zirka 28 Prozent schneller. Bei diesem Test wirkt Hyper-Threading stark bremsend.

Linux 64 Bit: MySQL singlethreaded

Die Datenbank MySQL liefert seine eigene Benchmark-Suite. Das integrierte sql-bench stresst mit einer Vielzahl an Operationen die Open-Source-Datenbank. Unterschiedliche Datenmanipulationen aus insert, update, delete sowie Zugriffsmessungen via select in Verbindung mit count und distinct laufen gegen die Datenbank. Verbindungsaufbau, Tabellen anlegen, löschen und verändern sind ebenfalls enthalten.

Zum Einsatz kam die in SUSE Linux 10.0 64-Bit enthaltene Datenbank MySQL 4.1.13 in der x86_64-Version. Für den Test der Prozessoren wurden an der Datenbank keine Veränderungen oder Tunings vorgenommen.

Der Benchmark sql-bench von MySQL arbeitet singlethreaded und nutzt somit die Vorteile von Hyper-Threading, Dual-Core oder einem zweiten Prozessor nicht aus.

Linux 64 Bit: MySQL multithreaded

Die Open-Source-Datenbank MySQL ist multithreaded ausgelegt. Wie die Datenbank von mehrerer Prozessoren und Technologien wie Dual-Core oder Hyper-Threading profitiert, lässt sich mit SysBench überprüfen. SysBench ist ein modularer multithreaded ausgelegter Benchmark zum Testen von Datenbanken unter intensiver Last.

Bei SysBench lassen sich Parameter wie die Anzahl der Threads oder die Größe der Datenbank festlegen. Für unsere MySQL-Benchmarks verwenden wir eine Datenbank mit 100.000 Einträgen. Bei dieser Größe sind Festplattenzugriffe vernachlässigbar und das Storage-Subsystem wird nicht zum begrenzenden Faktor.

Wir erhöhen bei den Multithreading-MySQL-Benchmarks die Anzahl der Threads von 1 bis 64. Hier zeigt sich bei welcher Kombination von Thread-Anzahl und Prozessor MySQL den optimalen Durchsatz erreicht. Ein Thread entspricht dabei den Anfragen eines Clients auf die Datenbank. Damit lässt sich die Aussage treffen, ab wie vielen Clients die Datenbank-/Prozessor-Kombination optimal arbeitet und wann die Performance einbricht.

SysBench gibt als Ergebnis die erzielten Transaktionen der Datenbank pro Sekunde aus.

Die CPU-Auslastung bei zwei Opteron 280 beträgt insgesamt im Maximum zirka 65 Prozent. Auch zwei Xeons übersteigen die 65-Prozent-Marke kaum. Ein Xeon 3,60 GHz 2M L2 erreicht bereits bei 4 Threads eine CPU-Auslastung von über 80 Prozent, ab 8 Threads über 90%. Ein Opteron 280 überschreitet durch seine Dual-Core-Technologie selbst im Maximum nur knapp 80 Prozent. Ist dagegen ein Single-Core-Opteorn-254 im Einsatz, so beträgt die CPU-Auslastung 98 bis 100 Prozent.

Systeme mit zwei Prozessoren bieten bei MySQL somit noch Reserven bei weiter steigender Anzahl von Clients.

Linux 64 Bit: MySQL große Datenbanken

Welchen Einfluss die Prozessoren auf die Performance von MySQL bei sehr großen Datenbanken haben, überprüfen wir mit dem modularen SysBench.

SysBench erlaubt frei wählbare Größen der Datenbank. Für unsere MySQL-Benchmarks verwenden wir eine Datenbank mit 1 und 10 Millionen Einträgen. Bei diesen Größen greift die Datenbank bereits verstärkt auf das Storage-Subsystem zurück. Die Thread-Anzahl legen wir bei den SysBench-1M- und 10M-Tests jeweils auf acht fest.

Bei den 1M-Test wird das Storage-Subsystem schon zum begrenzenden Faktor, es gibt zunehmend Aktivitäten auf der Festplatte. Ein zweiter oder schnellerer Prozessor bewirkt bei dieser Datenbankgröße nicht mehr viel. So liegt die CPU-Auslastung bei zwei Opteron 280 insgesamt nur bei zirka 30 Prozent. Bei einem Opteron 280 erreicht sie dagegen gut 60 Prozent. Ein Xeon 3,60 GHz 1M L2 besitzt bereits eine mittlere CPU-Auslastung von knapp 80 Prozent. Die Single-Core-CPU Opteron 254 arbeitet unter voller Last.

Durch seine geringe CPU-Auslastung von 30 Prozent ist das Opteron-280-Doppelpack beim 1M-Test auch langsamer als ein 280er, weil die Threads auf insgesamt vier Cores aufgeteilt werden. Der einzelne Opteron 280 teilt die Threads auf seine beiden integrierten Kerne auf und es wird weniger Scheduler-Overhead produziert. Außerdem erfolgt die Kommunikation durch den internen Crossbar-Switch zwischen den Kernen deutlich schneller, als wenn zwei 280er sich zusätzlich noch über die HyperTransport-Schnittstelle abstimmen.

VMware ESX-Server

Zur Analyse der Performance von virtualisierten Plattformen mit Opteron- und Xeon-Prozessoren verwenden wir die Virtualisierungslösung VMware ESX Server. Die Software erlaubt die Installation von verschiedenen – voneinander unabhängigen – Betriebssystemen wie Windows XP oder Linux. Jede virtuelle Maschine (VM) besitzt ihre „eigene“ abgeschottete Hardware.

VMware ESX Server selbst basiert auf einem Linux-Kernel und operiert als eigenes Betriebssystem. Im Gegensatz zu Lösungen wie VMware Workstation, GSX Server oder Microsofts VirtualPC wird kein zusätzliches Host-Betriebssystem benötigt.

Die Ansteuerung des ESX Servers erfolgt via Ethernet-Verbindung über den Web-Browser eines beliebigen Rechners. Hier lassen sich die virtuellen Maschinen auch Einrichten, Starten und Benutzen.

Für den Test der Prozessor-Performance in der virtualisierten Umgebung setzen wir auf die Version 2.5.2 des ESX Server. Damit unterstützt die VMware-Software bereits AMDs Dual-Core-Opterons. Hyper-Threading der Xeon-Prozessoren wird von GSX Server ebenfalls ausdrücklich genutzt. Zusätzlich ist VMware Virtual SMP aktiv. Das ESX-Server-Modul ermöglicht einer virtuellen Maschine den Zugriff auf mehrere physikalische Prozessoren.

Wir installieren auf dem ESX Server 2.5.2 acht identische virtuelle Maschinen. Jede VM erhält 512 MByte Arbeitsspeicher sowie eine 4 GByte große virtuelle Partition. ESX Server erlaubt pro VM wahlweise eine oder zwei virtuelle CPUs. Bei unserer Konfiguration wählen wir jeweils zwei virtuelle Prozessoren pro VM. Als Betriebssystem für die virtuellen Maschinen kommt jeweils SUSE Linux 9.3 Professional in der 32-Bit-Version zum Einsatz.

ESX Server arbeitet bei den Tests mit der Standard-Konfiguration ohne spezielle Server-Tuning-Parameter. Jede virtuelle Maschine erhält die gleichen CPU-Prioritäten. Die VMware-Software sorgt dabei für eine dynamische Lastverteilung.

Die Benchmarks lassen wir zuerst auf einer VM, dann jeweils parallel auf zwei, drei, vier bis hin zu schließlich zehn virtuellen Maschinen laufen. Damit überprüfen wir, wie stark die Performance einbricht, wenn mehrere VMs parallel die Plattform belasten.

VMware ESX Server: MySQL-Performance

Die Datenbank-Performance von MySQL 4.1.10. in den virtuellen Maschinen überprüfen wir mit dem Benchmark-Skript „test-insert“ aus der MySQL-Benchmark-Suite „sql-bench“. Die Open-Source-Datenbank sowie sql-bench sind Bestandteil von SUSE Linux 9.3 Professional, das jeweils als Betriebssystem in den VMs agiert.

Das Benchmark-Skript test-insert wählten wir aufgrund der minimalen Zugriffe auf die Festplatte. Damit stellen wir sicher, dass bei mehreren parallel arbeitenden VMs das Storage-Subsystem nicht zum begrenzenden Faktor wird. Das perl-Skript test-insert agiert mit einer 100.000 Einträge umfassenden Datenbank.

Eine VM beansprucht das Opteron-280-Doppelpack insgesamt mit bis zu 40 Prozent CPU-Auslastung. Alle vier Kerne sind dabei der virtuellen Maschine zugewiesen. Bei einer aktiven VM benötigt der ESX Server kaum Ressourcen für die Virtualisierung – maximal ein Prozent der Rechenleistung.

Arbeiten fünf VMs parallel, so weist ESX Server bei zwei Opteron 280 oder zwei Xeon 3,60 GHz 2M L2 jeder VM beim MySQL-Benchmark durchschnittlich 16 Prozent der CPU-Ressourcen zu. Bei acht aktiven virtuellen Maschinen teilt ESX Server bei zwei Opteron 254 den VMs jeweils zirka 10 Prozent zu. Die restlichen 20 Prozent benötigt die VMware-Lösung für die virtuellen Services sowie als „Reserve“.

VMware ESX Server: Analyse Opteron

Die MySQL-Performance der Opterons ist auf einem physikalischen Server um den Faktor vier schneller. Der Ansatz von ESX Server ist aber nicht eine optimale Performance und Auslastung des Systems bei nur einer virtuellen Maschine. Die VMware-Lösung sorgt bei einer Vielzahl von VMs für die optimale Auslastung eines Servers.

Aus unseren Messungen wird auch deutlich, dass der ESX Server optimal arbeitet, wenn die Workloads der einzelnen VMs den Prozessor und Speicher nur mäßig auslasten. Arbeiten dann viele VMs parallel, so sorgen diese für eine insgesamt optimale Auslastung des Servers. Workloads mit sehr hohen Anforderungen an die CPU und die Speicherbandbreite sind auf dedizierten physikalischen Servern nach wie vor besser aufgehoben.

Beim ESX Server bieten ein und zwei Opteron 280 bei nur einer aktiven VM die annähernd identische Performance beim MySQL-Benchmark. Ab zwei VMs bricht die Datenbankgeschwindigkeit bei einem Opteron 280 dagegen deutlich schneller ein. Bei fünf parallel agierenden virtuellen Maschinen arbeitet ein 280er wieder schneller als zwei Dual-Core-Opterons. Das Ressourcen-Management von ESX Server behält bei der 2-Wege-Konfiguration mehr Rechenleistung in Reserve. Mit zwei Opteron 280 bleibt die MySQL-Performance bei sieben und acht parallel arbeitenden VMs praktisch noch identisch – erst ab 9 VMs erfolgt langsam der Einbruch. Ein einzelner Opteron 280 bricht bereits bei acht VMs wieder verstärkt ein.

Die Performance-Kurve von zwei Opteron 254 (Single-Core) liegt annähernd parallel zu einem 280er Dual-Core-Opteron. Durch ihre 400 MHz höhere Taktfrequenz arbeiten die zwei 2,8-GHz-CPUs zwischen sieben und 20 Prozent schneller als ein Opteron 280.

VMware ESX Server: Analyse Xeon

Auffällig bei den Linux-Datenbank-Benchmarks ist die deutlich höhere Performance der Opteron-Plattform mit VMwares ESX Server im Vergleich zu den Xeons. Zwei Opteron 254 arbeiten beispielsweise bei einer aktiven VM um den Faktor 2,4 schneller als zwei Xeon 3,60 GHz 2M L2. Ohne ESX Server direkt unter Linux sind die Opterons nur 1,4-mal flinker.

Erzeugen im ESX Server acht VMs gleichzeitig Last, sorgt das Opteron-254-Doppelpack für eine immer noch 1,5-mal so hohe Performance als die Xeons. Die Xeon-Prozessoren halten dafür ab vier VMs die annähernd identische Leistung aufrecht.

Die Irwindale-Xeons bieten beim Datenbank-Benchmark direkt unter Linux zirka die siebenfache Performance als mit VMwares ESX Server in einer aktiven Linux-VM. Arbeiten 10 VMs parallel, so dauert der MySQL-Benchmark in jeder VM auch knapp 10-mal so lang als direkt unter Linux ohne ESX Server. Doch insgesamt ist Durchsatz in den 10 VMs vergleichbar mit der erbrachten Leistung einer Datenbank direkt unter Linux.

Sind die zwei Xeon 3,60 GHz 2M L2 dagegen nur mit fünf VMs beschäftigt, so beträgt deren summierte Performance nur die Hälfte der singulären MySQL-Leistung ohne ESX Server. Damit die Gesamt-Performance aller VMs mit der Geschwindigkeit des physikalischen Servers vergleichbar wird, sollten beim Irwindale-Doppelpack mindestens acht bis zehn VMs im Einsatz sein. Bei den Opterons stellt sich dieses Verhältnis bereits ab der siebten virtuellen Maschine ein.

Bei den 3,60-GHz-Xeons wirkt sich die L2-Cache-Verdopplung von 1 auf 2 MByte deutlich auf die Geschwindigkeit in den VMs aus. Die Irwindale-Xeons mit 2 MByte L2-Cache sorgen beim ESX Server für eine zirka 30 Prozent höhere Performance im Vergleich zu den Nocona-Modellen. Auf einem physikalischen Server mit Linux arbeitet der Xeon 3,60 GHz 2M L2 beim MySQL-Benchmark dagegen maximal acht Prozent schneller als der Nocona-Xeon (1M L2). Seinen größeren L2-Cache nutzt der Irwindale-Xeon somit gewinnbringend zum Puffern von Virtualisierungs-Routinen.

Cache/Speicher: 32-Bit-Transfer

Die Cache- und Speicher-Performance der Prozessoren überprüfen wir mit unserem Programm tecMem aus der tecCHANNEL Benchmark Suite Pro unter Windows Server 2003. tecMem misst die effektiv genutzte Speicherbandbreite zwischen der Load-/Store-Unit der CPU und den unterschiedlichen Ebenen der Speicherhierarchie (L1-, L2-Cache und RAM). Die Ergebnisse erlauben eine getrennte Analyse von Load-, Store- und Move-Operationen.

Cache/Speicher: 64-Bit-Transfer

Hier testen wir mit tecMem die Performance mit den 64-Bit-Load und -Store-Kommandos aus dem MMX-Befehlssatz. Die Transferrate ist hier schon deutlich höher als bei den 32-Bit-Kommandos, da die CPU mit jedem Befehl mehr Daten transferieren kann.

Cache/Speicher: 128-Bit-Transfer

Mit den 128-Bit-SSE-Befehlen lässt sich die maximale Cache- und Speicher-Performance ermitteln, die eine CPU erreichen kann.

Listenpreise

Hinsichtlich der Preise empfiehlt es sich, gelegentlich einen Blick auf die offiziellen Listen der CPU-Hersteller zu werfen. Bei AMDs Preisliste gab es am 26. September 2005 die letzten Änderungen. Intels Preisliste wurde am 11. September 2005 aktualisiert.

Die 1000er Preise in den Tabellen sind auch ein Anhaltspunkt für die deutschen/europäischen Endkundenpreise in Euro. Unter Berücksichtigung der Mehrwertsteuer und einer Händlermarge ergibt sich annähernd dieses Preisgefüge. Nachfolgend finden Sie einen Link zu den aktuellen Endkundenpreisen.

Fazit

AMDs Opteron 280 mit Dual-Core-Technologie ist bei 2-Wege-Systemen momentan das Maß der Dinge. Sobald multithreaded programmierte Anwendungen ins Spiel kommen, bleibt den mit höherer Taktfrequenz arbeitenden Single-Core-Modellen keine Chance – egal ob Xeon 3,60 GHz oder Opteron 254.

Gerade im Serverumfeld sind Singlethread-Programme oder Single-Task-Szenarien längst passé. Beispielsweise wenn von vielen Clients gleichzeitig Anfragen an eine Datenbank auf dem Server erfolgen. So erreicht der Dual-Core-Opteron-280 unter Linux bei der SMP-fähigen MySQL-Datenbank sowohl in der 1- als auch 2-Wege-Konifguration die meisten Transaktionen pro Sekunde. Im Vergleich der Single-Core-Modelle wechseln sich der Xeon 3,60 GHz und Opteron 254 ab – die Unterschiede sind nicht weltbewegend.

Für eine Überraschung sorgte die deutlich höhere Performance der Opteron-Plattform mit der Virtualisierungslösung VMware ESX Server. Egal ob Opteron 254 oder 280, die 3,60-GHz-Xeons mit 2 MByte L2-Cache erreichen hier teilweise nur die halbe Performance. Dabei arbeiten die Irwindale-Xeons durch ihren größeren Cache bereits 30 Prozent schneller als die Nocona-Xeons mit 1 MByte L2-Cache.

Bei VMwares ESX Server gibt es durch die Multi-User-Workloads eine massive Speicheraktivität. Hier profitieren die Opterons von den geringen Latenzzeiten ihrer integrierten Memory-Controller optimal. Bei Intels Xeon-Plattform sind beide CPUs über einen gemeinsamen FSB mit dem Chipsatz verbunden und greifen darüber auf den Speicher zu. Dadurch erhöhen sich die Latenzzeiten und das Bus-Sharing schränkt die Bandbreiten ein.

Nicht ohne Grund erhält bei Intels nächster Xeon-Plattform “Bensley” (Launch: Q1 2006) jeder Prozessor seinen eigenen FSB. Zudem stehen dann vier FB-DIMM-Speicherkanäle zur Verfügung. Virtualisierungsszenarien wie mit dem ESX Server sollten davon deutlich profitieren. Zudem unterstützen die Xeons mit Vanderpool dann auch die Virtualisierung auf CPU-Ebene unterstützen.

Noch im vierten Quartal 2005 führt Intel mit dem Paxville DP für vorhandene Plattformen die Dual-Core-Technologie bei den Xeons ein. Damit dürfte Intel den Dual-Core-Opterons wieder etwas mehr fordern. (cvi)

Testkonfiguration

Für den Test der Opteron-CPUs von AMD verwenden wir ein Tyan K8WE mit NVIDIAs nForce-Professional-Chipsatz. Über ihren integrierten Memory-Controller greifen die CPUs auf Dual-Channel-DDR400-SDRAM mit CL3 zurück. Die verwendeten Corsair-Module sind dabei gepuffert ausgeführt.

Irwindale- und Nocona-CPUs nehmen in einem Supermicro X6DA8-G2 Platz. Das Mainboard für zwei Prozessoren verwendet Intels E7525-Chipsatz und unterstützt DDR2-400-SDRAM in einer Dual-Channel-Konfiguration. Bei den Speichermodulen setzen wir auf Registered DIMMs PC2-3200R von Infineon mit einer CAS-Latency von 3.

Um die gleiche Testkonfigurationen zu gewährleisten, stehen den Prozessoren jeweils 4 GByte Arbeitsspeicher zur Verfügung. Einheit herrschte auch beim Massenspeicher, der sich aus Ultra320-SCSI-Festplatten mit 10.000 U/min aufbaut. Anschluss finden die Laufwerke an Adaptecs 2200S SCSI-RAID-Controller mit 64 MByte Cache.