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.

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

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.

Eerdere artikelen in deze serie

12-12-2006: Intel Xeon 'Clovertown' 2,66GHz
13-11-2006: Intel Xeon 'Woodcrest' 3,0GHz (Apollo 5)
4-9-2006: Intel Xeon 'Woodcrest' 2,66GHz
30-7-2006: AMD Opteron Socket F 2,4GHz
27-7-2006: Sun UltraSparc T1 vs. AMD Opteron
19-4-2006: Xeon vs. Opteron, single- en dualcore

Plug deze review

• Digg

Reacties (54)

Ga deze server als het lukt deze week inzetten voor een VMware demonstratie. Verwachting is dat je met VMware wel goed kan doorschalen naar 8 cpu's. Deze server wordt dan ook heel veel gericht op consolidatie projecten. Twee of drie van deze servers kunnen heel veel losse servers vervangen.

Het is jammer dat hij in deze test nog niet goed naar voren komt. Hopelijk spelen de db-ontwikkelaars ook in op de beschikbaarheid van dit soort servers.

Allereerst mijn complimenten voor de mooie review. Het feit dat de hedendaagse toepassingen nog lang niet zover zijn om dit geweld aan te kunnen en hiermee de zin of onzin van meerdere cpu's of cores in een systeem te hebben.

Het enige puntje wat ik echt mis is een vergelijking met Oracle. begrijp me niet verkeerd, Postgre en MySQL zijn mooie systemen en worden steeds vaker in het bedrijfsleven gebruikt. Maar zoals er al beschreven wordt is de markt voor deze systemen een log monster waar Oracle toch nog steeds en voor de komende jaren heer en meester is. De meeste ERP systemen en data warehouses gebruiken nog altijd Oracle als back end.

Oracle wil niet dat je reviews plaatst zonder dat zij ervan op de hoogte zijn, en dat vinden wij niet zo'n tof idee. Verder hebben we totaal geen ervaring met Oracle (i.t.t. mysql en in mindere mate postgresql) waardoor de vergelijking niet helemaal eerlijk zou kunnen zijn.

Sinds wanneer wordt er geluisterd naar wat een fabrikant wil? Een review moet net onafhankelijk zijn. Als je Oracle wil testen, dan doe je dat toch gewoon. Zolang je geen NDA ofzo getekend hebt is dat toch geen probleem?
Of is dit weer een gesponserde review?

Zolang je geen NDA ofzo getekend hebt is dat toch geen probleem?

'Als u dit produkt download gaat u akkoord met voorwaarden die Oracle bepaald heeft in de hieronder getoonde EULA [...]'

De juridische rechtsgeldigheid en haalbaarheid, zeker vanuit het oogpunt van de vrije journalistiek, is te betwijfelen, maar niemand wil echt een dergelijk risico nemen dunkt me.

Of is dit weer een gesponserde review?

Ik ben hier nog nooit een dergelijk ding tegengekomen zonder dat er 'advertorial' boven stond.

Je kunt natuurlijk wel Oracle testen en hun mailen dat je een review geplaatst hebt, maar als ze dan vragen om nog 100 verschillende instellingen uit te proberen, uitgebreid de schuld gaan geven aan je hardwareplatform, OS, benchmark suite en andere instellingen/compilers kun je daar je levenswerk van gaan maken. Als je dat niet doet gaan ze misschien via al hun PR-kanalen ventileren dat grote servers bouwen een vak apart is, zie maar die knulletjes van tweakers, krijgen zelfs met de goeie software een Sun server nog niet zo aan het draaien als wij van Oracle dat zelf kunnen... dan wilde je misschien dat je dat niet gedaan had

Ja, dat had ik ook wel willen zien. Ik kan me nog de tijd herinneren dat we op het werk op een 16-way UltraSparc doos de CPU bijna voltrokken met Oracle door een slechte query in een stuk software.

Een beetje jammer dat Oracle zo moeilijk doet over zijn database...

