4x SSD vs. 8x HDD

[TheNephilim]

Beste Tweakers,

Na het lezen van een aantal reviews, tests en benchmarks (van onderandere Femme) zou je verwachten dat 4 SSD's in RAID 10 sneller zijn dan 8 HDD's in RAID 10, maar dit lijkt er niet op. Ik zou graag jullie mening horen over het volgende probleem.

Oude situatie:
Adaptec RAID kaart, 256MB cache
8x Fujitsu 15K SAS 74GB in RAID 10

Nieuw situatie:
Areca 1222 RAID kaart, 256 cache
4x Mtron MSP-SATA7535 16GB in RAID 10

Omstandigheden:
MySQL server; verscheept 2-4GB per uur; 600-800 queries per seconde; 50% SELECT, overige is INSERT en vooral UPDATE.

Overige server stats:
2x Intel Xeon X5355
12GB DDR2 intern geheugen

We hadden gedacht een behoorlijke performance boost te krijgen ook al halveren we het aantal schijven. Helaas pakt het anders uit dan gedacht en is de MySQL server zelfs iets slomer geworden.
De database die erop draait is niet van het beste hout gesneden en ongeveer 6-7GB groot. De server trekt dan ook het geheugen bijna vol (ruim 8GB in gebruik) waardoor je zou denken dat het allemaal mooi vlotjes zou gaan.
Het optimaliseren van de database is overigens niet aan de orde, de applicatie die erop draait is er te groot, log en te slecht gescript voor.

Als er iemand is die kan verklaren waar de bottleneck zit, dan hoor ik dat graag.

Alvast bedankt!

[Verwijderd]

Allereerst: erg nette openingspost ! Hier kunnen we tenminste wat mee Even nog een vraag:
- wat heb je voor blocksize ingesteld op je raid array
- Heb je een nieuwe installatie uitgevoerd toen je ging migreren naar de nieuwe array

^{kleine opmerking: een server met 12GB DD2 geheugen ken ik niet, bedoel je niet toevallig 12GB DDR2 geheugen ?}

[phobosdeimos]

SSD's zijn nog niet echt goed in schrijfoperaties, dus je INSERT en UPDATES zullen in snelheid zijn afgenomen. Plus je zou betere overschakelen naar PostgreSQL ;-)

[TheNephilim]

Verwijderd schreef op donderdag 04 september 2008 @ 20:51:
Allereerst: erg nette openingspost ! Hier kunnen we tenminste wat mee Even nog een vraag:
- wat heb je voor blocksize ingesteld op je raid array
- Heb je een nieuwe installatie uitgevoerd toen je ging migreren naar de nieuwe array

^{kleine opmerking: een server met 12GB DD2 geheugen ken ik niet, bedoel je niet toevallig 12GB DDR2 geheugen ?}

Bedankt voor je reactie!

Ik bedoelde inderdaad DDR2

- De blocksize weet ik zo eerlijk gezegd niet (heb installatie niet zelf uitgevoerd), maar dat is inderdaad wel belangrijk natuurlijk. Dat ga ik even na bij mijn collega's. Deze moet vrij klein zijn als ik het goed heb met een DB server.
- De server is volledig opnieuw geïnstalleerd (CentOS), hierna MySQL 5.0.45-log. Database is geïmporteerd en vervolgens alles weer online en werkend gezet.
De database bestaat uit ~200 tabellen waarvan de meeste MYISAM en een enkele INNODB. We hebben eigenlijk 2 hoofdtabellen, hier word ontzettend veel op gelezen en geschreven. De 1 is INNODB en de andere MYISAM, beide op INNODB leverde behoorlijk hoge CPU-load op (ook na het finetunen van de my.cnf)

[ Voor 3% gewijzigd door TheNephilim op 04-09-2008 21:01 ]

[maratropa]

Staat write back cache aan van de areca kaart? En dan heeft het ook zin om die cache te updaten naar 2Gb, of kan dat niet bij de 1222?

[ Voor 74% gewijzigd door maratropa op 05-09-2008 10:50 ]

[voodooless]

