Hoofdcategorieën

Databasetest: Sun UltraSparc T1 vs. AMD Opteron

Door Wouter Tinus, donderdag 27 juli 2006 18:50, views: 67.100

Stroomverbruik, prijzen en conclusie

We kunnen helaas niets anders dan teleurgesteld zijn in de prestaties van de UltraSparc T1: zelfs met het perfect opschalende PostgreSQL wordt de machine keihard voorbijgestreefd door een middenmoot Opteron-server die voor net iets meer dan de helft van de prijs te koop is. Het is te hopen dat de T2000 zich in andere situaties beter houdt en de prestatiewinsten dan ook groot genoeg zijn om het prijsverschil te verantwoorden, want anders zou de chip met zijn radicale ontwerp wel eens onder de voet gelopen kunnen worden door concurrenten die de overstap naar multicore geleidelijker en conserveratiever aanpakken. Een pluspunt van de T2000 is wel dat de processor erg zuinig is: gemeten aan het stopcontact heeft het apparaat onder volle belasting slechts 232 watt nodig, terwijl de Opteron-server tijdens het uitvoeren van dezelfde taken bijna de helft meer verstookt. Gekeken naar de prestaties per watt in PostgreSQL komen we uit op een piek van 1,17 requests per seconde per watt voor de Opteron en 1,34 requests per seconde per watt voor de T2000, een verschil van ongeveer 15% in het voordeel van de Niagara. Sun zelfs wil in zijn zelfbedachte SWaP-maatstaaf ook nog de hoogte van de server meerekenen, maar aangezien beide 2U waren verandert dat in dit geval het beeld niet.

Stroomverbruik
Sun X4200 (4 cores, 2,4GHz) - load 341
Sun X4200 (4 cores, 2,4GHz) - idle 274
Sun T2000 (8 cores, 1GHz) - load 232
Sun T2000 (8 cores, 1GHz) - idle 223

Prijzen in euro's (bron: Sun.nl, 16-7)
X4200 (4-core, 2,4GHz, 8GB) 6800
T2000 (4-core, 1GHz, 8GB) 8300
T2000 (6-core, 1GHz, 8GB) 10900
T2000 (8-core, 1GHz, 8GB) 13400

Belangrijk om hier in de gaten te houden is dat we hier maar één applicatie hebben getest, namelijk de database van Tweakers.net. Dat de T2000 voor die toepassing geen goede keuze zou zijn betekent niet dat de machine direct afgeschreven moet worden: wellicht is hij bijvoorbeeld wel interessant als webserver. Sun heeft verschillende records gebroken met de T2000 en er zijn dus toepassingen te bedenken waar de processor beter in zijn element is. De belangrijkste conclusie die we kunnen trekken is dat kopers van deze server heel erg goed op moeten passen waar ze hem voor willen gebruiken, want als een applicatie toevallig net niet in het straatje van de UltraSparc T1 past kan het een dure miskoop zijn. Zulke risico's zijn bij servers met gewone Opterons of Xeons een heel stuk kleiner. Gelukkig begrijpt Sun dit zelf ook, en is het bedrijf erg behulpzaam voor mensen die de T2000 een keer willen uitproberen.

* De toekomst

De UltraSparc T1 is slechts de eerste van Suns nieuwe lijn processors. Als we de roadmap mogen geloven dan zal volgend jaar de op 65nm gebakken Niagara II verschijnen. Volgens de geruchten zal deze twee keer zoveel threads tegelijk kunnen verwerken, iets hoger klokken (maximaal 1,4GHz) en voor iedere core een eigen FPU hebben, in plaats van één gedeelde. Verder zou er in plaats van directe ondersteuning voor DDR2 overgestapt worden op FB-DIMM. In 2008 zou vervolgens Rock verschijnen, die vooral betere singlethread prestaties zou moeten bieden. Sun heeft volgens de geruchten een erg interessante manier bedacht om multithreading op een flexibele manier aan te pakken. In principe zouden zestien 'cores' ieder aan twee threads gaan werken, maar het cache zou worden gedeeld door groepjes van vier: ieder kwart van de processor zou 64KB L1 en 2MB L2 krijgen. Naar verluidt kunnen de cores echter niet alleen hun caches met elkaar delen, maar ook ongebruikte rekenkracht. Er zou dus ook wel gesproken kunnen worden over vier 'supercores' die ieder acht threads afhandelen.