Er is wel wat performance / prijs info te vinden mbt tot vergelijkende test voor Oracle, MS SQL server en IBM's DB2 maar helaas zitten daar weer geen My SQL of Postgres resultaten tussen:
http://www.tpc.org/tpcc/r...erby=priceperf&sortby=asc

Is er ook eens gedacht om Microsoft Windows Server te testen op de server in combinatie met de databases, ik zou wel benieuwd zijn hoe dat schaalt.

We hebben daar wat praktische bezwaren bij:
- We hebben zo goed als geen windows server ervaringen in ons team, laat staan voor zo'n zware machine.
- PostgreSQL is nog maar heel recentelijk (native) naar windows geporteerd waardoor het waarschijnlijk nog niet erg optimaal werkt.
- De overige grote databases, met name MS SQL Server en Oracle, mag je enerzijds niet zomaar testresultaten van publiceren en anderzijds hebben we daar gewoon niet genoeg ervaring mee om zomaar tegenover MySQL of PostgreSQL te zetten. En dan wederom al helemaal niet op Windows.

Daarbij zou ik niet al te gekke prestaties verwachten, en om windows zomaar af te laten slachten levert alleen maar een boel flames op ;-)

(mijn grappigste ervaring met MS performance: een debian-TWiki installatie draait in een vmware image onder windows nog sneller dan TWiki native onder windows...)

Anyway, het is vrij belachelijk dat je geen benchmarks mag plaatsen van producten, ik bedoel, straks mag de consumentengids niets meer testen omdat de fabrikanten dat niet willen? Kun je dat eigenlijk legaal wel verbieden? Wat mij betreft zouden jullie best eens met de consumenten gids mogen gaan praten, zien of dit juridisch wel kan, en eventueel een proefproces uitlokken door samen (sta je sterk) een flinke review van MS SQL, oracle etc te publiceren in de consumentengids...

Nogmaals, dit kan toch niet? Mensen verbieden andere mensen zo objectief mogelijke informatie over een product te geven?!?! Kom nou, dat KAN gewoon niet.

Je bent zojuist de fout ik gegaan met de post over Vmware, daar mag je namelijk ook geen resultaten van bekend maken.

De overige grote databases, met name MS SQL Server en Oracle, mag je enerzijds niet zomaar testresultaten van publiceren en anderzijds hebben we daar gewoon niet genoeg ervaring mee om zomaar tegenover MySQL of PostgreSQL te zetten. En dan wederom al helemaal niet op Windows.

Sinds wanneer bepaalt een fabrikant wat gebruikers over hun produkt mogen schrijven of zeggen ???

(f) You may not publish or provide the results of any benchmark or comparison tests run on Software to any third party without the prior written consent of Sun.

Dit soort dingen staat ook in de MS licentie, maar dat het erin staat betekend nog niet dat ze dit af kunnen dwingen, of dat het legaal is... Er staan meer dingen in die licenties die eigenlijk illegaal zijn...

Ik denk niet dat een fabrikant dat kan en mag bepalen, maar ze kunnen wel bepalen wanneer je aan de licentievoorwaarden voldoet. En voor de gratis developmentversie van Oracle is dat een voorwaarde die zij gesteld hebben.

Dan zouden we Oracle al moeten gaan kopen om geen last van dat soort beperkende waarden te hebben, maar dat is met een 8-cpu machine nogal prijzig...

De medewerkers van Sun (inclusief een Solution Architect & OS Ambassador) sporen ons alleen maar aan om ook Solaris te bekijken. Bovendien hebben we ook gewoon medewerkers van Sun op bezoek gehad die hier met de diverse problemen waar we tegenaan liepen geholpen hebben... ook met de volle wetenschap dat dit voor een artikel was. Dus ik gok dat dat dan wel goed zit

(f) You may not publish or provide the results of any benchmark or comparison tests run on Software to any third party without the prior written consent of Sun.