Doe eens wat benchmarks met bijvoorbeeld iometer? Interessant om te zien dat het tegenvalt. Wij hebben kort geleden ook de keuze moeten maken tussen SSD en SAS, en zijn toch voor het laatste gegaan, maar ook dat viel tegen vanwege een brakke controller. Het is nu wachten op een nieuwe

phobosdeimos schreef op donderdag 04 september 2008 @ 20:58:
SSD's zijn nog niet echt goed in schrijfoperaties, dus je INSERT en UPDATES zullen in snelheid zijn afgenomen.

Volgens diverse benchmarks zouden deze SSD's prima overweg moeten kunnen met random schrijfacties, stukken beter dan de gebruikte SAS schijfjes.

[ Voor 39% gewijzigd door voodooless op 05-09-2008 08:44 ]

[Femme]

phobosdeimos schreef op donderdag 04 september 2008 @ 20:58:
SSD's zijn nog niet echt goed in schrijfoperaties, dus je INSERT en UPDATES zullen in snelheid zijn afgenomen. Plus je zou betere overschakelen naar PostgreSQL ;-)

Er zit een dikke cache tussen van de raidcontroller. Je zult erg veel continue schrijfacties moeten doen om de ssd's de bottleneck te laten zijn.

Een verhouding 50/50 tussen selects en queries die wijzigingen in de database aanbrengen is wel vrij veel. Ik heb in mijn eigen benchmarks echter geen problemen hiermee ondervonden met de Mtron-ssd's op een Areca-controller. De prestaties waren in het slechts geval ongeveer gelijk aan die van een harde schijf.

Aangezien je database vrij klein is en de selects goed gecached kunnen worden terwijl er wel erg veel geschreven wordt terwijl het aantal disks is afgenomen kan ik me voorstellen dat dit geen ideale omstandigheid is voor ssd's.

[BCC]

Even out of the box: Je zegt dat je de database niet wil / kan optimaliseren, maar je hebt dan neem ik aan wel naar indexen gekeken / slow query logs? Je kan er nog zoveel hardware tegenaan gooien, maar full table scans worden er nauwelijks sneller van .

Hier gaan je inserts en updates natuurlijk niet sneller van worden, maar voor je selects kan het heel veel schelen.

[ Voor 18% gewijzigd door BCC op 05-09-2008 11:04 ]

[Noork]

Is het gebruik van de innoDB tabel noodzakelijk? Heb je voldoende geheugen aan inno toegewezen?

[TheNephilim]

Staat write back cache aan van de areca kaart? En dan heeft het ook zin om die cache te updaten naar 2Gb, of kan dat niet bij de 1222?

Voor zover bekend bij mij is het geheugen op de kaart onboard, dit kan niet uigebreid worden. De writeback cache hoort zeker aan te staan, maar dit weet ik niet zeker dus ga ik het even na bij mijn collega's. Ik kom hier zo snel mogelijk op terug.

-----

Doe eens wat benchmarks met bijvoorbeeld iometer? Interessant om te zien dat het tegenvalt. Wij hebben kort geleden ook de keuze moeten maken tussen SSD en SAS, en zijn toch voor het laatste gegaan, maar ook dat viel tegen vanwege een brakke controller. Het is nu wachten op een nieuwe
quote:
phobosdeimos schreef op donderdag 04 september 2008 @ 20:58:
SSD's zijn nog niet echt goed in schrijfoperaties, dus je INSERT en UPDATES zullen in snelheid zijn afgenomen.
Volgens diverse benchmarks zouden deze SSD's prima overweg moeten kunnen met random schrijfacties, stukken beter dan de gebruikte SAS schijfjes.

IOmeter? Ok, ik ga even kijken of we dat misschien vannacht of op een ander tijdstip uit kunnen voeren.
Ja wij waren ook in de veronderstelling dat deze SSD's goed waren in writes in tegenstelling tot een boel andere soorten SSD's. Tis jammer.

------

Er zit een dikke cache tussen van de raidcontroller. Je zult erg veel continue schrijfacties moeten doen om de ssd's de bottleneck te laten zijn.

Een verhouding 50/50 tussen selects en queries die wijzigingen in de database aanbrengen is wel vrij veel. Ik heb in mijn eigen benchmarks echter geen problemen hiermee ondervonden met de Mtron-ssd's op een Areca-controller. De prestaties waren in het slechts geval ongeveer gelijk aan die van een harde schijf.

