Vergelijking van dual-cpu databaseservers

Omdat de resultaten van de TPC, een van de standaardbenchmarks voor databaseservers, niet altijd even onafhankelijk zouden zijn, startte de Provinciale Hogeschool West-Vlaanderen (PIH) samen met AnandTech een project om onafhankelijke benchmarks van databaseservers te publiceren. De tests zijn vooral gericht op servers voor MKB's en worden onder andere uitgevoerd met DB2 en MySQL. Een van de basisstellingen die ook voor TPC gehanteerd worden, stelt dat voor databaseservers vooral snelle I/O en grote caches belangrijk zijn. In dit project wordt gecontroleerd of dit wel helemaal klopt. Andere vragen die men probeert te beantwoorden gaan over het nut van 64-bit, twee of meer processors en geheugensnelheid.

Op een presentatie in de PIH had men vorige week al even enkele indrukken vermeld. Zo leek het erop dat 64-bits-ondersteuning een prestatiewinst van 15 procent kon opleveren in DB2 en 30 procent in MySQL. De geheugensnelheid bleek minder van belang te zijn, terwijl een tweede processor maar liefst 45 procent betere prestaties veroorzaakt. Een derde en vierde cpu voegden daar volgens de spreker nog eens 38 procent aan toe. In het artikel gaat men echter uitgebreider op alle resultaten in en schotelt men ons ook de behaalde resultaten voor.

Om de haalbaarheid van het project te garanderen, concentreert men zich in het gepubliceerde artikel op single- en dual-processorsystemen. Bovendien wordt vooral de leessnelheid gemeten. Dit wordt gedaan om zich op een specifieke sector te kunnen concentreren, namelijk op applicaties die slechts weinig gegevens naar de database schrijven, maar wel heel wat gegevens ophalen. Bovendien kan men zich op deze manier concentreren op het platform met nadruk op de processor en het geheugen en wordt de invloed van de harde schijf beperkt. Het testen gebeurde met Suse SLES 8 met een 2.4.21-kernel. De clientapplicatie die de queries aan de database moet voorschotelen, werd door een student van de PIH geschreven in VB.NET. Op dit moment worden DB2-, MySQL- en MS SQL Server-databases ondersteund.

In de test worden heel wat verschillende servers meegenomen, gaande van een dual Intel Nocona op 3,6GHz met 1MB L2-cache en 2GB RAM tot een HP DL-145. De meeste systemen zijn echter rond een of meer Opterons gebouwd, met slechts twee Intel-servers. AnandTech is echter van mening dat dit in de toekomst zal veranderen, onder andere als de nieuwe Xeon-chips beschikbaar worden. Wel merkt men op dat de dual-Xeon-server voorzien is van Intels Lindenhurst-chipset, het serverequivalent voor de i925-chipset. Het SE7520AF2-moederbord is dan ook een van de eerste borden die nadrukkelijk gebruikmaken van DDR2- en PCI Express-mogelijkheden. Een voordeel hierbij is dat de Lindenhurst-server over vier DIMM-sockets per kanaal kan beschikken, terwijl de Xeons met DDR-I het met een maximum van vier DIMM's in totaal moeten stellen.

In de conclusie wordt eerst en vooral vermeld dat het benchmarken van databases een gecompliceerde bezigheid is. Echte databases worden nauwkeurig getweakt en zo ingesteld om maximale prestaties te leveren en de manier waarop de database benaderd wordt, kan een grote invloed hebben op de resultaten. Desondanks kan men toch enkele conclusies formuleren. Zo blijkt dat I/O-snelheid niet de belangrijkste factor is voor toepassingen die veel gegevens uit een database opvragen. De CPU blijkt namelijk, bij DB2 nog meer dan bij MySQL, een belangrijke invloed te hebben op de prestaties. Een tweede conclusie stelt dat de Opterons de Xeons met ruime afstand weten voor te blijven in de MySQL-tests. Met de Nocona heeft Intel echter een zeer goede comeback gemaakt. Wel blijkt uit de testresultaten dat de 3,2GHz Xeon met 2MB L3-cache te duur is in vergelijking met zijn Nocona-broertje op 3,6GHz.

Reacties (32)

Omdat de resultaten van de TPC, een van de standaardbenchmarks voor databaseservers, niet altijd even onafhankelijk zijn,

Op basis van wat wordt deze bewering gedaan? TPC is juist een onafhankelijke organisatie voor database benchmarks! Ga maar kijken HOE ze de results beoordelen.

De tests zijn vooral gericht op servers voor MKB's en worden onder andere uitgevoerd met DB2

