Databasetest: achtvoudige Opteron

Inleiding

For your convenience, an English translation of this article is available.

Computers met x86-processors zijn er in veel verschillende soorten en maten, van dunne notebooks voor zakenlui tot neon-gepimpte desktops voor gamers. Eén van de bruutste uitwassen van de familie is echter toch wel de Sun Fire X4600, een server die tot acht dualcore Opterons in een kast kan huisvesten. Vergeleken met deze machine lijkt alles wat we eerder getest hebben kinderspeelgoed. Maar is het wel mogelijk om zestien cores effectief te gebruiken? En zo ja, werkt het ook goed genoeg om de prijs van meer dan 35.000 euro te kunnen goedpraten? Op die vragen proberen we in deze review een antwoord te geven.

Marktverdeling

Wereldwijd worden er ieder kwartaal zo'n 1,8 miljoen x86-servers verkocht. Ongeveer 95% daarvan is het standaard soort dat we al vaker hebben getest en gebruikt, met één of twee processors aan boord. Deze worden veel ingezet als web-, mail-, file-, print- of proxy/firewall-doosjes, maar doen ook wel (licht) database- en applicatiewerk. Voor veel kleinere bedrijven is dit alles wat ze ooit nodig zullen hebben. Van de ongeveer 90.000 overgebleven servers heeft het overgrote deel vier sockets. Dit zijn doorgaans machines die worden ingezet voor groupware, ERP, CRM en andere 'enterprise'-achtige software waar vele honderden tot enkele duizenden mensen dagelijks mee moeten werken. Er blijven nog maar ongeveer 1500 stuks over met acht of meer processors, die alleen voor de allerzwaarste en/of -belangrijkste taken ingezet worden. In dit segment concurreert x86 met Itanium, Power en UltraSparc, die specifiek ontworpen zijn voor het meest veeleisende werk.

Server share per 'way' Hoewel er dus relatief weinig zware x86-servers verkocht worden, geldt voor servers dezelfde regel als voor andere markten: hoe duurder de uitvoering, hoe beter de marge. Meestal gaat de aanschaf van een zware server gepaard met een dik opslag- en/of backup-systeem, software en servicepakket of andere diensten zoals consultancy. De verkoop van deze machines brengt dan ook meer geld in het laatje dan puur op basis van de aantallen verwacht zou kunnen worden. Meer dan de helft van de mondiale serveromzet (de som van x86, Itanium en RISC) komt uit systemen met vier of meer sockets, terwijl deze klasse in aantallen net de 15% bereikt. Het gaat dan overigens puur om hardware: diensten en software komen er nog bovenop.

Het AMD-voordeel

De Opteron heeft in een paar jaar tijd behoorlijk wat marktaandeel weggesnoept van de eens zo dominante Xeon. Nergens anders wist AMD echter zo veel schade aan te richten als in het segment van servers met vier processors. Wereldwijd heeft het meer dan veertig procent van deze markt in handen en binnen de VS zelfs meer dan vijftig procent. Dit terwijl het totale aandeel van de Opteron pas net boven een kwart uitsteekt. De reden hiervoor is dat het platform van AMD naadloos op kan schalen van twee naar vier processors. Sockets kunnen rechtstreeks aan elkaar geknoopt worden met geïntegreerde HyperTransport-links en omdat iedere chip zijn eigen geheugencontroller heeft ontstaat er nooit een tekort aan bandbreedte. Dit staat in scherp contrast met Intel Xeons, die alleen via een dure chipset samen kunnen werken en een beperkte bandbreedte moeten delen. Op dit moment heeft een systeem met vier Xeon MP 'Tulsa' processors op Intels E8501-chipset bijvoorbeeld maar 12,8GB/s tot zijn beschikking, tegenover 42,7GB/s voor een viervoudige Socket F Opteron. En geloof het of niet, maar dit is een enorme verbetering boven de oude Xeon-chipset waar AMD de eerste twee jaar van zijn serveravontuur ~~tegenop moest boksen~~ overheen kon walsen.


	Totale bandbreedte 4-way servers (GB/s)

	Xeon MP (2002-2005)	3,2

	Opteron (2003-2006)	25,6

	Xeon MP (2005-2007)	12,8

	Opteron (2006-...)	42,7

	Xeon MP (2007-...)	34,1