Aangezien je database vrij klein is en de selects goed gecached kunnen worden terwijl er wel erg veel geschreven wordt terwijl het aantal disks is afgenomen kan ik me voorstellen dat dit geen ideale omstandigheid is voor ssd's.

256MB zou opzich genoeg moeten zijn voor een MySQL database, uitbreiden kan niet op deze kaart als ik het goed heb. Er speciaal een Areca kaart gekozen omdat deze de snelste op de markt zijn.
Hier waren we al bang voor, we hebben gekozen voor 4 SSD's omdat er bij tegenvallende prestaties altijd de mogelijkheid is om er meer aan te schaffen waar vooral het gebruikte RAID 10 baat bij heeft. We kunnen er nog 4 kwijt, 8 stuks totaal dus.

------

Even out of the box: Je zegt dat je de database niet wil / kan optimaliseren, maar je hebt dan neem ik aan wel naar indexen gekeken / slow query logs? Je kan er nog zoveel hardware tegenaan gooien, maar full table scans worden er nauwelijks sneller van .

Hier gaan je inserts en updates natuurlijk niet sneller van worden, maar voor je selects kan het heel veel schelen.

TABLE-LOCKS, hier zit het probleem met onze database. We hebben een tweetal brede tabellen die veel writes te verwerken krijgen.
We zijn nu bezig om een mogelijkheid te zoeken om deze tabel op te splitsen maar ook dit zal heel veel werk kosten en misschien niet het euvel oplossen.

-----

Is het gebruik van de innoDB tabel noodzakelijk? Heb je voldoende geheugen aan inno toegewezen?

We hebben lang alles op MyISAM gedraaid, maar dit bleek ook niet alles. innoDB heeft meer geheugen dan dat de tabellen zelf groot zijn. Het exacte getal weet ik zo niet, maar dit is al flink geoptimaliseerd.

[BCC]

Bernardo schreef op vrijdag 05 september 2008 @ 15:34:
TABLE-LOCKS, hier zit het probleem met onze database. We hebben een tweetal brede tabellen die veel writes te verwerken krijgen.
We zijn nu bezig om een mogelijkheid te zoeken om deze tabel op te splitsen maar ook dit zal heel veel werk kosten en misschien niet het euvel oplossen.

InnoDB doet toch row locking? Of zit het table lock commando verweven in de code?
http://www.devshed.com/c/a/MySQL/MySQL-Optimization-part-2/
Je kan ook nog wat proberen met de prioriteit van updates vs selects.

En heb je al gedacht aan een gerepliceerde database waarop je alle selects doet? Of is dat ook niet mogelijk ivm code?

[ Voor 26% gewijzigd door BCC op 05-09-2008 16:04 ]

[TheNephilim]

BCC schreef op vrijdag 05 september 2008 @ 15:57:
[...]

InnoDB doet toch row locking? Of zit het table lock commando verweven in de code?
http://www.devshed.com/c/a/MySQL/MySQL-Optimization-part-2/
Je kan ook nog wat proberen met de prioriteit van updates vs selects.

En heb je al gedacht aan een gerepliceerde database waarop je alle selects doet? Of is dat ook niet mogelijk ivm code?

InnoDB doet inderdaad row-level-locking. Maar het lijkt niet mogelijk deze 2 grote tabellen op InnoDB te zetten. We hebben eerder al 1 van de 2 overgezet. Beide bleek niet mogelijk, dan was het geheel nog trager.

Dat van prioriteit ga ik even lezen

Repliceren is inderdaad niet mogelijk door de code, dit zou betekenen dat we 2 connecties krijgen, 1 om te schrijven en 1 om te lezen. Dan moeten we zoveel code aanpassen, dat is onbegonnen werk.
We hebben eerder al zelfs MySQL cluster overwogen maar dit bleek toch boven budget.

Edit: Na even rekenen kom ik op 5% van de table-locks is WAITED

[ Voor 3% gewijzigd door TheNephilim op 05-09-2008 16:14 ]

[BCC]

