Hoofdcategorieën
Device Settings

[RSS] [quick] Index » Reviews » Databasetest: Apollo 5 » Overzicht

Databasetest: Apollo 5

Door Wouter Tinus, maandag 13 november 2006 09:21, views: 58.337

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.

Databasetest Apollo 5 - totaal - MySQL 4.1.20

Databasetest Apollo 5 - totaal - MySQL 5.0.20a

Databasetest Apollo 5 - totaal - PostgreSQL 8.2-dev


apollo helemaal naar buiten geschoven
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

T'rug naar huus

Inhoudsopgave

  1. Inleiding
  2. Linux-kernel 2.6.15 vs. 2.6.18
  3. Invloed prefetchers
  4. Woodcrest 2,66GHz vs. 3,0GHz
  1. Vergelijking schaalgedrag
  2. Overzicht
  3. Reacties (30)
Advertentie

Categorieën

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 30 reacties zichtbaar300 Off-topic / Irrelevant: 30 reacties zichtbaar30+1 On-topic: 29 reacties zichtbaar29+2 Informatief: 2 reacties zichtbaar2+3 Spotlight: 0 reacties zichtbaar0

Door Emiel, maandag 13 november 2006 09:36

Score: 1
Mooi verhaal weer. Opvallend hoe pgsql toch een stuk betere performance heeft dan mySQL en ook nog eens veel meer features aan boord heeft.

Overigens, wat is er gebeurd met de mooie onmouseover grafiekjes :)?

Door ShadowLord, maandag 13 november 2006 10:09

Score: 1
Stellen jullie MySQL nu ook zo in om met een concurrency van rond de 7 te werken om zo de maximale performance eruit te persen? (Met instellen bedoel ik dan vooral zorgen dat er gemiddeld maar 7 clients aan hangen dus). Of gedraagd de MySQL server zich in een real-world (lees: GoT) applicatie toch net wat anders?

Door ACM, maandag 13 november 2006 12:17

Score: 1
In de praktijk hebben we sowieso niet zo veel concurrent users, dus het is niet zo dat als er 500 bezoekers per minuut zijn, dat we dan ook 500 tegelijk per minuut op de database hebben zitten.

In de praktijk schommelt het eerder tussen de 10-30 connecties die dan ook nog niet eens allemaal echt aan het werk zijn. Magoed, je wil natuurlijk wel overcapaciteit hebben voor als er weer eens een artikel bij slashdot en andere grote sites gelinked wordt en om toekomstige belastingen ook aan te kunnen.

Bovendien hangt de GoT-load op Apollo 5 veel meer van de I/O af dan voor de belasting van de frontpage. Dus de belasting is ook nog eens anders.

Door CaliMonk, maandag 13 november 2006 10:12

Score: 1
Mooie review.

Waar ik nu vooral benieuwd naar ben, voor welke taken kiezen jullie voor PostgreSQL en wanneer voor MySQL?

Door Wouter Tinus, maandag 13 november 2006 12:23

Score: 1
De hele site draait op MySQL; PostgreSQL wordt alleen voor benchmarks gebruikt. Er zijn voor zo ver ik weet geen concrete plannen om in de productieomgeving (deels) over te stappen naar andere software. Onze aandacht is mede door deze tests wel gewerkt, maar het zou toch een lastig traject met veel potentiële valkuilen zijn, zonder direct merkbare voordelen voor de bezoeker, dus het is maar de vraag of het ooit gaat gebeuren.

Door moto-moi, maandag 13 november 2006 12:28

Score: 1
Dat is niet helemaal waar, we gebruiken voor de pricewatchmanager backend wel postgresql, dan moet je denken aan hippe grafiekjes voor de shops enzo :)

Door Niemand_Anders, maandag 13 november 2006 10:23