DB2 is wel de overall marktleider, maar in het MKB wordt toch erg veel met sqlserver gedaan of *shiver* met access. DB2 is ook niet echt goed geprijsd voor het MKB, die veelal de geavanceerde functionaliteit van DB2 niet nodig heeft.

Voor zover ik begrepen heb, zijn het de fabrikanten zelf die resultaten (of systemen?) voor TPC kunnen insturen

Het probleem is daarbij dat ze hun systeem helemaal gaan finetunen zodat er geen realistische bedrijfssituaties meer ontstaan. Denk maar aan het gebruik van RAID0 voor de benchmark, iets wat je op geen enkele databaseserver ook werkelijk zult tegenkomen

Voor zover ik begrepen heb, zijn het de fabrikanten zelf die resultaten (of systemen?) voor TPC kunnen insturen

Klopt, maar wel onder de regels van de TPC. Overigens is het veelal de hw fabrikant die samen met een software leverancier de tests inlevert, bv IBM en MS of HP en MS.

Het probleem is daarbij dat ze hun systeem helemaal gaan finetunen zodat er geen realistische bedrijfssituaties meer ontstaan. Denk maar aan het gebruik van RAID0 voor de benchmark, iets wat je op geen enkele databaseserver ook werkelijk zult tegenkomen

Lijkt me niet echt helemaal de waarheid. Heb je al eens gekeken naar de opstellingen van de systemen? De systemen zijn gewoon te koop (kosten vaak wel een paar centen) en uiteraard getuned, dat doet een goede DBA en een goede software afdeling ook.

TPC is een benchmark organisatie, dus welke is de snelste. Uiteraard zullen sommige organisaties consessies doen mbt snelheid, het is voor een benchmark tenslotte, maar moet men t.a.t. de regels van de TPC benchmark in acht houden. Dit houdt bv in bij de TPC-C dat transactional data ook echt transactional is. Die benchmarks zijn dermate groot dat er niet met raid-0 of raid-5 wordt gewerkt maar met grote file-cabinets.

De opmerking over dat de TPC niet betrouwbaar zou zijn is IMHO echt onzin. Sterker nog, als ik dit artikel zo lees dan is dit onderzoek juist niet betrouwbaar. Er wordt nl. geconcludeerd dat de CPU juist de belangrijkste factor is. Nee, bij DB2 en MySql, 2 databases die geen dyn. optimizer hebben zoals SqlServer, DAN heb je de cpu nodig (DB2 compileert nl. alles naar gewone C code). Verder is een onderzoek waarbij de nadruk op LEZEN ligt niet interessant voor het MKB, waar je juist databases gebruikt voor klantengegevens en transactie-gegevens, i.e.: waar juist wel veel wordt geschreven.

Verder is een onderzoek waarbij de nadruk op LEZEN ligt niet interessant voor het MKB, waar je juist databases gebruikt voor klantengegevens en transactie-gegevens, i.e.: waar juist wel veel wordt geschreven.

Precies, en juist in lezen is mysql goed. Om mysql voor transacties te optimatiseren is een stuk moeilijker, zeker als je bedenkt dat mysql transacties niet eens zo lang ondersteund. (itt SQLserver/Oracle). Bovendien is TPC-C een suite, waar je niet wordt verondersteld 1 stukje uit te nemen.

Naar mijn weten wordt vaak RAID 1+0 gebruikt bij dergelijke tests. Dit enerzijds om de dure RAID 5 XOR operatie niet uit te hoeven voeren en anderszijds dat één schijf te mirroren als deze defect is een 1 op 1 kopie is en niet WEER die dure XOR operatie gebruikt hoeft te worden om een schijf te herstellen.

XOR is helemaal niet duur.

Vooral in een Dual of Quad cpu systeem merk je er weinig van.

Waar slaat dit nou weer op, je gebruikt bij dit soort systemen een hardware raidcontroller. Zelfs op een single cpu merk je er niks van....

duur in de manier van zwaardere berekeningen. Als in een 0+1 opstelling 1 schijf wegvalt, vervangt de andere gewoon deze. In Raid 5 moet, als 1 schijf wegvalt, de processor, met behulp van de andere schijven zelf terug de data eerst berekenen en daarna kan hij deze pas terug gebruiken.

Kwa kostprijs is een 0+1 duurder (min 4 schijven) dan een 5 (min 3 schijven) voor eenzelfde prestatie ALS alle schijven werken.

Vergeet excel niet, dat wordt ook heel veel gebruikt als "database" in kb.

Ja, vergeet dan ook niet de ordners en kaartenbakken...niet elke emmer is een databases...