Het valt mij nog mee dat jullie van SUN deze benchmarks mogen posten. In de gebruikersovereenkomst van Solaris staat expliciet vermeld dat je geen benchmarks zonder hun toestemming mag publiceren.

Deze worden veel ingezet als web-, mail-, file-, print- of proxy/firewall-doosjes, maar doen ook wel (licht) database- en applicatiewerk.

dit viel me meteen op. Ik mis in dit rijtje toch iets heel belangrijks en daarbij heb je echt wel wat meer CPU kracht nodig. VMware is een opkomend iets en gebruikt meer processor kracht dan menig iets en dat word nog wel eens onderschat door vele.

Een goede VMware server met pak `m beet 8 CPU`s is echt geen overbodige luxe als er 10 a 12 servers op draaien. en vind "doosje" ook een beetje neerbuigend.

waarom op deze machine 10 VM's draaien? Je kunt voor dat geld 10 'echte' machines kopen en daar dan nog eens een aantal VM's op. Kostentechnisch niet interessant.

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

Grote organisaties kijken niet alleen naar de kosten van aanschaf, maar vooral naar de beheers- en onderhoudskosten. Op 1 machine 10 VM's draaien vergt minder beheerskosten dan 10 aparte machines met een native OS. Denk alleen maar aan het aantal netwerkverbindingen dat je nodig hebt. Tevens is de kans dat 1 systeem niets staat te doen veel groter dan dat 1 systeem met 10 VM's niets staat te doen. Dit is het algemene principe van virtualisatie.

Dat niet alleen, maar wat denk je van 10 maal 1U aan rack ruimte tegen 1 maal 4U.
Stroom verbruik, 10 systemen kosten een stuk meer stroom als 1 8way. Daarnaast is de onderlingen communicatie tussen de virtuele servers natuurlijk ook vele male sneller als via een fysiek netwerk.

Dat sloeg vooral op de dual-cpu systemen gok ik zo Maar je hebt natuurlijk gelijk dat een fikse virtualisatie-oplossing best pittige systeemeisen heeft. Wat zeker wel op kan lopen tot een soortgelijke doos als wij hebben bekeken.

Een goede VMware server met pak `m beet 8 CPU`s is echt geen overbodige luxe als er 10 a 12 servers op draaien. en vind "doosje" ook een beetje neerbuigend.

welnee, we hebben zeker 40 servers op 1 ESX machine draaien, en dat draait prima.

Alleen moet je natuurlijk geen 'fully-loaded' servers draaien natuurlijk. Maar file en printer servers, en wat low to medium loaded web/applicatie servers is uitstekend te doen.

De machines in kwestie zijn 'slechts' HP DL385's, met 2x dualcore opteron (2.4GHz) en 16GB geheugen. (hangt wel een MSA1500 onder voor storage)

VMware server met 8CPUs en maar 10-12 servers erop? Ik zie in de praktijk voor een 2CPU machine tegenwoordig al 12-20 virtuele machines. Maar dan wel met 16GB geheugen erin. Dus met een 8-way zou je op 40 tot 80VMs kunnen uitkomen, als je veel geheugen erbij koopt.

Ik heb ervaring met VMWare ESX servers.

We draaien op dit moment 3 a 4 servers op 1 DL380 server met 6GB ram en 2 processoren. Dit is echt ruim voldoende at the moment.

We hebben 1 server die een zwaardere applicatie draait, die is voorzien van 6GB ram en 2 dualcore's.

Server maken gebruik van een volledig redundante MSA1500 SAN met 2 MSA30 cabinets (alle servers hebben 2 FC kaarten aan boord).

VMWare is gewoon superhandig, maakt beheer een stuk prettiger en rebooten van een server is een verademing, geen SCSI opstartzooi etc, dus je ben in 2 seconden de bios uit ipv soms enkele minuten.

Ik vind jullie benchmarks uitermate vreemd, ze komen simpel weg niet overeen wat ik in real-world systemen tegen kom waarin progress bijzonder goed werkt met 250+ concurrent gebruikers. Systemen zelf die deze performance leveren zijn 4-way en 8-way fujitu primepowers.