Je kan tegenwoordig ook een transparante MySQL proxy er tussenin zetten. De applicatie denkt dan met 1 database server van doen te hebben, terwijl de proxy eigenlijk bepaald waar de queries heengaan.
http://forge.mysql.com/wiki/MySQL_Proxy

Een MySQL cluster is in weinig gevallen een goede oplossing.
Een domme replicator die een hoop van de selects afvangt is vaak simpeler en sneller.

[ Voor 35% gewijzigd door BCC op 05-09-2008 16:12 ]

[TheNephilim]

BCC schreef op vrijdag 05 september 2008 @ 16:10:
Je kan tegenwoordig ook een transparante MySQL proxy er tussenin zetten. De applicatie denkt dan met 1 database server van doen te hebben, terwijl de proxy eigenlijk bepaald waar de queries heengaan.
http://forge.mysql.com/wiki/MySQL_Proxy

Een MySQL cluster is in weinig gevallen een goede oplossing.
Een domme replicator die een hoop van de selects afvangt is vaak simpeler en sneller.

Klinkt opzich best goed, ik wist niet dat er zo iets bestond! Hier kunnen we nog even naar kijken, maar het is eigenlijk niet meer de bedoeling dat er servers bij moeten. Wel heel intressant!

Ik heb nog even gekeken, we hebben 5% table-locks waited.

[voodooless]

Ik denk niet dat het erg zinvol zal zijn. Je database past compleet in memory, dingen sneller maken met meer servers is er denk ik niet echt bij. Insert en update kunnen traag zijn door tragere IO, selects kunnen echter in memory gedaan worden. Heb je meerdere apps die tegelijk hakken op de database, kun je misschien nog met meer CPU's wat schalen, maar per client individueel zal het niet sneller worden.. Uiteindelijk ga je toch de meeste winst maken door aan de database of applicatie zelf te sleutelen. Kijk eens naar de indexen... Ik heb deze week op die manier ook nog een hele berg mensen blij kunnen maken Vaak zijn dat maar de kleine dingen waar de winst op te halen valt, en is het echt niet nodig om de hele meuk overnieuw te gaan schrijven.

[pimlie]

Hoe ziet je mysql configuratie eruit? Heb je bv innodb geconfigureerd met innodb_flush_method = O_DIRECT? (Neem aan dat je wel een bbu aan die controller hebt hangen?)

En vooral een belangrijke vraag, hoe heb je je disks geconfigureerd op de server? Heb je de gehele mysql datadir op de ssd's gezet, dus inclusief (binaire) logs of gaan deze naar een andere disk?

[BCC]

Bernardo schreef op vrijdag 05 september 2008 @ 16:21:
Klinkt opzich best goed, ik wist niet dat er zo iets bestond! Hier kunnen we nog even naar kijken, maar het is eigenlijk niet meer de bedoeling dat er servers bij moeten. Wel heel intressant!

400 selects en 400 inserts per seconde is niet weinig. Heb je niet een bestaande replicator (voor backup doeleinden) die je ook wat selects kan laten verwerken?

reviews: Database test: dual Intel Xeon 5160

[_JGC_]

Onze DB server deed afgelopen week na een upgrade van een webserver ineens 35000 queries per seconde. We hebben het hier dan over een quadcore Xeon met 12GB geheugen en 4x150GB raptors in RAID-10 op een 3Ware 9550SXU.
Het aantal queries/s zegt helemaal niks. Er zat een bug in een script waardoor een simpele select tig keer achterelkaar werd uitgevoerd. Aangezien die query makkelijk te cachen is had onze DB server er geen problemen mee.

Je hebt het hier over een database van 7-8GB en 12GB geheugen. Dat moet makkelijk zonder vertragingen kunnen, je complete dataset past in het geheugen. Post je my.cnf eens, grote kans dat daar nog veel optimalisaties in mogelijk zijn.

Wat zijn overigens je problemen met InnoDB, de enige reden die ik me kan indenken dat InnoDB niet werkt is als je gebruikmaakt van de fulltext indexing die alleen met MyISAM werkt.

[TheNephilim]