startte de Provinciale Hogeschool West-Vlaanderen (PIH) samen met AnandTech

Het is meer dat Johan De Galas die vroeger voor AcesHardware en Tweakers.net nu voor Anandtech schrijft en zijn studenten betrokken zijn bij dit project.

erg vroeger ook Tom's hardware toch?

Ace's doetie dachtik nog altijd (niet meer dus )
[edit]
bij Ace's is ie idd gestopt... en nu naar Anand.
wel goed voor Anandtech, komen daar ook eens beter artikelen

Het is De Gelas

Het is wel raar om hier je leraar terug te vinden
Prima review van hem & zijn leerlingen

In de conclusie wordt eerst en vooral vermeld dat het benchmarken van databases een gecompliceerde bezigheid is.

Volgens mij is bovenstaande quote het beste deel van het artikel.
Neem de opmerkingen over de invloed van het werkgeheugen en de CPU. Volgens mij is het de vraag welk onderdeel de bottleneck vormt. Wanneer de CPU goed in staat is in een korte tijd het werk geheugen te vullen en weer uit te lezen, zal het werkgeheugen de bottleneck zijn. Wanneer er minder data dan werkgeheugen is of er te weinig CPU kracht is, zal het werkgeheugen geen probleem vormen. Wanneer je dan toch werkgeheugen toevoegt, zal dat inderdaad weinig verschil geven.
Ik heb genoeg databaseservers zien opfleuren nadat er werkgeheugen was toegevoegd.

"Ik heb genoeg databaseservers zien opfleuren nadat er werkgeheugen was toegevoegd"

Klopt volledig, een database server gebruikt het werkgeheugen namelijk vooral voor cachen van data en indexes en het sorteren/bewerken van tijdelijke resultaten. Hoe meer data verwerkt wordt, hoe meer geheugen van invloed is op de prestaties. Dit merk je niet in de meest simple select * from situatie (tenzij je dezelfde query twee keer uitvoerd). Je gaat het pas merken bij veel joins (index uit cache is toch wel veel sneller) of het sorteren/groeperen van grote recordsets.

De efficientie van de client applicatie is natuurlijk ook van belang. Als voor een website de frontpage met alle artikelen grotendeels gecached wordt, hoeft de database server ditzelfde ook niet constant te onthouden en kan dus met minder geheugen uit de voeten.

Alles komt zoals gebruikelijk neer op de architectuur van de applicatie en de omvang van en bewerkingen op de dataset. Een goed ontworpen systeem met grote locaiteit en specialisatie zal met minder sterke hardware uit de voeten kunnen dan een minder doordacht systeem. Maar geheugen kost niets, dus gebruik gewoon 2GB en vergeet die 15K schijven voor de database server, 10K is snel zat voor een goed ontworpen applicatie, en ik denk minder ook nog wel!

* Voor all mijn benchmarks heb ik altijd gebruik gemaakt van de ingebouwde timer in de moderne processoren. Hiermee kun je heel naukeurig (in theorie zelfs op de clock cyclus naukeurig) de prestaties van queries meten.

@Olaf van der Spek:

Tuurlijk, een MKB applicatie zal over het algemeen niet zo gek veel transacties te verwerken krijgen. De actieve dataset is klein genoeg om nagenoeg, zo niet volledig opgevangen te worden door de in-memory cache van de database. Er is een duidelijk verschil tussen deze bedrijven met hun doorsnede applicaties en die van banken bijvoorbeeld die gigantisch veel transacties per minuut moeten verwerken.

De laatst genoemde worden dan ook op troughput geoptimaliseerd, was neerkomt of zoveel mogelijk in een zo kort mogelijk tijdsbestek verwerken en dat vrijwel continu. Hier zal I/O dus snel een bottleneck vormen en dus zijn snelle I/O subsystemen hier heel belangrijk. Voor de doorsnede MKB applicatie is deze situatie dus geheel anders.

Slechts in enkele gevallen en in geval van realtime data koppeling met grotere systeemen kan er een piek I/O belasting ontstaan die tijdelijk merkbaar kan zijn. Dit is echter goed te optimaliseren en de communicatie is daarmee tot een minimum terug te brengen waardoor ook in deze gevallen er geen I/O probleem meer optreed.

Als je bijvoorbeeld 400 medewerkers van een afdeling of bedrijf een intranet applicatie laat gebruiken die voor iedere schermhandeling even de database benaderd of iets wegschrijft, dan heb je echt nog steeds een I/O belasting van 0,0.

en vergeet die 15K schijven voor de database server, 10K is snel zat voor een goed ontworpen applicatie, en ik denk minder ook nog wel!