Deze benchmark heeft het over 25+ concurrent gebruikers, naar mijn inziens schaf je geen 8-way server aan voor zo' n klein aantal concurrent gebruikers op slechts 1 database, Daar heb je 1-2 cpu-systemen voor.

Ook worden op zulk soort systemen meestal meerdere databases(en vaak van verschillende smaken en producenten) naast elkaar gedraaid. Samen met groot aantal gebruikers kun je volgens mij dan pas de werkelijk kracht van een 8-way of 16-way systeem zien ten opzichte van kleinere systemen. En dan nog krijgen 1500+ gebruikers het niet eens voor elkaar om de cpu load boven de 50% te krijgen tijdens piekuren.


Samengevat, ik denk dat een goede realistische load haast bijna onmogelijk te creeren is door de crew van tweakers.net. Het enige wat ik er uit haal, is dat de database van tweakers.net kennelijk geen baat heeft bij een 8-way of 16-way systeem.

Ik denk dat je te veel naar de softwarekant van het verhaal kijkt. Dat een Fujitsu Primepower met Sparc64 V-processors het goed doet met acht processors wil niet zeggen dat een Opteron het dan óók maar moet doen, het zijn totaal andere platforms en zoals uitgelegd heeft AMD wat dingen 'quick en dirty' geïmplementeerd die goed werken met weinig sockets, maar stukgaan met meer. Het is niet voor niets dat er nul TPC-C resultaten zijn met acht Opterons, nul SPECjbb-resultaten en dat het enige SAP-SD resultaat zuigt. Dit terwijl Itanium, Xeon MP, Power, SPARC, enz. minder problemen hebben om boven de vier sockets te schalen. Dat kan toch niet allemaal de schuld van de software zijn of wel?

Dat wij niet genoeg load kunnen genereren is niet waar: zoals te zien in de grafieken wordt de database een bottleneck bij ongeveer 25 gelijktijdige gebruikers en bij 100 is het op zijn best gelijk, maar eerder trager, dus bij 250 gebruikers zal hij niet ineens weer sneller zijn. Voor ons is het geen probleem om de kraan verder open te draaien als we bij 100 nog steeds een stijgende lijn zouden zien, maar die bak wil gewoon niet sneller. Uiteindelijk zal inderdaad niemand een server met acht Opterons kopen voor een enkele websitedatabase, maar in dit geval was er echt niets meer uit te trekken.

Het punt is, misschien is de database en omgeving van tweakers.net niet echt geschikt om zulke bakken te testen. Maar zulke grote bakken worden volgens mij ook zeer zelden ingezet voor websites en databases die er onderhangen.

Overigens kunnen die sparc krengen veelll meer dan 250 concurrent gebruikers hebben, maar dan spreek ik niet over een load veroorzaakt door een webserver. Dat is toch net wat anders dan bijv. personeelssystemen. Bottleneck bij zulke servers zijn meestal de storagesystemen die eraan hangen.

Ik denk dat een sparc systeem met 25 users die elk zo snel mogelijk requests naar een database sturen het misschien niet eens zoveel beter zal doen, de kracht van zulke bakken is echter dat ze gigantische aantallen gebruikers tegelijk kunnen slikken.

Dus waar ik naar nieuwsgierig ben, wat gebeurd er als je bijv. 1000 concurrent gebruikers hebt die elke 2 seconden een verschillende query los laten op de database?
Hoe werkt het als het er 2000 worden, of 5000?
Niet zo zeer dus een klein aantal concurrent gebruikers die een soort dos-attack uitvoeren.

Storage zou geen bottleneck hoeven zijn met een geclusterd SAN gekoppeld via infiniband oid...

Ik vind jullie benchmarks uitermate vreemd, ze komen simpel weg niet overeen wat ik in real-world systemen tegen kom waarin progress bijzonder goed werkt met 250+ concurrent gebruikers.

