Databasetest: achtvoudige Opteron

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

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

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.