Dat zou ik niet te hard roepen, tenzij je in een bijna read-only situatie zit.

Tuurlijk, een MKB applicatie zal over het algemeen niet zo gek veel transacties te verwerken krijgen.

Dat is waar. Maar dan is het natuurlijk weer de vraag of je zelfs een dual CPU systeem nodig hebt.
Volgens mij is de goedkoopste Opteron dan net zo bruikbaar.

Op zich niets nieuws, wel leuk dat ze hierover eens een onafhankelijke test hebben gepubliceert. Kleine en middelgrote databases hebben over het algemeen weinig I/O t.o.v. de hoeveelheid geheugen, cache en bandbreedte die zelfs een eenvoudig systeem kan leveren. Wat ook kenmerkend is voor deze systemen is dat er veel logica in stored procedures en functies wordt ondergebracht. Hiermee wordt de CPU load van een client (bijvoorbeel een webserver) verplaatst naar de database server en treed er specialisatie op. De reden waarom hiervoor gekozen wordt is duidelijk, localiteit en dus betere prestaties van het gehele systeem. Als er manipulaties met data gedaan moeten worden, of berekeningen en validaties is dat natuurlijk het snelst als dit dicht bij de data zelf gebeurd, en dat is dus op de database server. Webservers hebben in dit soort doelgerichte applicaties vrijwel geen belasting en kunnen dus heel eenvoudig blijven.

Een ander voordeel van deze aanpak is dat de programma code niet vol komt te staan met data gerelateerde SQL code, welke dan ook nog eens op meerdere plaatsen in vaak net even een ander vorm terug komt. Er komt dus meer struktuur in het systeem en de kwaliteit van de software is beter te bewaken. Helemaal als er meerdere ontwikkelaars aan een systeem werken is dit een belangrijk punt! Bij het maken van een database backup zal dan ook de bijbehorende code die de database voedt en manipuleerd worden bewaard, versie bewaking wordt er dus eenvoudiger door.

Weer een ander voordeel is security. Je kunt de database zo configureren dat geen enkele applicatie zomaar select, insert, update of delete statements op tabellen kan uitvoeren in een database. Dus al wordt de webserver van de applicatie gehackt, dan nog is de data redelijk beschermd, er kan niet willekeurig schade aangericht worden aan de structuur van de data....nog steeds zijn manipulaties alleen mogelijk met de stored procedures, welke je je aan authorisatie onderhevig kan maken. Het hacken van de server alleen haalt dus niets uit, je moet dan ook nog de applicatie gebonden gebruikers authenticatie weten. Voor websites waarbij 'guest' ook toegang hebben is dit natuurlijk niet get geval, daar is alleen de structuur van de database enigsins afgeschermd, niet de data zelf.

Al met all is het heel logish dat deze databases veel CPU power nodig hebben en weinig I/O power. Er is simpel weg niet genoeg data om I/O echt belangrijk te maken, maar wel genoeg code om de CPU flink aan het werk te zetten. Wat wel helpt is niet te zuinig te zijn met geheugen, gewoon 2GB geheugen erin proppen en niet over kosten zeuren...het kost namelijk vrijwel niets. Vier uur langer optimaliseren, of een telefoontje van een klant afhandelen i.v.m. vermeende vretraging van een systeem kost meer!

Of ze in deze test de volledige queries in de client applicatie gestopt hebben is mij niet geheel duidelijk. Het aanroepen van een database functie of procedure is natuurlijk ook een query. Indien ze de volledige 'select x from ...' statements in de applicatie hebben gestopt is dit eigenlijk een beginners fout, maar dat maakt het statement dat de CPU belangrijker is dan het I/O subsysteem alleen maar sterker.

* Zelf heb ik veel ervaring in database optimalisaties voor SQL Server 2000, ik neem aan dat voor andere databases dezelfde vuistregels gelden.

"Servers are all about large caches and fast I/O." This is a generalization that is heard a lot in the IT community and the cliché has been proven, more or less, to be accurate in the high-end server market. But does this common wisdom also apply to the smaller dual processor systems that act as database servers?

We want to focus on operation, which involves little harddisk activity, and focus on the platform: the processor(s) and the interaction with the memory.

Dus eerst afvragen of IO belangrijk is en dan een benchmark kiezen die specifiek minder naar IO kijkt en dan concluderen dat IO niet belangrijk is?



> We also used the MySQL version (3.23.52)

3.23? Dat is wel erg oud (qua features).
En van IBM gebruiken ze dan de nieuwste versie?