Er is een groot verschil tussen Progress en PostgreSQL

Welke van de twee bedoel jij nou ?

Daarnaast moet je misschien even gaan lezen hoe de test is opgebouwd aangezien t.net echt wel weet hoe ze een database moeten testen. (Blijkens ze support krijgen van PostgreSQL en sun zelf...)

reviews: Serverduel: Xeon Woodcrest vs. Opteron Socket F

Heb jij het over 250+ transacties per seconde of 250+ gebruikers die het systeem gebruiken? Dit is niet hetzelfde.

Nog ter aanvulling op de vorige commentaren:
Bij de belasting die wij genereren volgen de requests van de "maar" 25 gebruikers elkaar zo snel mogelijk op. Onze gebruikers zijn dus per stuk veel en veel zwaarder dan normale gebruikers, normale (web)gebruikers wachten een behoorlijke tijd tussen elke request (lezen van het resultaat, etc). Daarnaast hebben applicaties die continu met de database verbonden zijn geen extra overhead van het steeds opnieuw verbinden en dergelijke.

Bovendien is onze database dusdanig van maat dat ie volledig in het ram-geheugen past van de machine, met als gevolg dat je nog meer de focus op de processoren en hun onderlinge communicatie legt.

En daar is de test dan ook voor ontworpen, om het systeem te testen, niet om te laten zien dat we "maar" 25 gebruikers tegelijk kunnen verwerken of om databases onderling te vergelijken.

Stop straks maar eens 4 of 8 Barcelona cores in dat ding en doe die test dan maar eens opnieuw. Schaalbaarheid problemen zal je houden maar die barcelona's zullen een stuk harder gaan.

Die Opteron core is ook niet veel vernieuwd in de afgelopen drie jaar. We hebben wel de stap van singel naar dual core gemaakt. En Met de barcelona krijgen we de stap naar quadcore + elke core zit heel anders in elkaar en is stukken sneller geworden en gaat evenveel stroom verbruiken. Dus de Performance per watt gaat maar dan 2x hoger worden.

Barcelona staat dan ook hoog op ons verlanglijstje om te mogen testen .

Ik ben benieuwd Want de schaalbaarheid naar 8 is natuurlijk een grote stap maar die kun je dan ook bereiken met een 4x quad core.

Hoe zit dit eigenlijk met de Intel cpu's ? hebben die wel 8 socket configuraties ? Ik heb namelijk een max van 4 in me hooft.

Intels eigen chipset ondersteunt niet meer dan 4 sockets, maar IBM en Fujitsu kunnen systemen gebaseerd op de X3-chipset met 8 sockets of meer leveren, tot maximaal 32.

En als je naar die schaalbaarheid kijkt ? Hoe gaat dat dan. aangezien de intel cpu's al veel minder bandbreedte per cpu hebben.

Dus ook daar zal wel gelden: Je hebt er alleen wat aan bij speciale applicaties.

Dat sowieso, maar de schaalbaarheid van X3 is toch nog vrij goed, waarom staat kort uitgelegd op pagina 1 van dit artikel, maar meer informatie is o.a. hier te vinden. Wat voorbeelden van benchmarks, beide niet ideaal, maar in ieder geval indicatief:

TPC-C:
4x 2,8GHz Opteron: 262989 (MSSQL)
4x 3,5GHz Xeon: 331087 (DB2/Linux)
8x 3,5GHz Xeon: 510822 (MSSQL)

SAP-SD:
4x 2,8GHz Opteron: 1987 (MSSQL)
4x 3,4GHz Xeon: 2127 (MSSQL)
8x 2,6GHz Opteron: 1650 (MSSQL)
8x 3,3GHz Xeon: 3350 (MSSQL)
16x 3,0GHz Xeon: 5205 (DB2/Windows)

De opvolger X4 die later jaar verwacht wordt zal nog meer bandbreedte en features hebben om de schaalbaarheid te verbeteren.

