Inleiding
For your convenience, an
English translation of this article is available.
Toen we een paar maanden terug voor het eerst onze handen legden op een server met twee Intel Xeon 'Woodcrest'-processors, waren we zeer onder de indruk van de prestaties ervan. Dit leverde niet alleen een uitgebreide review op, maar was ook de belangrijkste reden om bij het configureren van Apollo 5 - de nieuwe databaseserver van ons forum Gathering of Tweakers - voor deze chips te kiezen. Inmiddels is de nieuwe machine al in gebruik genomen, maar voor hij in Amsterdam werd opgehangen is hij natuurlijk eerst grondig getest. In deze review worden de resultaten van onze benchmarks behandeld.
Apollo 5 is een Dell PowerEdge 1950, een ander beestje dan de Fujitsu-Siemens RX300 S3 die we eerder onder de loep namen. De twee merken onderscheiden zich van elkaar op het gebied van design, prijs, uitbreidings-, beheer- en servicemogelijkheden. Omdat de twee zijn opgebouwd met dezelfde chipset is er echter geen reden om te aan te nemen dat het merk in deze specifieke test een significante rol speelt. Voor andere werklasten - waarbij meer I/O komt kijken - kan dat overigens anders uitpakken, maar we gaan er in dit verhaal vanuit dat het verwaarloosbaar is. Er zijn wel andere verschillen tussen de machines om naar te kijken, anders zouden we natuurlijk snel klaar zijn met deze review. We hebben een duurdere versie van de processor gekozen, meer en sneller geheugen besteld en een andere opslagcontroller geïnstalleerd. Een overzicht van de verschillen:
| | RX300 S3 | Apollo 5 |
|---|
| Processors | Xeon 5150 (2,66GHz, 65W) | Xeon 5160 (3,0GHz, 80W) |
| Geheugencapaciteit | 8GB (8x1GB) | 16GB (8x2GB) |
| Geheugensnelheid | 533MHz (17,1GB/s) / CL4 (7.5ns) | 667MHz (21,3GB/s) / CL5 (7.5ns) |
| Storagecontroller | Areca ARC-1120 (128MB) | Dell PERC 5/E (256MB) |
Op basis van dit tabelletje zal het voor niemand een verrassing zijn dat de nieuwe Apollo nog sneller is dan het systeem dat we eerder hebben bekeken, dus wat dat betreft zal dit artikel geen verrassingen bevatten. Wel kunnen we dankzij de cijfers van Apollo 5 meer conclusies trekken over het schaalgedrag van de Xeon en het effect van de nieuwste Linux-kernel, versie 2.6.18. Ook hebben we naar aanleiding van dit nieuwsbericht gekeken naar het effect van de hardwarematige prefetchers op onze test.
Belangrijk om in de gaten te houden is dat onze benchmarkmethode voor het grootste deel onafhankelijk is van I/O-prestaties en hoeveelheid geheugen. Zolang er maar minimaal (iets meer dan) 4GB in de server zit worden de harde schijven nauwelijks meer gebruikt. Voor ons oorspronkelijke artikel is de RX300 getest met 6x 1GB en 2x 512MB (7GB totaal), terwijl we dit keer gewoon 8x 1GB tot onze beschikking hadden. Opnieuw testen was sowieso nodig vanwege de nieuwe kernelversie, maar eigenlijk is het verschil tussen 7GB, 8GB en 16GB niet te merken in deze benchmark (in de GoT-productieomgeving is dat overigens wel anders 
).
Linux-kernel 2.6.15 vs. 2.6.18
Toen we de resultaten van Apollo 5 in PostgreSQL 8.2-dev vergeleken met de benchmarks uit onze vorige review werden we in eerste instantie positief verrast door het verschil. De initiële blijdschap sloeg echter al snel om in achterdocht, want theoretisch gezien was het bijna onmogelijk dat onze nieuwe Dell-machine zó veel beter presteerde dan de Fujitsu-bak die we eerder hadden getest. Al snel werd de theorie geformuleerd dat de nieuwe versie van de Linux-kernel een rol zou kunnen spelen. Vanwege driverproblemen moest Apollo namelijk kernel 2.6.18 draaien, terwijl we eerder met 2.6.15 hadden getest. Om deze theorie te staven werd de RX300 ook opgewaardeerd naar de nieuwe versie, waarna inderdaad bleek dat dit een flinke stempel op de prestaties drukt. In de ontwikkelversie van PostgreSQL 8.2 bleek de eenvoudige update voor een prestatiewinst van zo'n 19 procent te zorgen bij belastingen van 25 of meer gebuikers.
MySQL daarentegen vertoont een heel ander beeld: met één core ingeschakeld worden er nog wel aardige winsten geboekt, maar zodra er met meerdere threads gewerkt moet worden slaan de winsten om in verliezen. Omdat het geen optie was om Apollo 5 met de oude kernel te draaien is besloten om de Fujitsu-machine helemaal opnieuw te testen met de nieuwe kernel. De rest van de cijfers in dit artikel zijn dus allemaal verkregen met versie 2.6.18.
| Verschil kernelversie | MySQL 4.1.20 | MySQL 5.0.20a | PostgreSQL 8.2-dev |
|---|
| 1x singlecore | +6,2%  | +2,9% | +20,2% |
| 2x singlecore | -2,7%  | -4,4% | +20,2% |
| 1x dualcore | -1,9% | -5,8% | +18,7% |
| 2x dualcore | -1,6% | -5,7% | +16,0% |
| Gemiddeld | 0% | -3,3% | +18,8% |
Invloed prefetchers
In september publiceerde AMD een aantal opvallende benchmarks van een Xeon Woodcrest-systeem, waarmee men de aandacht van het technische publiek leek te willen vestigen op de hardwarematige prefetchers. In de SPECjbb2005-benchmark bleek de server ongeveer 14 procent trager te worden zodra de prefetchers werden ingeschakeld, ondanks Intels pogingen om dit soort negatieve bijeffecten te voorkomen. Een mogelijke verklaring voor dit effect is dat softwarematige en hardwarematige prefetchers elkaar in de weg kunnen lopen, maar dat is slechts speculatie. Om te kijken hoe de prefetchers onze test beïnvloeden hebben we in het BIOS van Apollo 5 de twee opties 'Hardware Prefetcher' en 'Adjacent Cache Line Prefetcher' tijdelijk uitgeschakeld. We kregen toen echter een ander beeld te zien dan in SPECjbb2005: in ons geval bleken de prefetchers wel degelijk voor een positieve bijdrage te zorgen, hoewel die niet overal even groot is. MySQL 5.0.20a profiteert er het minst van en PostgreSQL 8.2 het meest:
| Effect prefetchers | MySQL 4.1.20 | MySQL 5.0.20a | PostgreSQL 8.2-dev |
|---|
| 1x singlecore | +13,1% | +5,1% | +9,9% |
| 2x singlecore | +8,8% | +8,8% | +11,7% |
| 1x dualcore | +8,3% | +12,4% | +16,3% |
| 2x dualcore | +6,2% | +2,6% | +10,6% |
| Gemiddeld | +9,1% | +7,2% | +12,1% |
Woodcrest 2,66GHz vs. 3,0GHz
Nu we de prefetchers en kernelversies hebben bekeken is het tijd om de twee machines direct tegenover elkaar te zetten. Voor de duidelijkheid: voor beide servers is gebruikgemaakt van de nieuwe kernelversie en de prefetchers staan zowel bij Apollo 5 als de Fujitsu-server aan. Hieronder is te zien wat het effect van de 12,5% hoger geklokte processors en 25% extra geheugenbandbreedte is. In de onderstaande tabel worden zoals gewoonlijk alleen de resultaten van zware belastingen meegenomen (25+ gebruikers):
| 2,6GHz/533 vs. 3GHz/667 | MySQL 4.1.20 | MySQL 5.0.20a | PostgreSQL 8.2-dev |
|---|
| 1x singlecore | +13,3% | +12,8% | +9,2% |
| 2x singlecore | +11,3% | +14,9% | +11,1% |
| 1x dualcore | +13,4% | +18,8% | +14,3% |
| 2x dualcore | +10,1% | +10,2% | +9,9% |
| Gemiddeld | +12,1% | +14,1% | +11,1% |
Vergelijking schaalgedrag
Wanneer we het schaalgedrag van beide servers vergelijken zien we op sommige plaatsen een beperking opdoemen: de stap van één naar twee processors verloopt met alle drie de databases minder soepel dan voorheen. Hoewel de absolute resultaten natuurlijk nog steeds niet mis zijn, zien we bijvoorbeeld bij MySQL 5.0.20a dat het toevoegen van een tweede Woodcrest - die toch minstens 851 dollar kost - maar 6% betere prestaties oplevert. Het is niet zo dat deze versie van MySQL op andere platforms wel goed schaalt, maar toch is het in onze ervaring een dieptepunt.
De mindere schaling van de snellere chip kan niet zonder meer verklaard worden door een gebrek aan bandbreedte: de kloksnelheid - en daarmee de theoretische rekenkracht van de processor - is namelijk maar met 12,5% toegenomen, terwijl de geheugens in theorie 25% meer bandbreedte leveren. Op papier zijn er per kloktik dus ruim tien procent meer bytes beschikbaar voor de processors van Apollo 5, dan voor die van de Fujitsu RX300. De latency is wel iets hoger geworden: het ene systeem heeft 533MHz CL4-geheugen, terwijl het andere met 667MHz CL5-repen draait. Niet ontoevallig kan dit in beide gevallen omgerekend worden naar 7.5ns. Omdat een processor de tijd alleen in kloktikken ervaart gaat dezelfde latency relatief echter steeds langer duren naarmate de frequentie hoger wordt. Voor een 2,66GHz-chip gaan er bijvoorbeeld 20 tikken voorbij in die 7.5ns, terwijl een 3,0GHz-versie 22,5 keer klokt - een toename van 12,5%.
Een andere factor die bij kan dragen aan het slechtere schaalgedrag zijn zwaarder belaste bussen. De dubbele 1333MHz FSB heeft in theorie precies dezelfde bandbreedte als de vier geheugenkanalen, maar laat geen speelruimte over voor communicatie tussen de processors onderling. Als er meer werk verricht wordt neemt ook de onderlinge communicatie toe, waardoor een kleiner percentage beschikbaar is voor het lezen en schrijven van data. Verder geldt het latencyverhaal natuurlijk ook voor berichten tussen de processors onderling. Een laatste factor die mee kan spelen is dat het (minieme) aantal I/O-acties toeneemt door de hogere doorvoersnelheid.
 |
 | Woodcrest 2,66GHz / 533MHz FBD | |