Aan beide kanten van het strijdveld zijn wel een paar kanttekeningen te maken: ten eerste kunnen de HyperTransport-links van AMD ook niet onbeperkt opschalen. Er wordt namelijk een simpel 'broadcast'-protocol gebruikt om de caches van alle cores synchroon te houden. Dit betekent dat iedere processor continu met iedere andere processor aan het praten is, zelfs als ze met compleet verschillende taken bezig zijn. Dit onderlinge geklets veroorzaakt vertraging omdat een core in principe niets kan doen met een stukje data voor alle andere cores hebben bevestigd dat er ondertussen geen wijziging op is uitgevoerd. Hoe meer chips (of beter gezegd: hoe groter de langste afstand in het netwerk) - hoe hoger de latency wordt. Hoewel de invloed op de prestaties met vier sockets nog te overzien is, zijn er benchmarks met acht sockets waarbij het effect duidelijk te merken is.

De Xeon hoeft ondertussen niet altijd zo kreupel te zijn als hij met Intels eigen chipset is: met hulp van IBM's X3 'Hurricane' kunnen tot 32 Xeons vrij effectief met elkaar samenwerken. Dit gebeurt door op chipsetniveau een netwerk tussen de processors aan te leggen, iets wat de Opteron rechtstreeks doet. Het verschil is echter dat de X3-chipset het een en ander wat intelligenter aanpakt; zo laat hij bijvoorbeeld niet twee processors met elkaar praten als die niet met dezelfde data bezig zijn. Een poging van Newisys om zo'n filterende chipset voor de Opteron te bouwen is helaas nooit op de markt gekomen, maar het gerucht gaat nu dat AMD deze techniek in de processor zelf wil gaan integreren.

Trends

Er zijn verschillende trends gaande die de positie van 4-way en 8-way servers beïnvloeden. Aan de ene kant staan consolidatie en virtualisatie. De eerste term houdt in dat meerdere applicaties op één systeem gaan draaien, zodat ruimte, stroom en kosten worden bespaard. Virtualisatie is daarbij een krachtig hulpmiddel, omdat het beheerders in staat stelt om een fysieke machine op te delen in meerdere virtuele machines. De problemen en risico's die normaalgesproken komen kijken bij het samenvoegen van verschillende soorten software op een systeem worden hierdoor teruggebracht. Als bedrijven dikke machines gaan neerzetten om grote aantallen kleinere te vervangen zou het zware segment verder kunnen groeien. De meest recente cijfers van IDC laten zien dat de groei van goedkope servers stagneerde terwijl de high-end groeide in het laatste kwartaal van 2006, maar één kwartaal is natuurlijk nog niet direct een trend.

Ondertussen wordt echter ook aan de andere kant getrokken: blade-servers bieden een hoge dichtheid en betrouwbaarheid door middel van goedkope redundantie. Bovendien kunnen ze geclusterd worden als er zwaar werk aan de winkel is. Veel bedrijven zijn geïnteresseerd in het 'Google'-model, waarin hardware slechts een legosteentje is dat naar wens bijgeprikt of weggehaald kan worden, terwijl de applicatie(s) altijd door blijven draaien. In dit model is er juist totaal geen behoefte aan zware en dure machines met vier of acht processors. Ironisch genoeg kan virtualisatie ook voor dit soort toepassingen een uitkomst zijn, want voor een virtuele machine maakt het niet uit op welke fysieke hardware deze draait, zelfs niet als dat van het ene op het andere moment verandert.

Een andere factor die zware systemen minder aantrekkelijk kan maken is de groei van het aantal cores per socket. Twee jaar terug waren de Opteron en de Xeon nog singlecore, maar het zou niemand verbazen als we voor 2010 chips met acht cores zouden hebben. Er zijn twee manieren om hier tegenaan te kijken: de ene is om het gewoon te zien als de zoveelste methode om prestaties van een chip te verbeteren, net als bijvoorbeeld grotere caches en hogere kloksnelheid. Het andere standpunt is dat het hele multicore-verhaal op een gegeven moment ernstig beperkt zal worden door de software, waardoor de vraag naar meer sockets zal afzwakken. Of dat nou bij 16, 32, 64 of 128 cores gebeurt kunnen we in het midden laten, maar als er een bepaalde praktische limiet is waar twee sockets al bij in de buurt komen, dan zou de vraag naar grotere systemen afnemen.

Welk van de genoemde factoren het sterkst is maakt voor de korte termijn niet veel uit: de servermarkt is een trage kolos van ruim 50 miljard dollar. Welke kant hij ook opschuift, alle betrokkenen hebben ruim de tijd om daarop in te spelen. De komende vijf jaar zal er zeker nog een gezonde vraag naar dit soort machines blijven bestaan, dus laten we nu maar snel gaan kijken wat zo'n beest kan presteren.