Hoewel Sun een hoop innovatieve ideeën heeft voor toekomstige processors, heeft het wel een groot risico genomen door dit pad te bewandelen: de chip is lang niet zo breed inzetbaar als zijn x86-concurrenten en kan ook niet meedoen in de hogere marktsegmenten waar Power en Itanium leven. Uiteraard heeft het ontwerp wel zijn unieke sterke punten, maar hij zal op die gebieden erg goed moeten gaan verkopen om het wegvallen van de rest te compenseren. Op dit moment bewaakt de UltraSparc IV+ het fort nog, maar met het annuleren van diens opvolger zal de Niagara-lijn zich uiteindelijk helemaal zelf moeten gaan redden. Tot nu toe is nog niet gebleken dat de verkoopcijfers spectaculair zijn: in de presentatie over zijn meest recente kwartaalcijfers liet Sun wel weten dat ten opzichte van vorig jaar iets meer servers had verkocht, maar uit een nog veel sterkere stijging van de - pas geleden weer versterkte - Opteron-machines - kunnen we concluderen dat de Sparc-verkopen nog steeds dalende zijn. Op dit moment is Niagara goed voor 100 miljoen dollar omzet per kwartaal, op een totale serveromzet van 1,3 miljard.

Sun totale verkoop vs. x86 verkoop

Sun zal het ontwerp flink onder handen moeten nemen om het breder inzetbaar te maken, maar lijkt de laatste tijd alleen maar aan het bezuinigen te zijn op zijn de processorafdeling. Met het annuleren van de UltraSparc V raakten vijfhonderd man hun baan kwijt; later zijn er nog zestig naar AMD gegaan en recent zijn er weer tweehonderd ontslagen, onder andere mensen die bezig waren met co-processors voor Rock. Na het aftreden van Scott McNealy heeft de nieuwe CEO Jonathan Schwartz aangekondigd dat er nog eens vier- tot vijfduizend banen gaan verdwijnen bij Sun. Onduidelijk is in hoeverre de chipafdeling hierdoor wordt getroffen. Als Niagara en opvolgers geen succes worden zal het voor Sun waarschijnlijk geen grote ramp zijn: sinds vorig jaar heeft het een deal met Fujitsu om servers met diens Sparc64-processors te verkopen. Ook zou x86 een deel op zich kunnen nemen: Transitive (bekend van de PowerPC-emulator die Apple gebruikt voor zijn Intel-Macs) heeft zijn software pas geleden uitgebreid om ook Sparc te kunnen draaien.

Het is te hopen dat de Niagara een groot genoeg deel van de markt weet te veroveren om de toekomstige ontwikkeling te blijven rechtvaardigen. Diversiteit op de markt is namelijk goed voor de consument, en Sun zou met deze chips een van de weinige bedrijven kunnen worden die met succes het gevecht tegen de x86-bierkaai aangaat. We vragen ons echter hardop af of hoe ver Sun bereid is om hiermee te gaan: zal het er koste wat kost een succes van proberen te maken, of zal het hele concept slachtoffer worden van bezuinigingen als het niet snel genoeg geld in het laatje begint te brengen? Volgens Sun zelf is het bedrijf in ieder geval vastberaden om door te zetten: de roadmap loopt tot voorbij 2010.

Scott McNealy met UST1 Niagara

* Dankwoord

Tweakers.net wil graag de volgende mensen bedanken; Bart Muyzer en Hans Nijbacker (Sun Nederland) voor hun medewerking aan dit artikel en hun voortdurende inspanningen om de benchmarkresultaten te verbeteren; Jochem van Dieten (databaseconsultant en vaste GoT-bezoeker) voor zijn hulp met PostgreSQL; en natuurlijk ACM en moto-moi voor het uitvoeren van de tests en de hulp bij het verwerken en interpreteren van de resultaten.

T'rug naar huus


Inhoudsopgave


Reacties

«  1  2  »

Top-artikel Wouter d:)b

Leuk artikel, maar ik had naast deze T2000 ook nog de vergelijking gezien met bijvoorbeeld een Fire V440, die dan zou worden uitgerust met bijvoorbeeld 4 UltraSPARC's. Het lijkt me wel leuk om te weten hoe Sun's oude architectuur vergelijkt met de nieuwe. En natuurlijk met de Opterons. Een beetje een gemiste kans. Misschien voor de volgende keer?