Ah ziet er zeker netjes uit. Dus AMD zou er wat extra HTT links tegenaan moeten gooien om het wat beter te maken of een chipset die het verkeer beter kan sturen. Misschien dat de hogere snelheid van HT3.0 ook al wat goed kan maken.

De extra link en splitsbaarheid daarvan zullen zeker helpen, je kunt met acht sockets zelfs alles aan elkaar knopen . Edit: waarbij het overigens wel even gezegd moet worden dat dit pas met de tweede generatie Barcelona kan, niet met degene die dit jaar komt.

En het feit dat de Barcelona's over 4 HT links beschikt, die elk dan nog eens kunnen gesplitst worden in twee 8 bit links. Dit zal de cache snooping overhead zeker verminderen.

True er zijn alleen wel genoeg veranderingen die ook mee helpen aan de schaalbaarheid. En de Pure performance per core is ook veel hoger. Maar je moet ook nog iets hebben om te verbeteren niet ?

mischien niet onverstandig om dit eens te vergelijken met een zware itanium multiproc omgeving en een heuse IBM multicore.

qua prijsklasse toch meer het allooi van deze sun.

Eerlijk gezegd is dit al een behoorlijk stap buiten wat we normaal doen. Dus "nog dikker" hoef je zeker voorlopig niet te verwachten, want we lopen er dan steeds meer tegenaan dat je eigenlijk het systeem helemaal niet kan benchmarken zoals ie in de praktijk gebruikt wordt, omdat ie zelden los verkocht wordt (dus zonder bijzondere storage e.d.)

Een Power5 of Itanium is desalniettemin wel interessant om een keer te bekijken, maar we zijn natuurlijk een beetje afhankelijk van wat de diverse hardware leveranciers ons willen en kunnen uitlenen.

Op zich zijn de conclusies goed. Maar ook weer niet...

Als ik namelijk de Melrow (2x Clovertown 2,66GHz) zou hebben en ik moet meer rekenpower hebben dan zou ik dus een tweede machine erbij kunnen zetten. Dat geeft al een probleem met synchroniseren van de interacties op de database. Ik zou dan al 3 systemen moeten nemen met twee voor de interacties en 1 met de database zelf. Met twee systemen zit ik al bijna op het opgenomen vermogen van de SUN.
Het is dan maar de vraag of ik dezelfde prestatiewinst krijg.

Dit blijft het grote probleem van computersystemen, de wet van de verminderde meeropbrengst.

Je hebt gelijk dat het een moeilijke afweging is. Hoe beter parallelliseerbaar, hoe makkelijker het in een cluster te plaatsen is. Er zijn overigens ook wel zuinigere oplossingen dan onze geteste Dual X5355, zeker met blade-systemen kom je waarsch aardig ver.
Maar als je wel goed multi-threaded kan werken, maar niet makkelijk het geheugen kan verdelen, dan zit je al bijna aan zo'n monster als dit vast.

Ik vind het erg jammer dan niet met FreeBSD is getest.
Laatst kwam ik een artikel tegen dat de schaalbaarheid van de nieuwe BSD kernel bij SMP systemen met 8 of meer processoren aan de kaak stelt, en BSD kwam een stuk beter uit de bus dan Linux. De test had betrekking op database toepassingen.
Zie:
http://people.freebsd.org/~kris/scaling/mysql.html
http://jeffr-tech.livejournal.com/5705.html
En vooral de grafiek hier:
http://people.freebsd.org/~jeff/sysbench.png

Dat hebben wij ook gelezen, maar als ik wat verder klik naar http://people.freebsd.org/~jeff/ , dan zie ik dat de diff van 25 februari is, wij hadden op dat moment de server niet meer in huis.
Verder zou het betekenen dat de test nog een half maal zo lang duurt, en als je bedenkt dat ACM en ik dit naast ons gewone werk doen, dan kun je je voorstellen dat dat wel extreem veel tijd gaat kosten.

Hardware kosten zijn eenmalige kosten, beheerskosten niet.