Score: 1
Juist omdat de 'snellere' versies van een serie niet aan de verwachtigen kunnen voldoen, gebruiken wij meestal de Xeon 'instap' modellen in een beowulf cluster opstelling. Ofwel meerdere goedkopere servers verbonden met een SAS storage. Een bijkomend voordeel is dat een machine gemakkelijker offline kan worden gehaald voor onderhoud.

Aangezien de 5160 momenteel het paradepaartje is van Intel ben ik eigenlijk wel benieuwd hoe deze zich verhoud tot bijvoorbeeld een 8-core Ultrasparc T1 processor.

Door ACM, maandag 13 november 2006 10:38

Score: 1
Een database leent zich er niet zo heel goed voor om over een beowulf-oplossing verdeeld te worden. Tenzij je natuurlijk met dure grappen als Oracle RAC e.d. gaat lopen stoeien.

Maar voor MySQL en PostgreSQL zit je dan met vrij eenvoudige master-slave modellen, waardoor het niet per se sneller wordt.

Overigens staan de scores van de 8-core T1 ook gewoon in de grafieken hier?

Door NitroX infinity, maandag 13 november 2006 12:07

Score: 1
Leuke vergelijking. Echter, na het lezen van de vergelijking met de Opteron op 2,4GHz vraag ik me af hoe een 2,6GHz of 2,8GHz Opteron het zou doen tegenover deze Xeon krachtpatser.

Door Wouter Tinus, maandag 13 november 2006 12:19

Score: 1
We beseffen dat het vergelijkingsmateriaal aan de AMD-kant wat mager is, maar daar komt in een van de volgende artikelen verandering in ;).

Door Archiebald, maandag 13 november 2006 15:15

Score: 1
hmm, intressante benchmark.

zit zelf in een nogal lastig pakket..
MySQL database van ruim 1,2/1,3 Gbyte (+/-400 mb aan indexen)

draait op een dubbele dual core Opteron 270 met (nu nog) 4 Gbyte geheugen, komt binnenkort 4 Gbyte bij.
en 3 western digital raptors (36 gb) in RAID 5..

maar als de website op zijn piek is, is hij nogal traag... en de load is dan rond de 30 (ja veelste hoog)

maar zoals ik hier net las, is PostgreSQL beter als MySQL bij een zwaar belaste database?

Door Rizz0, maandag 13 november 2006 17:28

Score: 1
Over de verschillen tussen PSQL en MySQL kan ik je niet adviseren, maar mag ik vragen welke website je hebt? Hoogstwaarschijnlijk is de database op een hoop andere manieren te ontzien en dat kan flink schelen in de aanschaf van nieuwe hardware.

Door Wouter Tinus, dinsdag 14 november 2006 01:06

Score: 1
Het is moeilijk om algemene dingen te zeggen over de prestaties van databases. Als je onze benchmarks als richtlijn aan wil nemen moet op zijn minst gelden dat voor jouw database:

1) de meeste queries alleen lezen
2) een groot deel van het werk in een klein deel van de data gebeurt
3) er genoeg geheugen is
4) de server geen andere taken heeft

Wanneer dit niet geldt wordt I/O namelijk erg belangrijk en zouden de verschillen tussen MySQL en PostgreSQL wel eens anders uit kunnen pakken.

Verder moet ik me helemaal achter Rizz0 scharen: door het optimaliseren van queries, het gebruik van caching en/of het verplaatsen van zware taken naar batches die niet realtime maar bijvoorbeeld 's nachts of ieder uur draaien kun je de load waarschijnlijk aanzienlijk terugbrengen zonder nieuwe hardware aan te schaffen. Je database is niet zo groot vergeleken met die van ons, dus tenzij je website echt heel erg populair is zou je met 4GB ram niet aan een load van 30 moeten komen. MySQL heeft een 'slow log' waar trage queries worden getoond, en dat is een goed startpunt om te beginnen met optimaliseren.

Door Archiebald, dinsdag 14 november 2006 10:42

Score: 1
ja, we hebben zelf ook een idee dat het aan de hdd's ligt..
maar kheb 2 boeken over mysql besteld, hopelijk kan ik me wat beter verdiepen hierin.