"Dus eerst afvragen of IO belangrijk is en dan een benchmark kiezen die specifiek minder naar IO kijkt en dan concluderen dat IO niet belangrijk is?"

Zolang de testen die ze uitvoeren relevant en representatief zijn voor de doelgroep waarvoor ze de test uitvoeren is daar niets mis mee. Ik zie het fenomeen waarnaar ze verwijzen ook maar al te vaak opduiken. Architecturen die ontworpen zijn om optimaal te werken voor hele zware loads die vervolgens als heilig (maatstaaf) worden verklaard en geforceerd worden toegepast om een eenvoudige applicatie te maken die er werkelijk totaal niets aan heeft.

Nu zal je je afvragen wat deze situaties dan zijn....internet sites bijvoorbeeld. Niet iedere site hoeft honderdduizenden request per minuut te verwerken. Maar de 'gospel' architecturen en alles wat daarbij komt kijken (cusussen, interfaces focusen er maar al te graag op en het wordt ook maar wat graag als argument gebruikt om ideen van anderen neer te sabelen onder het motto, maar dat schaal niet tot .... (hoog nummer). De best practices en interfaces die daaruit voortvloeien zijn niet dezelfde die de meesten echt nodig zullen hebben, het compliceert de ontwikkeling van software alleen onnodig.

Kleinere applicaties moeten just meer op latency (gebruikers response), eenvoud en kosten geoptimaliseerd worden dan op thoughput (zoveel mogelijk in korte tijd kunnen verwerken). Geloof mij, de meeste situaties zijn toch echt van de kleinere schaal!

Bij elke wens hoort een eigen computer, de ene combinatie zal voor een constante stroom aan opgevraagde data gunstiger zijn terwijl andere servers eerder incidenteel snel moeten kunnen reageren. Ben blij dat ik geen server heb, lijkt me een hel om die benchmark door te spitten zodadelijk.

Hmm, Zou liever een vergelijk zien van DB-server met windows en oracle.

Vraag me een beetje af wat de compile opties zijn van die MySQL en tevens welke compiler gebruikt is...de ervaring leert namelijk dat op intel hardware behoorlijke performance stijgingen te behalen zijn door intel's eigen compiler te gebruiken....MySQL biedt ze zelfs in binary vorm aan met die compiler gecompiled.....
Indien niet die compiler is gebruikt voor de intel machines is wat mij betreft de test behoorlijk minder waardevol...
Het lijkt me trouwens ook zinvol om het tweaken te laten doen door mensen die specifieke ervaring hebben met een database platform....

Leuk te zien dat ze met open-source testen. Jammer dat ze niet ook een Oracle database hebben meegenomen in de test. Helaas is M$Sql niet op linux beschikbaar dus die kon niet worden meegetest.

Aan de andere kant is het ook wel eens interessant wat de invloed van het OS is op de database. Voor zover ik weet zijn MySql en DB (en Oracle) ook op M$Windows beschikbaar.

Misschien een idee voor de volgende test?

Dan moet je Progress testen. Dat zit veel dichter bij het MKB. Je hebt nauwelijks onderhoud en het is licentie technisch een stuk goedkoper.

Misschien een idee voor de volgende test?

Zou idd leuk zijn, ware het niet dat Oracle expliciet verbiedt in de licentie dat je benchmark-resultaten gaat publiceren. Deels angst dat iemand anders dan zijzelf testen en erachter komen waarom benchmarks van Oracle zelf altijd aantonen dat ze de snelste zijn... En als iemand anders test zijn ze gemiddeld. Een ander deel is natuurlijk de concurrentie. MS zou maar wat graag een valse benchmark doen om aan te tonen dat Oracle veeeeel trager is. En vice-versa...

hé, dat is een leuke en originele grap zeg, consequent M$ typen in plaats van MS...hahaha!

Ja wel leuk zo'n server met PCI-Express.
Kan je ook eens Doom3 en FarCry op hoog niveau spelen.
Of zijn er al 2 Gigabyte netwerkcontrollers voor de PCI-E?

Kan je ook eens Doom3 en FarCry op hoog niveau spelen.

Zitten er x16 sloten op dan?
PCI-E is vooral handig voor RAID controllers.
Maar ook voor (quad port) gigabit of tien gigabit/s kaarten.

Geheugen is vooral fijn voor het in memory houden van veel gebruikte tabellen. Als je meer geheugen hebt, kan je meer queries in geheugen afhandelen, wat dramatisch in de performance scheelt!
Dus als je een DB hebt van 500 MB en 1 GB geheugen, dan zal dat kreng niet sneller worden als je er nog een plakje van 2 GB bij zet.

My 2 Ct.