Sun Fire X4600

De Sun Fire X4600 is een 4U rackmount server met plaats voor vier of acht processors en maximaal 64GB geheugen. Er is ruimte voor vier 2,5" SAS-schijven, vier netwerkpoorten van een gigabit per stuk, twee keer usb aan de voorkant en nog eens twee aan de achterkant. Wie extra kaarten wil inpluggen heeft ruim de keuze, want er zijn zes PCIe-slots (vier keer x8 en twee keer x4) en twee 100MHz PCI-X-slots aanwezig. In principe is er genoeg ruimte in de kast voor kaarten van volledige hoogte, maar om één standaard aan te houden voor alle servers worden desondanks alleen low profile kaarten ondersteund. Op het moederbord wordt gebruikgemaakt van een combinatie van de AMD-8132 PCI-X-tunnel en een nVidia nForce Pro 2200-chipset.

Het ontwerp van het apparaat is vrij bijzonder: in plaats van processors die rechtstreeks op het moederbord zitten gebruikt men een systeem met blades, waar iedere blade een socket en vier geheugenbanken huisvest. Door deze slimme inrichting neemt het geheel weinig ruimte in beslag en kan het toch goed gekoeld worden.

Besturingssystemen die worden ondersteund zijn Solaris, Red Hat Enterprise Linux, Suse Linux Enterprise Server, Vmware ESX Server en Windows Server 2003. Zoals verwacht mag worden van een machine van dit formaat kan hij volledig op afstand beheerd worden. De ingebouwde 'service processor' kan onafhankelijk van de rest van het systeem zijn werk doen en bereikt worden via speciale daarvoor aangemerkte 100Mbit ethernetpoort of een seriële verbinding. Beheerders kunnen zowel via de ingebouwde webinterface aan de slag als via de standaardprotocollen SNMP, IPMI en DMTF.

Tweakers.net ontving van Sun de originele Fire X4600, uitgevoerd met acht 2,6GHz dualcore Opteron 885-processors en 32GB aan ddr-geheugen. Een nieuwe versie van het ontwerp - de X4600 M2 - ondersteunt Socket F-chips en tot 128GB ddr2-geheugen. Deze is niet duurder dan zijn voorganger en zal voor de meeste mensen waarschijnlijk dus de betere keus zijn. Het verschil in prestaties tussen Socket 940 en Socket F is echter niet zo heel groot, dus we denken toch dat deze review aardig representatief zal zijn. De prijzen van de machines beginnen bij 16.500 euro voor een model met vier 2,4GHz-chips, 16GB geheugen en één 73GB-schijf. Onze uitvoering staat op de prijslijst voor 38.300 euro. Het geheel wordt van stroom verzien door vier 850W-voedingen, waarvan er twee kunnen uitvallen voor het systeem echt in de problemen komt. Het gevaarte weegt bijna 57 kilo.

Fujitsu-Siemens TX200

De tweede machine die we in deze review zullen bekijken is de Fujitsu-Siemens TX200. Dit is een prijsbewust model gebaseerd op de Intel 5000V-chipset. Hij is als (diepe) toren of 4U rackmount te krijgen en heeft ruimte voor twee dual- of quadcore Xeons, 24GB FDB667-geheugen en zes harde schijven. Controllers zijn aanwezig voor SATA, SAS en SCSI met basisfeatures op het gebied van RAID en optionele uitbreidingen. Wie zijn eigen controllers liever gebruikt kan een van de twee PCIe-slots gebruiken (x8 en x4), twee keer PCI-X of zelfs nog een gewone PCI-gleuf. De standaard 600W-voeding kan eventueel voorzien worden van een broertje voor extra veiligheid. De machine ondersteunt Windows 2000 en 2003, Suse en Red Hat Linux, VMware, SCO OpenServer en UnixWare.

Hoewel we op geen enkele manier willen pretenderen dat de TX200 een concurrent is voor de X4600, wilden we graag van de gelegenheid gebruikmaken om een idee te krijgen van de prestaties die een relatief goedkoop systeem met twee quadcores zou kunnen leveren. Met twee 1,6GHz Clovertowns en slechts 4GB geheugen staat deze machine in scherp contrast met de high-end spullen die we normaal graag op de pijnbank leggen, maar juist daarom kunnen we er waardevolle lessen van leren. De door ons geteste configuratie kost 3299 euro.