het gaat trouwens om de site www.hetpaardenspel.nl
op dit moment liggen de servers op de een of andere manier bij sommige uit, bij sommige niet (ssh is wel toegankelijk, maar meer ook niet heb ik et idee)

Door Olaf van der Spek, woensdag 15 november 2006 15:15

Score: 1
en 3 western digital raptors (36 gb) in RAID 5..
Waarom RAID 5 in plaats van RAID 1?
Zelfde vraag overigens alweer/nog steeds aan Tweakers zelf.
Met een database < 2 gbyte lijkt er geen ruimteprobleem.

Door Archiebald, woensdag 15 november 2006 16:33

Score: 1
er paste maar 3 4 hdd's in de server, en we moesten iets, en we dachten dat we meer rekenkracht/geheugen nodig hadden dan goede hdd's... nu blijkt dus dat et wel nodig is...

we zitten nu over te denken om een NAS aan te schaffen, om alles centraal te storagen.. en dan zouden we het in RAID 6 of 10 willen doen, maar daar moeten we eerst naar gaan kijken (ook met oog op de toekomst :P)

en dan na te gaan dat het gewoon een uit de hand gelopen hobby is geworden...alles wordt ook langzamer hand wel professioneler :)

edit: foutje

Door Olaf van der Spek, donderdag 16 november 2006 11:13

Score: 1
er paste maar 3 4 hdd's in de server, en we moesten iets, en we dachten dat we meer rekenkracht/geheugen nodig hadden dan goede hdd's...
Eh, RAID 1 vereist 'maar' 2 HDDs. Dus ik volg je redenatie echt niet.
Met 4 HDDs kun je dus 2 RAID 1 arrays draaien.

Door ..Piet.., donderdag 23 november 2006 14:08

Score: 0
Omdat RAID5 sneller is?

Door curry684, donderdag 16 november 2006 13:55

Score: 1
Nou ik weet niet wat je met dat Paardenspel allemaal voor geks doet, maar ik kan een site met 3 miljoen pageviews per maand moeiteloos draaiende houden op 1 enkele Opteron 165 met 2GB RAM en 4 Raptors in RAID-10. Nog geen load boven de 0.6 gezien in de praktijk.

Pas toen we op Slashdot kwamen (!!!) waren er wat problemen, maar dat was enkel iowaits door te weinig geheugen.

Heb je al enige vorm van caching ingebouwd of zo?

Door Olaf van der Spek, vrijdag 17 november 2006 13:51

Score: 1
maar ik kan een site met 3 miljoen pageviews per maand moeiteloos draaiende houden
Dat is gemiddeld 1 request/seconde. Dat stelt toch niks voor (en is de verkeerde maat voor 'performance')?

Door Archiebald, woensdag 22 november 2006 14:15

Score: 1
zoals Olaf van der spek al zegt... dat is gemiddeld 1 request/seconden...

wij zitten ruim aan de 42 request/seconden...

en dan na te gaan dat er als je een pagina alleen al bekijkt (als je ingelogt bent natuurlijk) al 4 queries moet worden gedraait

Door Archiebald, donderdag 16 november 2006 11:30

Score: 1
we hebben voor RAID 5 gekozen omdat op die server een database draait, en dan moet de server zowel snel kunnen lezen als schrijven op de harde schrijven, bij RAID 5 is dit het snelste (voor wat mogelijk was in de server), RAID 10 (of 01) is nog sneller, maar dit was niet mogelijk in de huidige server

Door Olaf van der Spek, vrijdag 17 november 2006 13:53

Score: 1
Ik geloof er niks van. RAID 5's write performance is een ramp, zeker met kleine DB writes.

Door humbug, vrijdag 17 november 2006 15:19

