[MySQL64] 2Dualcore Opteron270 presteren beneden verwachting

[MaxxMark]

Wij hebben recent besloten over te gaan stappen (vanwege de goede verhalen. zie oa: http://www.anandtech.com/IT/showdoc.aspx?i=2447&p=1 ) op een Dual DualCore Opteron (64bit) systeem voor onze database activiteiten.

Dit wilde we slim aan gaan pakken en hebben besloten te gaan kijken wat de feitenlijke voordelen zijn van het systeem. Hiervoor hebben we besloten een aantal benchmarks te draaien zodat we duidelijk inzicht hadden in hoe groot snelheids winsten wel of niet zijn.

Aangezien we alleen met MySQL draaien hebben we besloten om alleen gebruik te maken van de MySQL benchmarks, SQLBench welke standaard bij een mysql distributie zit, en daar onze resultaten op te baseren.
Het OS is de 64bit variant met SMP kernel. En een mysql 64bit versie


In de basis:
1 Tyan K8S PRO
op dit moment:
1 SATA Disk (120Gb)
wordt uitgebreid naar 2x u320 scsi 15krpm in raid-0 met op een LSI raid controler met 1gb onboard cache


Met de volgende specifieke configuratie verschillen


1x Opteron 270 (DualCore 2.2Ghz 64bit)
2x 1GB Apacer 3200Mhz

2x Opteron 270 (DualCore 2.2Ghz 64bit)
4x 1Gb Apacer 3200Mhz (2gb per cpu)


Dit alles is vergeleken met onze huidige snelste 32bit (dedicated) MySQL Database:

2x Xeon (HT 2.4Ghz 32bit)
2x 73Gb U320SCSI (stripe-set)
4x 1Gb 3200Mhz


De volgende resultaten zijn benchmark total results:


XEON2-DEBIAN32 3237,00 (100,00%)
OPT2-FBSD64 10427,00 ( 31,04%)
OPT2-DEBIAN64 812,00 (398,65%)
OPT2-SOLARIS 8505,97 ( 38,06%)

Hierin is de XEON het referentie systeem

Later is besloten om de 2e cpu en de extra 2gb geheugen te bestellen en daarna weer te benchmarken.


Na het binnenkomen van de extra cpu en het extra geheugen zijn we nog een keer gaan testen en uit gegaan van het Debian OS omdat die verreweg de beste prestaties tot dan toe leverden.

Tot onze verbasing leverde dit het volgende resultaat:

OPT4-DEBIAN64 1399,00 (231.38%)


Dit betekende dus een achteruitgang in prestatie. Specifieker gekeken (op de verschillende onderdelen van de mysql benchmark) bleken er wel verschillen te zitten tussen de single dualCore en de dual dualCore, maar op het geheel gezien is het dus een achteruitgang.

Om configuratie verschillen te voorkomen hebben we toen besloten om nogmaals te testen met 1 CPU en te tweaken tot we het volgende resultaat kregen (tweaken, 2x runnen van de benchmark om caching te excluden/middelen) :

OPT2-DEBIAN64 695.00 (465,76%)

Hierna hebben we zowel de CPU als het extra geheugen er in gedaan en kwamen we op het volgende resultaat:

OPT4-DEBIAN64 739.00 (438,02%)

Hoe dit komt is ons tot nu toe een raadsel.

Mogelijkheden waar van wij denken dat het eventueel mogelijk zou kunnen zijn:

1. configuratie fout
2. Compileer fout (mysql)
3. compileer fout (kernel)
4. threading problemen
5. mysql is niet schaalbaar (1cpu ->2cpu groot verschil. 2cpu->3 of 4cpu's minder groot verschil)
6. Er werd geopperd dat het zou kunnen komen door de hevige context switching van de cpu's waardoor de snelheids winst teniet gedaan werd. Zelf leek mij dit niet echt logisch. Je gooit er 2x 2.2Ghz extra tegenaan en het maakt geen verschil, of zelfs achteruitgang.
7. MySQL benchmark support geen multi threading
8. Mysql benchmark is geen goede representatie van een real-life environment.


We hebben de my.cnf in verschillende configuraties gehad (varierend van default tot custom made) en deze hadden weinig tot geen extra positief effect

Als laatste proberen wij de volgende configuratie nog welke gebruikt zijn door anandtech in hun mysql tests. Heleaas is de benchmark methode die zij gebruiken een in-house benchmark methode welke wij niet kunnen gebruiken en is een directe vergelijking met hun helaas niet mogelijk.

code:

           Read_buffer=2GB
           Port=3306
           socket = /var/lib/mysql/mysql.sock
           skip-locking
           set-variable = max_user_connections= 2000
           set-variable = max_connections= 2000
           key_buffer=2G
           Read_buffer=2G
           table_cache=1024
           tmp_table=128M
           max_heap_table=256M
           read_rnd_buffer = 64M
           thread_cache=16
           net_buffer_length=16k

Bij anandtech daarentegen komt duidelijk naarvoren dat van dual naar quad opteron weldegelijk een voordeel op moet leveren. Iets wat bij ons totaal niet naar voren komt.

(PS. de Anandtech settings van hierboven geven een resultaat van ~1500 seconden, niet echt lekker dus)

Mocht iemand nog ideeën / suggesties hebben dan hou ik mij van harte aanbevolen.

Voor meer informatie over de resultaten van de benchmarks zie:

http://incursion.gamepoint.net/BenchMarkResult.xls

[ Voor 6% gewijzigd door MaxxMark op 16-02-2006 12:57 ]

[squaddie]

Zou het probleem van de performance niet aan de harde schijf kunnen liggen? De Xeon-bak heeft immers 2x 73Gb U320SCSI (stripe-set) en de Opteron-bak een single sata schijfje. Ik heb niet zo heel veel gespeeld met de bijgeleverde benchmark, dus ik weet niet of de data van schijf wordt gelezen en die de bottleneck vormt en de Opterons spreekwoordelijk uit hun neus eten tijdens de benchmark.

Ik weet niet of het mogelijk is om die twee SCSI-schijven om te hangen naar Opteron-bak, dan worden de CPUs onder dezelfde omstandigheden getest en heb je een goede vergelijking.

PS met 2 dualcore processoren en 4 GB geheugen moet je een aardige RAID-set hebben om dat van voldoende data te voorzien.

[ Voor 13% gewijzigd door squaddie op 03-02-2006 14:30 ]

[MaxxMark]

squaddie schreef op vrijdag 03 februari 2006 @ 14:29:
Zou het probleem van de performance niet aan de harde schijf kunnen liggen? De Xeon-bak heeft immers 2x 73Gb U320SCSI (stripe-set) en de Opteron-bak een single sata schijfje. Ik heb niet zo heel veel gespeeld met de bijgeleverde benchmark, dus ik weet niet of de data van schijf wordt gelezen en die de bottleneck vormt en de Opterons spreekwoordelijk uit hun neus eten tijdens de benchmark.

Ik weet niet of het mogelijk is om die twee SCSI-schijven om te hangen naar Opteron-bak, dan worden de CPUs onder dezelfde omstandigheden getest en heb je een goede vergelijking.

PS met 2 dualcore processoren en 4 GB geheugen moet je een aardige RAID-set hebben om dat van voldoende data te voorzien.

Ik geef toe, de disks KUNNEN een invloed hebben. Dit zou bijvoorbeeld een reden kunnen zijn dat FreeBSD zo slecht presteert. Als je in de XLS kijkt zie je dat bij de FreeBSD results het vooral de disk intensieve dingen zijn die slecht presteren.

Debian gaat blijkbaar veel beter om met 'trage' disks dan FreeBSD.

Alleen is het zo dat als het de disks zijn die de problemen geven, dan hadden we dit al veel eerder moeten zien bij de vergelijking onderlingen onderling. Verder is het natuurlijk gewoon zo dat het nergens op slaat dat een extra cpu voor een achteruitgang zorgt. Als het de disks waren dan zou de performance minimaal gelijk moeten blijven.

Verder is het volgens mij zo dat SQLBench inderdaad wel insert, maar veel gewoon in memory houd. En dan zou het effect daarvan geen invloed moeten hebben op non-disk related queries.

[jochemd]

MaxxMark schreef op vrijdag 03 februari 2006 @ 13:59:
Aangezien we alleen met MySQL draaien hebben we besloten om alleen gebruik te maken van de MySQL benchmarks, SQLBench welke standaard bij een mysql distributie zit, en daar onze resultaten op te baseren.

(..)

7. MySQL benchmark support multi threading

Heb je de handleiding wel gelezen?

quote: http://dev.mysql.com/doc/refman/5.0/en/mysql-benchmarks.html

7.1.4. The MySQL Benchmark Suite

This benchmark suite is meant to tell any user what operations a given SQL implementation performs well or poorly. You can get a good idea for how the benchmarks work by looking at the code and results in the sql-bench directory in any MySQL source distribution.

Note that this benchmark is single-threaded, so it measures the minimum time for the operations performed. We plan to add multi-threaded tests to the benchmark suite in the future.

Ga gewoon eens met je eigen applicatie testen in plaats met een benchmark die iets heel anders meet dan je wil weten.

[MaxxMark]

jochemd schreef op vrijdag 03 februari 2006 @ 19:50:
[...]

Heb je de handleiding wel gelezen?

Persoonlijk heb ik dat zelf niet gedaan, maar de sysop die er mee bezig is hoop ik wel

[...]

Ga gewoon eens met je eigen applicatie testen in plaats met een benchmark die iets heel anders meet dan je wil weten.

Onze eigen applicatie betekent dat we in een real-world omgeving moeten werken met een paar duizend concurrent spelers, over een flink aantal gameservers. Helaas valt dat niet binnen een van de mogelijkheden. Als dat wel simpel het geval was hadden we dat natuurlijk gedaan.

Het systeem 'even' in de live omgeving hangen is ook geen optie aangezien dat betekent dat we naar de colo moeten gaan en het 'experimentele' systeem in een live omgeving moeten hangen.

Enige wat nog rest is, een al eerder gebruikt stresstest idee, om aantal sample's te pakken van verschillende tijdsmomenten op de live omgeving en deze voeren aan het nieuwe systeem. Alleen betrof dat indertijd een weinig gemiddelde test-sample. Een goede test zou zijn om een volledige dag aan queries aan het systeem te voeren en te controleren in hoeveel tijd hij die kan verwerken. Helaas is dit alleen niet te leggen tegen het referentie systeem.

Trouwens, als je kritiek levert of een op/aanmerking heb mag je dat ook wel wat positiever en constructiever brengen. Zoals in mijn post al stond bij optie 7 trok ik al in twijfel of sqlbench wel support bood voor multithreading.

Na inderdaad de doc's er even bijgepakt te hebben zie ik dat sqlbench geen ondersteuning bied voor multithreaded design.

Verder vind ik je opmerking ...in plaats met een benchmark die iets heel anders meet dan je wil weten. nogal een uitstraling hebben van 'verziek mijn tijd eens niet en nu wegwezen'.

Als ik de docs goed interpreteer staat er dat de tool een verscheidenheid aan mysql zaken aan de tand voelt. Ofwel het doet PRECIES wat wij willen, namelijk inzicht geven in hoe goed het systeem op verschillende gebieden presteert.
Verder staat er ook dat ze plannen om een multithreaded versie in de toekomst uit willen brengen.

Uiteraard moet ik toegeven dat het best wel enigszins misschien een beetje heel erg stom is geweest dat we zoiets triviaals niet gezien hebben. Hoewel mij niet alle blaam treft is het uiteindelijk wel mijn verantwoordelijkheid.

[jochemd]

Onze eigen applicatie betekent dat we in een real-world omgeving moeten werken met een paar duizend concurrent spelers, over een flink aantal gameservers. Helaas valt dat niet binnen een van de mogelijkheden. Als dat wel simpel het geval was hadden we dat natuurlijk gedaan.

Nothing worthwhile is easy.


Ga rustig de rest van de handleiding lezen. Verzamelen daarna traces van queries van je live systemen, restore een backup van je live systeem naar je nieuwe server en ga vervolgens die traces met flink wat concurrent threads terugspelen. Zorg dat je server al minstens een half uur draait zodat de cache gevuld is en je logfiles ook een enigszins realistische grootte hebben en start dan je stopwatch eens.

[MaxxMark]

Handleidingen lezen is meestal mijn eerste keus....

Heb zelf al aardig wat tweakings er op zitten mysql wise.. Het jammere is alleen dat de mysql docs zichzelf danig tegen spreken dat er op een zeker punt geen duidelijkheid meer in te krijgen is..

En waarschijnlijk ben ik daar niet de enige in, want anders zou er wel een 'mysql calculator' in omloop zijn welke een X aantal factoren in beschouwing zou nemen.

Anyhow, dat doet eigenlijk niet ter zaken.. Volgende mogelijkheid gaan er een paar (alternatieve) methodes tegenaan.. Zelf heb ik ook zoiets van 'wtf' mbt het singlethreaded zijn van de sql benchmark... Denk dat ik daar nog eens op terug moet komen..

Gewoon bij wijze van bevestiging ga ik dit topic nog even bij houden..

[Verwijderd]

Onze eigen applicatie betekent dat we in een real-world omgeving moeten werken met een paar duizend concurrent spelers, over een flink aantal gameservers. Helaas valt dat niet binnen een van de mogelijkheden. Als dat wel simpel het geval was hadden we dat natuurlijk gedaan.

Dit is natuurlijk onzin

Simulatie is dan wel een vak apart, maar het simuleren van enkelen duizenden spelers op een (game)server is niet echt moeilijk. Het moeilijkste is om de verhouding tussen de verschillende acties realistisch te houden, niet om de server te belasten. Daarvoor kun je simpel traces replayen.

Daarnaast is de harddisk natuurlijk een duidelijk punt van aandacht. Het is niet voor niets dat vele database servers als raid 0(of 10) geconfigureerd worden. Je 4 cores kunnen je trage sata schijfje redelijk dichttrekken.

Tot slot misbruik je een test voor iets waar die niet voor bedoeld is en snap je de resultaten van die test niet. Jammer maar helaas. Doe gewoon een goede test en kijk dan of de resultaten logisch zijn. Ik denk dat je dan veel minder reden tot klagen hebt en je keuze voor Debian ipv Solaris of BSD misschien zelfs fout blijkt te zijn. (Debian een factor 10 sneller dan BSD? Hoe geloofwaardig is dat?)

[MaxxMark]

Verwijderd schreef op zaterdag 04 februari 2006 @ 01:28:
[...]

Dit is natuurlijk onzin


Simulatie is dan wel een vak apart, maar het simuleren van enkelen duizenden spelers op een (game)server is niet echt moeilijk. Het moeilijkste is om de verhouding tussen de verschillende acties realistisch te houden, niet om de server te belasten. Daarvoor kun je simpel traces replayen.

Niet om je opmerking te ontkrachten, maar ik denk niet onzin het juiste woord is. Zoals in veel situaties het geval is is juist tijd het punt van probleem. Het chronisch tekort aan tijd is er de oorzaak van dat een test applicatie (op dit moment!) opzetten/uitdenken niet tot de mogelijkheden hoort. Wat we natuurlijk wel gaan doen is (zoals ik al eerder opperde) de db belasten met real-life data.

Daarnaast is de harddisk natuurlijk een duidelijk punt van aandacht. Het is niet voor niets dat vele database servers als raid 0(of 10) geconfigureerd worden. Je 4 cores kunnen je trage sata schijfje redelijk dichttrekken.

Helemaal mee eens natuurlijk! Het is ook de bedoeling dat het systeem in de toekomst gaat werken met 2 15k scsi disks in een raid 0 configuratie. De reden dat er niet gekozen wordt voor een raid 1+0 of raid 5 configuratie is omdat de (slave) databases redundant zijn uitgevoerd. Op dit moment kan een slave gewoon uitgezet worden zonder dat het platform hier last van heeft. Dit is natuurlijk niet zo als de master er besluit mee te kappen

Tot slot misbruik je een test voor iets waar die niet voor bedoeld is en snap je de resultaten van die test niet. Jammer maar helaas. Doe gewoon een goede test en kijk dan of de resultaten logisch zijn. Ik denk dat je dan veel minder reden tot klagen hebt en je keuze voor Debian ipv Solaris of BSD misschien zelfs fout blijkt te zijn. (Debian een factor 10 sneller dan BSD? Hoe geloofwaardig is dat?)

Dat er te veel waarde gehangen was van mijn kant aan het simpele woord 'SQLBench' is duidelijk. Volgende keer eens wat beter op letten.

Dat Debian 10x beter presteert dan BSD (of een andere OS) is natuurlijk raar, en ook hier kan ik zeggen dat we ook op dat vlak tests dus opnieuw moeten doen.

Concluderend is het dus meer onduidelijkheid/onwetendheid/stomheid die het probleem veroorzaakte. En ook hier is ook weer van toepassing 'aldoende leert men'

[Rolfie]

Het is al eerder genoemd, maar ik zou zeker eens kijken naar je schijven. een U320 72Gb schijfje is beter instaat veel te verwerken dan een single SATA schijfje. De performance van SCSI is nu eenmaal beter als die van SATA, zeker onder een hoge workload.

[MaxxMark]

Rolfie schreef op zaterdag 04 februari 2006 @ 12:00:
Het is al eerder genoemd, maar ik zou zeker eens kijken naar je schijven. een U320 72Gb schijfje is beter instaat veel te verwerken dan een single SATA schijfje. De performance van SCSI is nu eenmaal beter als die van SATA, zeker onder een hoge workload.

Helemaal mee eens, u320 15k rpm scsi disks zijn inderdaat beter dan sata.

Ook ik zei al; er gaan in de toekomst scsi disks in. Het systeem is uitgerust met een scsi backplane. Enige wat er nu nog in moet is de raid controler en de disks.

[Abom]

Denk eraan dat je schijven met zo´n configuratie je bottleneck zullen zijn, je schijven zijn te mager ingericht voor de rest van het systeem. Ik weet niet hoe het specifiek uitziet met mysql, maar ik ga er vanuit dat je ook veel performance kunt halen bij het goed inrichten van je schijven. Zorg ervoor dat je transactie logs apart opgeslagen worden van je database files.

Zoals je weet hebben wij ook een nieuwe db-server (dual opteron 275 met 4gb), wel met MS SQL dan, maar op dit moment zijn de schijven de bottleneck in de meeste situaties. De schijven zijn alsvolgt ingericht: raid10 array voor het OS/swap files, raid5 voor database files en een raid10 array voor de transactielogs, totaal van 12 schijven. De performance van het systeem is zelfs iets beter dan wij verwacht hadden.

[Femme]

Wij zijn ook bezig om wat tests uit te voeren op dual Xeon en dual Opteron servers met een simulatie van de Tweakers.net-databaseomgeving. De dual-core Opteron presteert in onze tests wel naar verwachting.

We hebben een scriptje gemaakt waarin de meest voorkomende queries op Tweakers.net wordt uitgevoerd. De queries worden in willekeurige volgorde uitgevoerd (als ze niet van elkaar afhankelijk zijn) en worden willekeurige id's van records opgevraagd binnen een realistisch bereik. Dit scriptje wordt met behulp van ApacheBench bij een bepaalde concucurrency aangeroepen. We hebben tijdens het testen van de dual-core Opteron gemerkt dan één client (P4 2,8GHz) niet voldoende is om de maximale prestaties aan de database-server te onttrekken. Met twee clients presteert hij al iets beter (MC / multi-client resultaten in onderstaande grafieken).

Alle systemen waren voorzien van 4GB geheugen en een Areca ARC-1120 128MB of ARC-1130 256MB met acht WD Raptor WD740GD's harde schijven waarvan vijf in RAID 5 voor data. CPU iowait is gemiddeld minder dan een halve procent dus disk I/O heeft een zeer kleine invloed op de resultaten.

Hier zijn onze voorlopige resultaten in MySQL 5.0:



De dual Opteron 275 presteert bij een concurrency van 1 en 2 niet beter dan de dual Opteron 254. Dat is logisch, aangezien de vier cores dan niet optimaal gebruikt kunnen worden. Als je je Opteron 270 goed wilt testen zul je dus moeten testen met een (realistische) hoge concurrency. Ook is zaak om een realistische benchmark te gebruiken, dus probeer eens zoiets in elkaar te knutselen wat wij ook gedaan hebben dmv een PHP-scriptje met queries en ApacheBench om requests te genereren.

De test van AnandTech is op hetzelfde principe gebaseerd. Ik heb ooit iets in elkaar geknutseld voor Johan de Gelas toen hij nog voor Ace's Hardware werkte. Dat lijkt hij nu ook te gebruiken voor AnandTech.

Een read_buffer van 2GB is overigens bizar groot en volstrekt nutteloos. De read_buffer wordt gebruikt om data van een connectie in te lezen en wordt per connectie gereserveerd. Een read_buffer van een paar MB is meer dan voldoende.

[ Voor 27% gewijzigd door Femme op 06-02-2006 17:22 ]

[_-= Erikje =-_]

wat geeft zo'n raid 5 array op die areca nou ongeveer voor troughput? Ik ben hier nog aan het kijken voor een mailstore server namelijk

[Kippenijzer]

Ik zat zodra dit topic begon eigenlijk al te wachten/hopen dat er nog een reactie van Femme zou komen, want die heeft meestal wel kijk op dit soort zaken, en zie daar .
Vraag ik me op die resultaten wel af of er "duidelijk" is wat de enorme dip bij hoge concurrency op de Dual Dual-Core Xeon met HT veroorzaakt, of dat dit bijvoorbeeld een fout in de data / meetfout kan zijn?

[CyBeR]

Femme schreef op maandag 06 februari 2006 @ 17:07:
We hebben een scriptje gemaakt waarin de meest voorkomende queries op Tweakers.net wordt uitgevoerd.

Zou je bereid zijn dit scriptje met ons te delen zodat wij er een voorbeeld aan kunnen nemen?

[Femme]

_-= Erikje =-_ schreef op maandag 06 februari 2006 @ 22:53:
wat geeft zo'n raid 5 array op die areca nou ongeveer voor troughput? Ik ben hier nog aan het kijken voor een mailstore server namelijk

Zie deze review: reviews: Mega roundup van Serial ATA RAID 5-adapters

De kaarten van Areca zijn het beste wat je op dit moment op SATA-gebied kunt krijgen. In combinatie met WD Raptors doen ze qua performance zeker niet onder voor een 10K SCSI-configuratie, al helemaal niet als die SCSI-config het met een oudere RAID-adapter moet doen.

Kippenijzer schreef op maandag 06 februari 2006 @ 23:29:
Ik zat zodra dit topic begon eigenlijk al te wachten/hopen dat er nog een reactie van Femme zou komen, want die heeft meestal wel kijk op dit soort zaken, en zie daar .
Vraag ik me op die resultaten wel af of er "duidelijk" is wat de enorme dip bij hoge concurrency op de Dual Dual-Core Xeon met HT veroorzaakt, of dat dit bijvoorbeeld een fout in de data / meetfout kan zijn?

De oorzaak van die dip is ons ook niet helemaal duidelijk.

CyBeR schreef op maandag 06 februari 2006 @ 23:56:
[...]

Zou je bereid zijn dit scriptje met ons te delen zodat wij er een voorbeeld aan kunnen nemen?

Ik kan binnenkort wel wat voorbeeldcode posten.

[Verwijderd]

http://techreport.com/rev.../opteron-x75/index.x?pg=1

[Abom]

Verwijderd schreef op dinsdag 07 februari 2006 @ 01:54:
http://techreport.com/rev.../opteron-x75/index.x?pg=1

En bedankt.

[Verwijderd]

Verwijderd schreef op dinsdag 07 februari 2006 @ 01:54:
http://techreport.com/rev.../opteron-x75/index.x?pg=1

Briljant. Had je daaraan gedacht Maxxmark, het bekijken van benchmarks?

[MaxxMark]

Verwijderd schreef op donderdag 09 februari 2006 @ 20:37:
[...]


Briljant. Had je daaraan gedacht Maxxmark, het bekijken van benchmarks?

Ik moet hem inderdaad bedanken voor de zeer nuttige bijdrage aan de discussie inderdaad

Sinds wanneer geven benchmarks gedaan door anderen inzicht in hoe een machine, die uit andere componenten bestaat, presteert?

Plus dat het er op lijkt dat je mijn openingspost niet eens goed gelezen hebt. Daar staat namelijk duidelijk een verwijzing naar de opteron tests van Anandtech.

[ Voor 23% gewijzigd door MaxxMark op 12-02-2006 16:35 ]

[Infern0]

Wat betreft de benchmarks die je uitgevoerd hebt met FreeBSD kan ik je vertellen dat je deze resultaten een heel stuk kan opkrikken.

Voor FreeBSD wordt sowieso gesteld dat je gewoon i386 moet gebruiken en niet amd64 wanneer je geheugen niet meer is dan 4 Gb, aangezien je minder context switching hebt.

Daarnaast is het raadzaam om een andere timecounter te nemen welke minder cpu verbruik vereist
http://wikitest.freebsd.org/moin.cgi/MySQL

Ook het gebruik van een andere threading library krikt de boel enorm op plus het gebruik van de ULE scheduler ipv de "oude" 4BSD scheduler

Als laatste heeft het te maken met async file systeem wat FreeBSD gebruikt (hier weet ik niet het fijne van).

Met deze wijzigingen haal ik bijna dezelfde preformance op FreeBSD als met Debian en Archlinux. Mijn tests zijn uitgevoerd met http://jeremy.zawodny.com/mysql/super-smack/