Ik denk niet dat het erg zinvol zal zijn. Je database past compleet in memory, dingen sneller maken met meer servers is er denk ik niet echt bij. Insert en update kunnen traag zijn door tragere IO, selects kunnen echter in memory gedaan worden. Heb je meerdere apps die tegelijk hakken op de database, kun je misschien nog met meer CPU's wat schalen, maar per client individueel zal het niet sneller worden.. Uiteindelijk ga je toch de meeste winst maken door aan de database of applicatie zelf te sleutelen. Kijk eens naar de indexen... Ik heb deze week op die manier ook nog een hele berg mensen blij kunnen maken Vaak zijn dat maar de kleine dingen waar de winst op te halen valt, en is het echt niet nodig om de hele meuk overnieuw te gaan schrijven.

Daar heb je gelijk in, de database pas inderdaad compleet in memory. Het zou nog wel eens goed aan de IO kunnen liggen, van inserts en updates. Helaas zijn er nog geen Octo-cores... anders konden we makkelijk een CPU upgrade doen, maar of dat helpt is natuurlijk ook nog de vraag.
We zijn al bezig om deels wat dingen te splitsen naar andere tabellen, veel werk maar misschien toch maar eens naar kijken of het mogelijk is.

------

Hoe ziet je mysql configuratie eruit? Heb je bv innodb geconfigureerd met innodb_flush_method = O_DIRECT? (Neem aan dat je wel een bbu aan die controller hebt hangen?)

En vooral een belangrijke vraag, hoe heb je je disks geconfigureerd op de server? Heb je de gehele mysql datadir op de ssd's gezet, dus inclusief (binaire) logs of gaan deze naar een andere disk?

Yup InnoDB is inderdaad goed geconfigged wat betreft de innodb_flush_method, dat kwamen we meteen al tegen en dat is O_DIRECT (iig de snelste). battery backup unit bedoel je? ... ja die hebben we inderdaad aan de contoller hangen.
Alles staat op de RAID 10 partitie, OS ... DB en logs ook. We hebben er nog overnagedacht om het op aparte drives ofzo te zetten. Maar dit leek toch het beste met de SSD's

-----

400 selects en 400 inserts per seconde is niet weinig. Heb je niet een bestaande replicator (voor backup doeleinden) die je ook wat selects kan laten verwerken?

Nee, we maken geen gebruik van een replicator dus dat gaat helaas niet op.
Kzal dit weekend het linkje even gaan lezen. Bedankt.

-------

Onze DB server deed afgelopen week na een upgrade van een webserver ineens 35000 queries per seconde. We hebben het hier dan over een quadcore Xeon met 12GB geheugen en 4x150GB raptors in RAID-10 op een 3Ware 9550SXU.
Het aantal queries/s zegt helemaal niks. Er zat een bug in een script waardoor een simpele select tig keer achterelkaar werd uitgevoerd. Aangezien die query makkelijk te cachen is had onze DB server er geen problemen mee.

Je hebt het hier over een database van 7-8GB en 12GB geheugen. Dat moet makkelijk zonder vertragingen kunnen, je complete dataset past in het geheugen. Post je my.cnf eens, grote kans dat daar nog veel optimalisaties in mogelijk zijn.

Wat zijn overigens je problemen met InnoDB, de enige reden die ik me kan indenken dat InnoDB niet werkt is als je gebruikmaakt van de fulltext indexing die alleen met MyISAM werkt.

Queries per seconde zegt inderdaad niet alles, maar om even een beeld te geven van de situatie is het even handig.
Het geheel zou inderdaad helemaal in het geheugen moeten passen, zeker MYISAM maakt daar (zou je zeggen) dankbaar gebruik van. Toch niet helemaal blijkbaar, het zijn echt de writes naar de disks toe denk ik. Kzal misschien dit weekend nog even de my.cnf posten als dat lukt, anders word het maandag.
Nee, fulltext indexes gebruiken we niet in de innoDB tabellen, je kunt ze daar ook niet aanzetten zelfs volgens mij.

[Gomez12]

1e indruk is toch echt dat je gewoon eens naar je app / db moet gaan kijken.