Score: 1
Zoals altijd hangt performance van een hoop zaken af. Bij Raid 5 is de write operatie inderdaad redelijk ingewikkeld en daardoor traag, maar een goede controller kan een hoop van dat probleem oplossen. Lezen is bij Raid 5 natuurlijk geen probleem en je hebt toch een ruimtevoordeel bij grote databases. Als je dus veel leesopdrachten hebt kan de conclusie dus best wel eens zijn dat de performancewinst van een Raid 01/10 configuratie te beperkt is om zinvol te zijn.

Door markg85, vrijdag 17 november 2006 14:24

Score: 1
Ik heb hier die review en alle reacties met grote interessen gelezen en vraag mij nu een paar dingen af..

Ik weet hoe ik mysql op moet zetten maar om nou te zeggen dat ik er een PRO in ben... het is meer iets als: yum -y install mysql en dan nog een password instellen en klaar voor mij.. maar nu vraag ik me af of er ergens een volledige mysql EN postgresql guide is om een zo efficient mogelijke mysql server op te zetten..??

Verder vraag ik me ook af hoe je die benchmarks maakt en hoe je meerdere mysql servers een site laat serveren (is daar ook een guide van?)

** de guides/howto`s mogen ook in het engels

ennuh.. als ik hier zo naar die tests kijk lijkt postgresql wel gewoon beter te zijn dan mysql.. is dit in de praktijk ook zo?

en: waarom testen jullie wel de laatste postgresql (dev) versie en niet de laatste mysql dev versie (mysql 5.1) is zo natuurlijk een beetje oneerlijke vergelijking.. en anders tenminste de laatste mysql uit de 5.0.x reeks (is 5.0.27 op dit moment)

Door _ep, vrijdag 17 november 2006 22:04

Score: 1
Zoals ook al uit een aantal van bovenstaande reacties blijkt is er geen algemene regel hoe een database het beste werkt. Dit zal vooral afhangen van wat je er mee gaat doen. Vooral lezen of vooral schrijven? Veel verkeer tegelijk of niet? Veel unieke data of juist veel herhalend werk? En ga zo maar door.

Als je een database moet opzetten waarvoor de performance 'echt' belangrijk is, dan is het aan te raden genoeg informatie te vergaren over de manier waarop databases werken en wellicht zelf te gaan experimenteren/benchmarken.

Een aardig startpunt voor informatie over mysql en hoe je kan clusteren is natuurlijk de website van mysql zelf!

Door moto-moi, zondag 19 november 2006 15:13

Score: 2
5.0.11 is de laatste betaversie van de 5.1 range, en die crashed onwijs hard bij het draaien van het eerste deel van onze benchmark. Dus deze versie is nog niet echt klaar voor productie, vandaar dat we hem deze keer ook gewoon niet hebben gedraaid.
Verder ligt de postgresql beta versie die we hebben getest vrij dicht bij de definitieve 8.2 versie. Verder zou je kunnen denken dat er misschien nog extra performancetuning in de final van 8.2 zouden kunnen zitten hebben we dus besloten voorlopig het op deze beta te houden zodat je de oude tests ook 1-op-1 kunt vergelijken met deze test.

Door markg85, maandag 20 november 2006 00:58

Score: 1
ik neem aan dat je 5.1.11 bedoelt :)
en ook dat is niet de laatste versie in de 5.1 beta kak.. de laatste is: 5.1.12 beta

al zeggen ze bij de changelog van 5.1.12 wel dit:
Due to a build slippage, binary distributions of MySQL 5.1.12 contain neither NDB Cluster nor Partitioning. We apologize for any inconvenience. Please upgrade to 5.1.13 as soon as it is available. if you build from source, you can execute configure with the --with-ndbcluster and --with-partition options.
dus dat gaat al erg lekker met de 5.1 tak :P

Door thl, donderdag 30 november 2006 19:18

Score: 1
Grappig, dit review heeft het PostgreSQL-nieuws gehaald:

http://www.postgresql.org/about/news.691

Op dit item kan niet meer gereageerd worden.

VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011