Trouwens, ook leuk erbij te vermelden is dat Solaris nu eenmaal geschreven is met de SPARC architectuur in het achterhoofd, dus extra leuke opties zoals bijvoorbeeld predictive self healing heeft. Ook hier had ik graag wat meer over gehoord.

En last but not least, ik zou ook iets willen zien over deze machines en hun performance wat betreft Java applicaties. Want net als Solaris is Java ook ontwikkeld voor de SPARC bakken. Misschien is het een goed idee om een vergelijking te bouwen aan de hand van een WebLogic of JBoss webapplicatie?

Trouwens, ook leuk erbij te vermelden is dat Solaris nu eenmaal geschreven is met de SPARC architectuur in het achterhoofd, dus extra leuke opties zoals bijvoorbeeld predictive self healing heeft. Ook hier had ik graag wat meer over gehoord.
Aangezien Solaris niet een platform is wat wij dagelijks draaien kun je je zo voorstellen dat we niets alles getest en/of geprobeerd hebben ;) Ik ben met je eens dat Solaris erg lekker werkt, al voelt het in eerste instantie wel wat spartaans aan voor een GNU/Linux admin
Misschien is het een goed idee om een vergelijking te bouwen aan de hand van een WebLogic of JBoss webapplicatie?
Probleem daarmee is dat wij geen jboss applicaties hebbe draaien, waardoor je terug zou moeten vallen naar standaard benchmarks en die vinden wij nou net niet zo interesant omdat die vaak niet realistische situaties testen.

Java ontwikkeld voor de SPARC bakken? Hoe kom je daarbij? Java is ontwikkeld als platform-onafhankelijke programmeertaal.

Dan draai jij maar eens dezelfde Java code op een 3 GHz Intel machine en op een 1500 MHz SPARC. Als je geluk hebt kan de Intel net nog de (2 keer zo trage, ik zeg het er graag bij) SPARC bijbenen...

Sinds wanneer is een 1.5Ghz Sparc "twee keer zo traag" als een 3Ghz Pentium/Xeon?

Je wilt toch niet beweren dat je hier op een dergelijke server-gerelateerde review reageert met de suggestie dat kloksnelheid de enige factor is die de snelheid van een processor bepaalt?

Wat voor AMD met de Athlon al jaren geldt, en Intel met de introductie van de Pentium M ook al weer een tijdje, gaat hier natuurlijk ook op.

Bovendien zal die Sparc met Solaris gedraait hebben en die Intel-machine vast niet? Dat is alleen om die reden al minder eerlijk vergelijken.

Magoed, het is heel wel mogelijk dat de Sparc relatief gezien sneller is met Java dan Intel en AMD processoren.

Dan draai jij maar eens dezelfde Java code op een 3 GHz Intel machine en op een 1500 MHz SPARC.
Ja maar Intel is zowiezo al traag. :+
:>

Voor database-toepassingen is de T1 idd niet zo rapido. Wanneer je ook kijkt hoe dit zich vertaald in prijzen voor software, dan zie je dat je voor bijv. een oracle licentie het aantal core's v/d T1 mag delen door 4: In het geval van de 8 Core versie heb je dus maar 2 CPU licenties nodig (waar je voor 8 RISC core's er 8 x 0.75=6 core's voor nodig hebt, scheelt ff 4x 40.000 US$)....RISC heeft van nature een hogere efficiency voor database berekeningen.

Zou zeker interessant zijn om ook nog een vergelijk op verschillende toepassingen te zien.

SPARC is anders ook een RISC architectuur, wellicht bedoelde je POWER?

Ik mag alleen maar concluderen dat ik hoop dat een opvolgend onderzoek gedaan wordt zodra die Niagra II uit is. Als dat ding inderdaad een FPU per core, en nog wat andere zaken verbeterd heeft tov de eerste variant, dan kan het zijn dat we daar nog wat extra power zien.

Dat valt wel mee, het aantal FPU berekeningen in onze test lag heel erg laag, minder dan 0.1%

mooie test ik zou zeggen smijt er nu nog een woodcrest 2,66 bij en we kunnen weeral verder...

maar nu moet ik wel zeggen dat het gebruik van solaris en oracle deze niagra echt onklopbaar is tov de oudere sparc generaties... zeker kwa prijs.