Table locks zijn met inno-db overbodig, maar gooi zowieso eens de slow-query aan zodat je kan zien waar je indexen moet plaatsen
En met een 50/50 select/update verdeling zou ik me heel erg sterk gaan afvragen of je niet beter app-caching kan gaan toepassen. Ik kan me voorstellen dat je db bij deze aantallen updates geen optimaal gebruikt maakt van zijn cache. Zelfs een 1 sec app-cache kan dan imho wel redelijk wat schelen.

Maar bovenal zou ik proberen te achterhalen wat het probleem is met 2 innodb tabellen, als je hiermee je table-locks elimineert heb je volgens mij al een goede winst...

[maratropa]

Die areca 1222 is een SAS kaart toch? Was het niet beter geweest om gewoon een SATA areca kaart er voor te gebruiken?

[pafdaddy]

Tis een SAS/SATA controller, dus geen probleem lijkt me.

[mrFoce]

maratropa schreef op zaterdag 06 september 2008 @ 10:39:
Die areca 1222 is een SAS kaart toch? Was het niet beter geweest om gewoon een SATA areca kaart er voor te gebruiken?

Ik heb deze kaart en deze heeft gewoon aansluitingen voor SATA. Draai zelf ook 6x SATA zonder problemen. De kaart kan inderdaad ook SAS aan

[maratropa]

Wat ik bedoel is dat veel SAS kaarten wel SATA kunnen maar wel eens niet de snelheid halen van echte SATA kaarten.

Zo heeft femme ondervonden (dacht ik) dat de areca 1680 SAS bijv geen ster is met sata schijven.

En de snelheid van mtrons op een areca sata kaart met 2gb write back is in de benches van femme echt knettertje snel.

[pimlie]

Bernardo schreef op zaterdag 06 september 2008 @ 01:10:
Alles staat op de RAID 10 partitie, OS ... DB en logs ook. We hebben er nog overnagedacht om het op aparte drives ofzo te zetten. Maar dit leek toch het beste met de SSD's

Dan zou ik om te beginnen dit aanpakken. Lees ook de post van Femme nog eens door, het probleem zit hem ws gewoon in het mindere aantal disks. Het voordeel van ssd's zit vooral in het random lezen (door de lage access times), niet zozeer in het schrijven. Als je dus veel writes doet en van 8 naar 4 disks gaat kan je erop wachten dat je performance minder wordt.

In jullie geval is denk ik nu het beste om de writes proberen op te splitsen. Creeer een aparte raid 5 of 10 array met sas disks en zet hier het OS en logs op, dus ook de mysql binlogs.
Hopelijk is je performance dan al veel beter, zo niet dan zit er ws niets anders op om of de sas disks terug te zetten of 4 extra ssd's aan te schaffen

Overigens vind ik het nog steeds jammer dat de T.net Benchop geen raid 10 arrays met ssd's heeft gebencht. Uit mijn eigen test kwam dan wel naar voren dat voor mysql een raid 10 array beter presteert dan een raid 5, ik zou dit nog graag bevestigd zien door een test van de T.net Benchop met een betere controller (verkapte request aan Femme ).

[TheNephilim]

Hier een benchmark result van de SSD's:

[root@mysql ~]# hdparm -t /dev/VolGroup00/LogVol00 && ./seeker /dev/VolGroup00/LogVol00

/dev/VolGroup00/LogVol00:
Timing buffered disk reads: 492 MB in 3.00 seconds = 163.88 MB/sec
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/VolGroup00/LogVol00 $16960MB, wait 30 seconds..............................
Results: 3050 seeks/second, 0.33 ms random access time

------------

Dan zou ik om te beginnen dit aanpakken. Lees ook de post van Femme nog eens door, het probleem zit hem ws gewoon in het mindere aantal disks. Het voordeel van ssd's zit vooral in het random lezen (door de lage access times), niet zozeer in het schrijven. Als je dus veel writes doet en van 8 naar 4 disks gaat kan je erop wachten dat je performance minder wordt.

In jullie geval is denk ik nu het beste om de writes proberen op te splitsen. Creeer een aparte raid 5 of 10 array met sas disks en zet hier het OS en logs op, dus ook de mysql binlogs.
Hopelijk is je performance dan al veel beter, zo niet dan zit er ws niets anders op om of de sas disks terug te zetten of 4 extra ssd's aan te schaffen