|
| Performance scaling | |
|
| MySQL 4.1.20 | 1x single -> 1x dual |      34% | |
|
| MySQL 4.1.20 | 1x dual -> 2x dual | 17% | |
|
| MySQL 4.1.20 | 1x single -> 2x dual | 56% | |
|
| MySQL 5.0.20a | 1x single -> 1x dual |    22% | |
|
| MySQL 5.0.20a | 1x dual -> 2x dual | 14% | |
|
| MySQL 5.0.20a | 1x single -> 2x dual | 40% | |
|
| PostgreSQL 8.2-dev | 1x single -> 1x dual |    76% | |
|
| PostgreSQL 8.2-dev | 1x dual -> 2x dual | 84% | |
|
| PostgreSQL 8.2-dev | 1x single -> 2x dual |  224% | |
|
|
| Woodcrest 3,0GHz / 667MHz FBD | |
|
| Performance scaling | |
|
| MySQL 4.1.20 | 1x single -> 1x dual | 34% | |
|
| MySQL 4.1.20 | 1x dual -> 2x dual | 13% | |
|
| MySQL 4.1.20 | 1x single -> 2x dual | 52% | |
|
| MySQL 5.0.20a | 1x single -> 1x dual | 29% | |
|
| MySQL 5.0.20a | 1x dual -> 2x dual | 6% | |
|
| MySQL 5.0.20a | 1x single -> 2x dual | 37% | |
|
| PostgreSQL 8.2-dev | 1x single -> 1x dual | 84% | |
|
| PostgreSQL 8.2-dev | 1x dual -> 2x dual | 77% | |
|
| PostgreSQL 8.2-dev | 1x single -> 2x dual | 226% | |
|
Overzicht
Onze tweede ervaring met Intels Woodcrest-Xeon was eigenlijk net zo goed als de eerste. Het iets mindere schaalgedrag werd ruim gecompenseerd door betere absolute prestaties. Zoals wel vaker het geval is met topmodellen bieden de Xeon 5160-processors in Apollo 5 echter niet het meeste waar voor hun geld: de 3,0GHz-modellen zijn 23% duurder dan de 2,66GHz-versies en hebben bovendien een 23% hoger TDP, terwijl ze in ruil daarvoor maar ongeveer 10% betere prestaties te bieden hebben. In onze situatie is het niet nodig om op iedere watt of euro te bezuinigen, maar er zijn natuurlijk een hoop klanten die zich die luxe niet kunnen veroorloven.
Hoewel het benchmarken van Apollo 5 niet tot schokkende nieuwe conclusies heeft geleid, hebben we wel alweer het zesde datapunt verzameld in onze serie van serverreviews, een mooie referentie om in toekomstige artikelen naartoe te kunnen wijzen. Om af te sluiten geven we daarom nog even een overzicht van alle hardware die we tot nu toe getest hebben: Apollo 5 (3,0GHz Woodcrest), Fujitsu-Siemens RX300 (2,66GHz Woodcrest en 3,73GHz Dempsey), Sun Fire X4200 (2,4GHz Opteron Socket 940), Sun Fire T2000 (1,0GHz Niagara) en MSI K9SD Master (2,4GHz Opteron Socket F). Uitgebreide specificaties van al deze machines zijn hier te vinden.
Apollo 5 wordt in het rek geschoven, klaar om tot ruim 500 tweakers per seconde te kunnen bedienen
Eerdere artikelen in deze serie
4-9-2006: Intel Xeon 'Woodcrest' 2,66GHz
30-7-2006: AMD Opteron Socket F
27-7-2006: Sun UltraSparc T1 vs. AMD Opteron
19-4-2006: Xeon vs. Opteron, single- en dualcore
:strip_icc():strip_exif()/u/29534/moto-icon.jpg?f=community){kind=icon}
/u/1830/acm.png?f=community){kind=small}
/u/8555/Shadow_60x60.png?f=community){kind=small}
:strip_exif()/u/818/we33ee45.gif?f=community){kind=small}
:strip_exif()/u/7759/red_cat.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/45765/3dfx2.jpg?f=community){kind=small}
.