Sorrie, lange quote:
In MySQL 5.0 zijn een hoop problemen met betrekking tot de schaalbaarheid opgelost, wat zich vertaalt naar duidelijk hogere prestatiepieken. Desondanks valt er met acht cores nog steeds weinig winst te halen, en bovendien is er een vrij dramatisch nieuw gedrag geïntroduceerd. Bij zwaardere belasting (meer dan 40 gelijktijdige gebruikers) zakken de prestaties als een plumpudding in elkaar. Erger nog: hoe hoger de piek, hoe dieper het dal. Waar we bij 25 gelijktijdige gebruikers nog logische resultaten terugkrijgen, komen er bij 50 en hoger bizarre situaties naar voren waarin 1 core sneller is dan 8 cores. De reden hiervoor is niet duidelijk: noch onze ervaren systeembeheerders, noch de experts bij Sun en MySQL konden voor een oplossing zorgen. Ook experimenten met verschillende (bèta)versies leverden geen enkele verbetering op, waardoor we voor nu gewoon moeten accepteren dat het zo is.
Ehh, misschien het gewoon een I/O bottleneck (1 server) met de 2 HDDs ?
Hoe meer concurrency, hoe minder throughput. 8 cores stressen de HDD I/O concurreny natuurlijk meer dan 1 core. Blijkbaar is ~50 requests/s de bottleneck met 2 HDDs en/of 1 controller.

Meer HDDs en/of 1 of meerdere knappe controllers met veel cache zouden dat verhelpen. Normaal RAM zit er al genoeg in :Y)

EDIT: Tja, als 't echt allemaal in goed in RAM gecache't & voornamelijk read-only is; misschien slipt er ergens wel een (dirtyflag ?) interrupt-requestje doorheen in een slechte module of zelfs driver ... Die dingen kunnen dodelijk zijn voor de performance/schaalbaarheid en hebben dezelfde symptomen.

misschien het gewoon een I/O bottleneck (1 server) met de 2 HDDs ?
Nee. De dataset is maar een paar GB (inclusief indexen) en er zit 8 GB RAM in dus is de dataset volledig in cache. De query load is bijna read-only dus daar zit ook geen I/O load.

Nee, in de x4200 (met solaris) zaten precies zulke disks, voor de Linux-benchmark van die doos gebruikten we twee redelijk daarmee vergelijkbare losse (dus geen raid 0) WD Raptors en ook eerder al waren we tot de conclusie gekomen dat I/O geen bottleneck in deze benchmark is.

We zijn er van overtuigd dat disk IO nauwelijks een probleem is, en bovendien waren ook de postgres, mysql 4.1 en mysql 5.1 resultaten met precies dezelfde disk-configuratie uitgevoerd. Als MySQL 5.0 dan ineens wel een i/o-probleem heeft zou dat alsnog een bug in die software zijn ;)

Tja, het is de eerste uit de serie he, dus verwacht nog geen extreem goede resultaten, ik vind dat hij het aardig doet en kijk zeker uit hier meer over te horen :)

Hiermee levert de T2000 betere prestaties per watt, maar dat is in onze situatie een schrale troost.
Daar gaat het toch om in een moderne server en is dat ook niet de reden dat Sun aan dit soort chips werkt? Ik vind niet dat zo'n belangrijk punt even tussen neus een lippen door gezegd wordt, het is nogal een vinding namelijk.

Niet in de context waarin die opmerking gemaakt wordt, waarbij de absolute prestaties achterblijven, terwijl de prijs bijna 2x zo hoog is.

't Is zeker een belangrijk punt. Het apparaat is heel erg zuining. Jammer dat al die fans en de beide voedingen het enorm lage verbruik van de processor een beetje teniet doen...

Maar feit blijft dat die server wel zo'n twee keer zo duur is. Met een extreme dichtheid en/of andere toepassingen kan het natuurlijk alsnog een heel interessant apparaat zijn, zeker als je zelf voor de koeling moet zorgen en/of de elektriciteitsrekening zelf moet betalen.

Daar gaat het toch om in een moderne server en is dat ook niet de reden dat Sun aan dit soort chips werkt? Ik vind niet dat zo'n belangrijk punt even tussen neus een lippen door gezegd wordt, het is nogal een vinding namelijk.
De prestaties per watt kunnen in sommige gevallen belangrijk zijn, maar zeker niet ten koste van alles. Als je extra machines nodig hebt vanwege een gebrek aan absolute prestaties, of het jaren duurt voor het verschil in aanschafprijs wordt terugbetaald door een lagere stroomrekening*, dan is het ineens helemaal niet zo'n voordeel.