PostgreSQL 8.2 final vs. dev

In deze reeks artikelen hebben we tot nu toe steeds gebruikgemaakt van een ontwikkelversie van PostgreSQL 8.2. Hoewel deze voor ons gebruik nooit enig probleem heeft veroorzaakt, zal de inmiddels verschenen uiteindelijke release zonder twijfel een stuk populairder worden. Wat precies het verschil is tussen de twee versies is dan wel uitgebreid gedocumenteerd in de changelogs, maar moeilijk samen te vatten. De prestaties en schaalbaarheid zijn in de loop der maanden in ieder geval niet vooruitgegaan. Zo zien we bij zware belastingen (25 of meer gelijktijdige gebruikers) een gemiddelde afname van 24% bij acht processors en 14% bij vier processors. De winst die tijdens de stap van vier naar acht sockets gehaald wordt is ook afgenomen: waar de ontwikkelversie nog 24% pakt, is de uiteindelijke versie net 6% sneller met het dubbele aantal cores.

Het grote prestatieverlies kwam voor het eerst aan het licht toen we 8.2-rc1 probeerden, een bijna uiteindelijke versie van de software. Het team achter PostgreSQL heeft naar aanleiding van onze bevindingen snel een drietal patches gemaakt om het leed te verzachten, maar die konden helaas niet meer in de final release opgenomen worden. Wel zijn ze in versie 8.2.1 terechtgekomen. Wij hebben voor onze test de 'final' versie 8.2.0 gebruikt mét deze drie specifieke patches toegepast, maar zonder eventuele andere wijzigingen die voor 8.2.1 zijn gemaakt.

Onder Solaris ziet het beeld er helaas niet veel anders uit. De ontwikkelversie presteerde daar al niet fantastisch (merk bijvoorbeeld op dat de configuratie met acht processors zo'n 10% trager is dan die met vier processors) en de uiteindelijke release doet het niet bepaald beter. Dit was een dilemma: PostgreSQL 8.2 final zal veel meer gebruikt worden dan 8.2-dev, maar slaagt er minder goed in om de hardware te benutten. Omdat de server niet onnodig in een kwaad daglicht te stellen en we al veel vergelijkingsmateriaal hebben verzameld met 8.2-dev hebben we besloten om daar voorlopig nog even vanuit te blijven gaan als basis.

Een minder groot versieprobleem trad op bij MySQL, waarvan versie 4.1.22 ongeveer 10% trager bleek te zijn dan 4.1.20 en directe vergelijkingen dus ook niet mogelijk zijn.

Schaalgedrag van 4 naar 8 sockets

De Sun X4600 leek een ideaal apparaat te zijn om het schaalgedrag van de Opteron mee te kunnen bestuderen. Door het ontwerp met blades kunnen processors fysiek uit het systeem verwijderd worden, waardoor het op het eerste gezicht mogelijk lijkt te zijn om configuraties van één tot acht sockets te bouwen door er steeds één bij te prikken. Helaas gaat het in de praktijk wat minder makkelijk, omdat ieder socket functioneert als knooppunt in een netwerk van HyperTransport-links. Dit netwerk wordt niet stap voor stap opgebouwd maar kent twee specifieke configuraties. Zoals op de afbeelding hieronder te zien is worden er grotendeels andere verbindingen gebruikt voor 4-way en 8-way systemen. Andere configuraties worden helaas niet ondersteund met de X4600, hoewel de M2-variant binnenkort een bios-update krijgt om ondersteuning voor 6 processors toe te voegen.

Links: configuratie met acht sockets, Rechts: configuratie met vier sockets

Het is nog wel gelukt om ons systeem aan de praat te krijgen met twee sockets, maar de prestaties hiervan waren duidelijk slechter dan van een standaardserver met dubbele Opteron verwacht kan worden. Waarschijnlijk komt dit omdat in de X4600 de twee sockets die met de chipset verbonden zijn alleen via een omweg met elkaar kunnen praten. Helaas zijn er dus geen zinnige gegevens over het complete schaalgedrag vanaf één socket, maar de gegevens met vier en acht processors hebben we wel.

We zien een aantal interessante dingen in de onderstaande grafiek. MySQL 4.1.22 doet het sowieso niet heel goed met vier processors, maar werken met zestien cores wordt hem echt te veel. Een daling van 41% tijdens de overstap brengt de prestaties terug naar een niveau wat normaal van een systeem met één socket verwacht kan worden. MySQL 5.0.32 doet het iets beter, maar een winst van 4% voor een verdubbeling van de theoretische rekenkracht is uiteindelijk ook niet indrukwekkend te noemen. In ieder geval is te zien dat de ontwikkelaars het werken met meerdere threads beter onder de knie hebben gekregen in de nieuwe versie. Toch is zelfs de score met vier sockets (acht cores) slechts marginaal beter dan die van een enkele quadcore Xeon.

Trouwe lezers weten inmiddels wel dat PostgreSQL voor wat betreft schaalgedrag een prima stuk software is, maar zoals we op de vorige pagina al gezien hebben komt dat op de X4600 toch niet goed tot zijn recht. De final versie zet gemiddeld bij >25 gebruikers een bescheiden winst van 6% neer, maar de grafiek toont een effect dat we alleen bij MySQL eerder hebben gezien: grotere drukte geeft slechtere in plaats van constante prestaties. De ontwikkelversie is een stuk positiever: met een schaalwinst van 44% zet hij een nieuw record neer van 950 requests per seconde.

Solaris vs. Linux

Over de verschillen tussen Solaris en Linux kunnen lange verhalen worden geschreven, wat op een vrijwel oneindig internet betekent dat mensen dat ook daadwerkelijk gaan doen. Dr. Nikolai Bezroukov heeft bijvoorbeeld een grondige vergelijking gemaakt waarin naast voor- en nadelen ook de geschiedenis en onderlinge invloeden worden toegelicht. Zijn conclusie is kort samengevat dat Solaris een hoop interessante features heeft en qua architectuur op veel gebieden voorloopt, maar door zijn van oorsprong commerciële karakter - dat inmiddels wel minder, maar nog steeds aanwezig is - niet van dezelfde bekendheid geniet als Linux. Een van de claims die wordt gemaakt is dat Solaris beter schaalt dan Linux, met name als het gaat om multithreading en open source databases, precies waar we mee bezig zijn. Onze vorige ervaring bevestigde deze stelling van Bezroukov: PostgreSQL deed het op een dubbele Opteron 2,4GHz 6% beter en MySQL liep 14% sneller dan onder Linux.

Wanneer we vier of acht processors gebruiken om Solaris en Linux te vergelijken zien we gemengde resultaten. MySQL 4.1.22 gaf onder Linux al enigszins teleurstellende scores en ging bovendien hard achteruit bij het overstappen van vier naar acht Opterons. Met Solaris is het gedrag anders: de pieken die gehaald worden met een klein aantal gebruikers liggen flink wat hoger dan onder Linux, maar zodra de belasting wordt opgevoerd zakt het ook met vier processors al hard in, terwijl Linux zich pas bij acht processors laat kennen. Of dit beter of slechter is hangt af van de situatie, maar eigenlijk zien beide er niet helemaal gezond uit.

MySQL 5.0.32 gedraagt zich onder Linux een stuk braver dan MySQL 4.1.22, maar vertoont onder Solaris nog steeds vreemd gedrag. Met vier processors verslaat de versie voor Solaris ineens de beste resultaten van Linux (inclusief die met acht processors), maar bij het verder opschalen valt hij door de mand door bijna een kwart terug te vallen.

Een recente discussie op de Linux kernel mailinglist geeft inzicht in een mogelijke verklaring voor het schaalgedrag van MySQL, waar we al een jaar lang kritiek op hebben: de software probeert de aandacht van de processor(s) voor de verschillende threads op een logische manier te verdelen door de prioriteit ervan aan te passen, maar gebruikt daarvoor een verkeerde aanroep naar de Linux-kernel, waardoor het eigenlijk helemaal geen effect heeft. Hierdoor zouden er wel eens veel threads kunnen draaien waarvan MySQL denkt dat ze op de achtergrond zitten, terwijl ze in werkelijkheid nog volop cpu-belasting veroorzaken. Het corrigeren van dit probleem door een onofficiële kernelpatch geeft bemoedigende resultaten, dus hopelijk zal MySQL binnenkort de juiste aanroep gaan gebruiken. Helaas verklaart dit nog niet waarom de Solaris-versie hetzelfde gedrag vertoond, maar Linux is uiteindelijk toch een belangrijker - zo niet het belangrijkste - platform voor MySQL.

Ook de schaalfavoriet PostgreSQL 8.2-dev gedraagt zich vreemd: met vier processors zijn de prestaties nog praktisch gelijk, maar tijdens de overstap naar acht processors wint de Linux-versie 24% terwijl de Solaris-versie juist 10% achteruit gaat, zodat Linux uiteindelijk met een voorsprong van 38% over de finishlijn komt. Nu hebben we bij Tweakers.net heel wat meer ervaring met Linux dan met Solaris, maar toch denken we niet dat het vreemde gedrag in de verschillende databases verklaard kan worden door een foute configuratie: de installatie van Solaris is door mensen van Sun zelf uitgevoerd en daarna hebben we op hun aanraden nog diverse tips en trucs uitgevoerd. Ook tijdens een laatste gezamelijke controle kon er geen verklaring worden gevonden voor het verschil, maar Sun blijft de kwestie intern onderzoeken.

X4600 vs. Clovertown

We hebben gezien dat er haken en ogen zitten aan het draaien met vier of acht processors: een groot HyperTransport-netwerk lijkt erg gevoelig te zijn voor de manier waarop de software is gebouwd. Hoewel we al een paar keer eerder moeizaam schaalgedrag hebben gezien bij kleinere systemen, is dit voor het eerst dat we echt drastisch negatieve effecten tegenkomen bij het verdubbelen van het aantal cores. Mogelijk is dit een probleem waar alle servers op stuiten, maar helaas hebben we geen vergelijkingsmateriaal in dezelfde klasse. Wel kunnen we de X4600 vergelijken met Intels quadcore. Naast de nieuwe Fujitsu TX200 met 1,6GHz-processors trekken we ook de eerder besproken 2,66GHz-versie erbij.

In MySQL 5.0.32 zien we dat twee Clovertowns het helemaal niet slecht doen tegenover vier of zelfs acht Opterons, ondanks het feit dat AMD twee keer zoveel bandbreedte per core tot zijn beschikking heeft. Aan de andere kant blijkt dat een 2,66GHz Clovertown met 1333MHz bus slechts 18% sneller is dan een 1,6GHz-model met 1066MHz bus, terwijl eerstgenoemde ruim twee keer zo duur is. Dit soort scheve verhoudingen zijn op zich niets nieuws in de computerwereld, maar toch belangrijk om af en toe aan herinnerd te worden.

In de grafiek van PostgreSQL 8.2-dev zien we een logischer beeld, waarbij het systeem met acht Opterons duidelijk bovenaan staat. Hoewel dit er al een stuk beter uitziet voor de X4600, is het maar de vraag in hoeverre het echt positief genoemd kan worden. Twee stuks van het topmodel Clovertown kosten namelijk 2344 dollar, terwijl acht stuks van de door ons geteste Opteron niet minder dan 9320 dollar moeten opbrengen. Daar komt nog bij dat een set van 2,66GHz Clovertowns samen maximaal 240 watt verstoken en doorgaans in een 1U-doos passen, terwijl acht Opterons een totaal tdp van 760 watt hebben en meteen 4U in beslag nemen. Ook al is deze vergelijking wat simplistisch, het mag duidelijk zijn dat de investering in een goed gevulde X4600 voor lang niet alle bedrijven te verantwoorden zal zijn gebaseerd op een prestatiewinst van 19%.

PovRay en Kmeans

Waar is de X4600 wel duidelijk geschikt voor? Dit is een vraag die Sun wellicht het best zelf kan beantwoorden: de marketing heeft het over records in een aantal zwaar paralleliseerbare, rekenintensieve benchmarks: SpecFp_rate2000, SpecInt_rate2000 en SpecOmpm2001. De records zijn stuk voor stuk gezet met Solaris en Suns eigen compiler. Een aantal van de gebruikelijke serie zakelijke benchmarks (zoals TPC-C en SpecJbb2005) zijn niet gedraaid danwel niet gepubliceerd. Degene die wel is verschenen valt tegen: in SAP-SD worden met acht 2,6GHz Opterons 1650 gebruikers bediend, slechter dan de ~1980 die IBM en HP met vier processors halen en tevens minder dan de score van een dubbele Clovertown: 1841. We zijn dus in ieder geval niet de enigen die problemen hebben (gehad) bij het maximaal benutten van de kracht van de X4600.

Met twee benchmarks die net als de tests die Sun voor zijn marketing gebruikt bijna perfect over meerdere threads te verdelen zijn gaven we de X4600 een kans om zichzelf te bewijzen. De eerste is PovRay, de bekende softwarematige raytracer. We kozen voor versie 3.7 bèta, de eerste multithreaded versie. De snelste tijd voor het systeem met acht processors is 160 seconden, wat 35% sneller is dan de 246 seconden die met vier processors nodig was. Nog steeds ver verwijderd van de ideale verdubbeling, maar toch het beste wat we tot nu toe hebben gezien. De 1,6GHz Clovertown kan de taak pas na 406 seconden afronden. Helaas is de 2,66GHz Clovertown niet getest, maar op basis van deze gegevens lijkt het er niet op dat deze de X4600 zou kunnen inhalen.

De tweede test is door Tweakers.net zelf ontwikkeld en wordt uitgevoerd in PostgreSQL. Het gaat om implementatie van het Kmeans-algoritme, dat is bedoeld om objecten op te delen in groepen van dingen die op elkaar lijken. In de wereld van datamining en zoeken is dit een veelgebruikt hulpmiddel. De benchmark deelt 43.665 nieuwsberichten in op basis van de woorden die er in voorkomen. Gemiddeld worden er voor elk bericht iets meer dan honderd kenmerkende woorden geselecteerd. Aan de hand van het aantal keer dat deze voorkomen kan een 'afstand' worden berekend tussen twee verschillende posts. Verhalen die dicht bij elkaar zitten qua woordgebruik worden bij elkaar gestopt en de test gaat net zo lang door met verdelen tot er in ieder groep minder dan twintig stuks zitten. Dit algoritme kan makkelijk over meerdere threads verdeeld worden door delen van de verzameling aan iedere core toe te wijzen.

Het schaalgedrag van het algoritme wordt mooi geillustreerd door Clovertown: een enkele thread op 1,6GHz is maar liefst 6019 seconden bezig met deze taak, terwijl dat op 2,66GHz afneemt naar 3883 seconden, een bijna perfecte schaling van prestaties met kloksnelheid. De verdubbeling van het aantal threads werkt op kleine aantallen ook erg goed, met meer dan 95% betere prestaties voor de stap van één naar twee cores, meer dan 85% voor de stap van twee naar vier en meer dan 80% voor de laatste stap naar acht cores. In totaal wordt het programma door de stap van singlecore naar twee keer quadcore 6,8 keer sneller op 2,66GHz en 7,2 keer sneller op 1,6GHz, niet ver van de ideale 8 keer vandaan.

Voor de Opteron onderscheiden we Linux en Solaris. De eerste zet met acht cores redelijk goede prestaties neer: de tijd van 691 seconden is wel hoger dan de 568 van het topmodel Clovertown, maar op zich niet vreemd. Wel vreemd is dat het systeem na de stap van acht naar zestien cores ineens bijna twee keer zoveel tijd nodig heeft. Wederom stuiten we op schijnbaar heel goed schalende applicatie die het met acht sockets simpelweg begeeft. Een mogelijke verklaring hiervoor dat PostgreSQL onder de zware druk van acht dualcores zijn tabellen vaker moet schoonmaken (vacuumen), wat uiteindelijk een averechts effect heeft. Onder Solaris is het beeld echter weer anders: hier wordt een winst van 21% geboekt door de extra rekenkracht toe te voegen. Helaas is dit een schrale troost voor het feit dat de prestaties in absolute termen achterblijven: zelfs met 16 cores heeft de Opteron met Solaris nog bijna vier minuten langer nodig dan de goedkoopste Clovertown.

Stroomverbruik en conclusie

Relatief matige prestaties in combinatie met vier 850W-voedingen belooft niet veel goeds voor de prestaties per watt, maar voor de volledigheid zullen we het toch becijferen. De X4600 gebruikt met acht processors en 32GB geheugen 825 watt idle en 1030 watt onder belasting. Met vier processors en 16GB kwamen deze metingen uit op respectievelijk 585 en 703 watt. Deze cijfers zijn verkregen zonder het stroombesparende PowerNow! ingeschakeld, omdat dit vanwege onduidelijke redenen niet wilde werken in combinatie met onze bios- en/of Linux-versie. Als het wel had gewerkt was het idle verbruik sowieso lager geweest en had er mogelijk ook nog iets van het belaste verbruik afgekund. De 2,66GHz Clovertown met 8GB geheugen had onder volle belasting 355 watt nodig, terwijl de Fujitsu-machine met 1,6GHz-chips en 4GB al aan 279 watt genoeg had. Clovertown zet hierdoor met gemak twee keer zoveel prestaties per watt neer in de best schalende database.


	Opgenomen vermogen

	Sun X4600 (8x Opteron 2,6GHz)	1030

	Sun X4600 (4x Opteron 2,6GHz)	703

	Melrow (2x Clovertown 2,66GHz)	355

	Fujitsu TX200 (2x Clovertown 1,6GHz)	279


	Prestaties per watt (PostgreSQL 8.2-dev)

	Melrow (2x Clovertown 2,66GHz)	1264

	Fujitsu TX200 (2x Clovertown 1,6GHz)	1205

	Sun X4600 (4x Opteron 2,6GHz)	615

	Sun X4600 (8x Opteron 2,6GHz)	519

X4600 conclusie

Het is moeilijk om heel positief te zijn over de achtvoudige Opteron. In de applicaties waarin hij niet trager is dan een viervoudige uitvoering is de winst vaak niet indrukwekkend genoeg om het extra verbruik en kosten te kunnen rechtvaardigen. Sun valt daarbij niets te verwijten: de X4600 is zoals we van het bedrijf gewend zijn stijlvol, gebruiksvriendelijk en compleet. Het is simpelweg de architectuur van AMD die niet heel geschikt is om op te schalen naar meer dan vier sockets. Er zijn enkele tests die het potentieel kunnen demonstreren, maar het gaat dan om extreem goed paralleliseerbare applicaties. Voor de prijs van 38.300 euro hoeven we niet eens naar de concurrentie te kijken om een alternatief te vinden voor zulke software: voor hetzelfde bedrag trekken we zo bijna tien(!) dual 2,8GHz Opteron-servers met 4GB geheugen uit het magazijn. Dat zijn twintig processors voor de prijs van acht. Als een bepaalde taak dan toch zo makkelijk te distribueren is, waarom niet meteen een cluster bouwen? Sneller gezegd dan gedaan, maar uiteindelijk levert het wel weer meer uitbreidingsmogelijkheden en flexibiliteit op.

Het voornaamste voordeel van een grote machine boven een cluster is dat er een grote sloot geheugen beschikbaar is die gedeeld wordt door alle threads, zodat de programmeurs zich geen zorgen hoeven te maken over synchronisatie. De X4600 ondersteunt maximaal 64GB geheugen (de M2 zelfs 128GB) en daar past een aardige dataset in, bijvoorbeeld voor een wetenschappelijke simulatie. Eén van de plaatsen waar de achtvoudige X4600 een toepassing heeft gevonden is dan ook in de Japanse Tsubame, die moment van schrijven de negende snelste supercomputer ter wereld is. Kort samengevat is een achtvoudige Opteron interessant voor stoere simulaties gemaakt door nog veel stoerdere programmeurs, maar is het grootste deel van de wereld beter af met twee of vier sockets, of een andere processor die zich beter thuisvoelt in zware systemen. Gelukkig heeft Sun hier rekening mee gehouden en kan de X4600 zonder problemen met vier sockets geleverd worden. Deze configuratie is nog steeds geen winnaar in onze databasetest, maar kent in de praktijk in ieder geval wel een hoop succesverhalen.

Achtvoudige Opterons in actie in Japan

Fujitsu TX200 conclusie

Deze machine heeft niet de prestige en uitstraling van een Sun X4600, maar gewapend met acht cores kan hij toch behoorlijk van zich afbijten. Hoewel de klant uiteraard vrij is om te kiezen, blijken de 1,6GHz Clovertowns van ons testexemplaar een verrassend sterk aanbod: ze bieden zeker zestig tot tachtig procent van de prestaties van het topmodel voor minder de helft van de prijs en een 2x40W lager tdp, wat een uitstekende prijs-prestatie en prestatie-watt verhouding oplevert. Het enige nadeel is dat de kast relatief groot is. Dit laat wel ruimte vrij voor veel (goedkope) 3,5" harde schijven in plaats van 2,5" servermodellen, maar is voor een dichtbevolkt rek geen pretje. Al met al is de TX200 een interessante optie voor wat kleinere bedrijven die vooral waar voor hun geld willen en niet kampen met ruimtegebrek.

Dankwoord

Sun en Fujitsu-Siemens logo Tweakers.net wil Hans Nijbacker, Bart Muijzer, Jignesh Shah, James van Geene en Gert Jan van Gent van Sun bedanken voor hun medewerking aan dit artikel. Verder Jeroen de Bruijn van Fujitsu Siemens voor het uitlenen van de TX200, Tom Lane van PostgreSQL voor het analyseren van de prestatieproblemen, onze eigen systeembeheerders ACM en moto-moi voor het ontwikkelen en uitvoeren van de benchmarks, en Mick de Neeve voor de Engelse vertaling.