De SSD's zijn wel duur, maar er is inderdaad altijd nog de mogelijkheid om er 4 bij te zetten. We hebben de SAS disks nog dus daar kunnen we nog even over nadenken.
Al met al nog een boel dingen die we kunnen doen, waarvan er een aantal natuurlijk geld kosten. Bovenal kost het natuurlijk veel tijd.

Mijn collega en ik hebben besloten een ingrijpende wijziging in de database structuur aan te brengen, we splitsen 1 tabel op naar 2 nieuwe onderdelen. Hier ligt waarschijnlijk de aard van het probleem. Mocht dit niet baten werken we het lijstje van andere mogelijkheden af.

De my.cnf hebben jullie ook nog van me tegoed, maar kan helaas niet de config vinden die we gebruikt hebben ten tijde van het '2-innodb-tabllen' probeersel.

[voodooless]

Je hebt nu net de twee dingen getest die hoogstwaarschijnlijk niet het probleem zijn: random en sequentieel lezen. Probeer eens een echte benchmark...

[pimlie]

Bernardo schreef op maandag 08 september 2008 @ 10:17:
Mijn collega en ik hebben besloten een ingrijpende wijziging in de database structuur aan te brengen, we splitsen 1 tabel op naar 2 nieuwe onderdelen. Hier ligt waarschijnlijk de aard van het probleem. Mocht dit niet baten werken we het lijstje van andere mogelijkheden af.

Eh, waarom denken jullie dat dit gaat werken? Als je hierna nog steeds hetzelfde aantal writes hebt blijft de disk performance gewoon het probleem, dan maakt het echt niet uit of het in 1 of 2 tabellen zit

Of splits je het op om dan alsnog innodb te gaan draaien?

[TheNephilim]

Je hebt nu net de twee dingen getest die hoogstwaarschijnlijk niet het probleem zijn: random en sequentieel lezen. Probeer eens een echte benchmark...

Helemaal correct, ik zal even nagaan of de write performance getest kan worden.

-----------

pimlie schreef op maandag 08 september 2008 @ 11:03:
[...]


Eh, waarom denken jullie dat dit gaat werken? Als je hierna nog steeds hetzelfde aantal writes hebt blijft de disk performance gewoon het probleem, dan maakt het echt niet uit of het in 1 of 2 tabellen zit

Of splits je het op om dan alsnog innodb te gaan draaien?

Klopt, maar dan zijn we er ook zeker van dat het daar aan ligt en kunnen we in hardware investeren waar nodig. Als we nu meteen investeren en het toch niet werkt, hebben we er misschien spijt van dat we het niet andersom doen.

[BCC]

Bernardo schreef op maandag 08 september 2008 @ 11:10:
Klopt, maar dan zijn we er ook zeker van dat het daar aan ligt en kunnen we in hardware investeren waar nodig. Als we nu meteen investeren en het toch niet werkt, hebben we er misschien spijt van dat we het niet andersom doen.

?! Ik weet niet, maar hardware is altijd goedkoper dan ontwikkeltijd. Of het moet natuurlijk een hele simpele fix zijn. Aan de andere kant, als je zo slechte performance hebt op zulke snelle hardware, dan moet je idd het probleem in de software gaan zoeken. Ook al is je db server nog zo snel, zonder indexen blijft het huilen.

[TheNephilim]

BCC schreef op maandag 08 september 2008 @ 12:23:
[...]

?! Ik weet niet, maar hardware is altijd goedkoper dan ontwikkeltijd. Of het moet natuurlijk een hele simpele fix zijn. Aan de andere kant, als je zo slechte performance hebt op zulke snelle hardware, dan moet je idd het probleem in de software gaan zoeken. Ook al is je db server nog zo snel, zonder indexen blijft het huilen.

De database is niet van het beste hout gesneden zoals ik al aangaf. Maar dit zit hem niet meer in indexes enzo, dat is prima in orde. We hebben soms te brede tabellen en chars waar ints horen.
De fix was inderdaad minder ingrijpend dan we altijd dachten maar wel gewoon even goed gecoördineerd werk.