* Als het verschil 110 watt is zoals wij hebben gemeten, dan bespaar je uitgaande van een kWh-tarief van 0,15 euro maar 0,0165 euro per uur. Na zeven jaar - wat een érg lange tijd is om een server te blijven gebruiken - heb je dan duizend euro minder aan stroom uitgegeven, en misschien nog eens duizend euro minder aan koeling in je serverruimte. Met prijsverschillen die oplopen tot 6000+ euro is het dus lang niet altijd verantwoord om voor de prestaties per watt te gaan ;).

Mee eens, echter als de performance betekent dat je opeens een extra server moet aanschaffen dan is het argument opeens zeer bewerkelijk. En dan heb ik het nog niet over de aanpassingen in de software.

Enkele maanden terug was ik nog bij Sun in Schotland waar de man, nochtans een technisch iemand, die ons rondleidde zo lyrisch was over de Niagara.

Met vettig Scottisch accent:
"Twice the performance at half the cost, and half the power consumption. None of our competitors can match this, they don't stand a chance against this!
De man had blijkbaar teveel naar zijn eigen marketingmensen geluisterd :)

Al bij al toch redelijke prestaties voor een eerste keer. Ik ben benieuwd of het bij de tweede generatie wel lukt.

Feit is dat SUn meer prestaties levert per watt, ik zie niet in hoe dat geen mission accomplished kan zijn?

Er zijn wel degelijk situaties waar ie wel vliegt, maar niet in onze test :)

Nee jullie hebben de testen gedaan, niet het vervoer :Y)

Leuk verhaal, maar jammer dat de T1 gebruikt wordt voor DB-doeleinden. Sun zegt namelijk zelf voluit dat een T1 niet geschikt is voor het zware werk. Daar hebben we nogsteeds de Ultrasparc IV+ (overigens heeft iemand van Sun mij verteld dat de Ultrasparc IV+ niet de Utrasparc V is geworden vanwege het beperkte aantal veranderingen)

Sun zelf zegt de T1 vooral in te zetten voor doeleinden met vele en korte requests/afhandelingen (webserver bijvoorbeeld). Er vanuit gaande dat we tegenwoordig in de 3-tier wereld leven, dan ziet Sun de T1 in de front-layer en een Ultrasparc IV+ helemaal achteraan (daar waar de databases draaien dus). Er tussenin passen prima de Opterons (Sun twijfelt al om hier een T1 in te zetten).

Als ik overigens mijn omgeving kijk, dan zie ik Sun (en dus ook Solaris) een enorme stap voorwaards maken, vooral tenkoste van HP (Dat Tru64 zo geweldig heeft weten te verprutsen)

Volgens Sun's eigen website:

Key Applications

* Web and portal servers
* Java application servers and Java Virtual Machines
* Network infrastructure services (identity, network, security, and proxy caching)
* Mail and messaging applications
* Streaming media
* Enterprise application server
* Database node

Omdat we I/O uit de vergelijking hebben gehaald zie ik niet in waarom deze test relatief ongunstig voor de T2000 is. Natuurlijk zal de T2000 wat beter presteren als ie juist relatief veel moet wachten op per client, maar dan heel veel (webserver, mailserver, e.a.), maar ik heb niet de indruk gekregen van de Sun-mensen die bij ons op bezoek kwamen dat dit buiten hun beoogde spectrum valt.

Als ik het goed begrijp hebben jullie in een kort tijdsbestek de database van mysql naar postgresql geporteerd en daar betere prestaties gehaald.
Gaan jullie tweakers db nu overzetten?

Het was behoorlijk wat werk om de data om te zetten, maar dat was desalniettemin het makkelijke deel...
Er is namelijk maar een vrij klein, hoewel wel het belangrijkste, deel van de alle queries van de website omgeschreven van een "mysql optimised"-formaat naar een formaat waar postgres wat beter mee kon presteren.

Niettemin vond ik het persoonlijk een interessante ervaring dat het toch relatief eenvoudig omgezet kon worden. Echter durf ik niet te zeggen of we de uren die er in postgres-ondersteuning gestoken zouden moeten worden wel echt kunnen verantwoorden.
De prestaties zullen er iig niet noemenswaardig door afnemen, dat is op zich wel een prettige geruststelling.
«  1  2  »

Op dit item kan niet meer gereageerd worden.

VNU Media logo Powered by True

© 1998 - 2009 Tweakers.net - Alle rechten voorbehouden - Uw Privacy - Algemene Voorwaarden

Uitgever van: