Database server configuratie met hoge IO/s

Heb je uberhaubt al eens gekeken waar de load precies vandaan komt?

Met een recente versie van sar kan je met "sar -d 10 1" de disk utilization over de afgelopen 10 seconden bijvoorbeeld meten.

Is die 100%, dan weet je dat daar je bottleneck zit.

Uitrekenen hoeveel I/O's je nodig hebt, en kijken hoeveel je schijven kunnen halen?
Ik zou (zo in eerste instantie) het aantal schijven uitbreiden in je raid5 set (meer spindels)

is RAID 01/10 niet beter dan RAID 5?

[ Voor 5% gewijzigd door Archiebald op 17-11-2006 23:21 . Reden: omdat burn zit te zeuren over ABN ]

Voor een DB server is de diskconfiguratie inderdaad vrij belanrijk. Voorals als er veel IO moet worden gedaan.

Hoe ziet de huidige configuratie eruit

Een Ideale configuratie zou zijn:
System: 2 disken in RAID1 (mirror)
Data: 4 disken in RAID 10 (gemirrorde stripeset) of 2 disken in RAID 1.
Logs: 4 disken in RAID 10 (gemirrorde stripeset)

De meeste IO zit in de transaction logs. Dus die moet echt snel zijn. Naast de diskconfiguratie is genoeg geheugen ook handig. Het cachen van queries, tables en het toestaan van voldoende connections vreten genoeg geheugen.

Ik zou zeggen, kijk eens naar de huidige configuratie van Apollo (De DB server van T.Net)

Met die hoeveelheid data en RAM lijkt het me onwaarschijnlijk dat je probleem in je reads zit. Logischerwijs zit het dan in je writes.
Hoe heb je op dit moment je commits geconfigureerd? Per transactie of per X seconde? (Je draait toch wel InnoDB hè?) Kan je het je permiteren om m inder vaak te commiten? Kan je queries groeperen in transacties zodat je nog minder vaak commit?

Binnen je budget zou ik goed naar Sun Opterons kijken (er zijn benchmarks waar die 2 GB/s I/O halen) maar vooral naar een RAID controller met battery backed cache zodat je gebruik kan maken van een write-back cache.

Bernardo schreef op zaterdag 18 november 2006 @ 23:47:
Oké dat past meestal niet in een enkele server toch?

Jawel . Er zijn bijvoorbeeld Chenbro 3U cases met 12x hotswap (click)

Een cluster brengt je geen verbetering van de performance. Alleen kwa beschikbaarheid. Zowiezo is clusteren in MySQL nog niet echt aan te raden. Hooguit in een active/passive configuratie.

Er zijn natuurlijk wel servers met 12 disksloten, maar wellicht zijn die wat boven je budget

Maar nogmaals, kijk eens naar de .plan voor apollo. Die heeft een bay met 14 of 16 disken over een dikke verbinding met de server.
edit: plan: Forum in verwachting van nieuwe database-server deze dus

[ Voor 5% gewijzigd door Equator op 19-11-2006 11:04 ]

Bernardo schreef op zaterdag 18 november 2006 @ 23:47:

We maken geen gebruik van innoDB

50% van je queries schrijft, maar je gebruikt een tabeltype dat een tabel exclusief moet locken bij elke wijziging.

we hebben wel gedeeltes op inno gehad... maar dat maakte de site alleen maar slomer.

Delen InnoDB helpt niet, je moet alles op InnoDB hebben anders zit je nog steeds met je lockingprobleem.

Is InnoDB ook goed bij grote tabellen (soms meer als 1 miljoen rijen)?
want je wil niet dat de site traag wordt doordat er veel mensen bijv op het forum posten, en dus de tabel elke keer locked/unlocked

innoDB op wikipedia
InnoDB info op mysql.com

Leesvoer

Bernardo schreef op zaterdag 18 november 2006 @ 23:47:
[...]
Oké dat past meestal niet in een enkele server toch? Maar hier hebben we wat aan. We zitten hier dus op 10 disken. De caches kunnen we misschien nog wat optimaliseren. Aangezien onze query cache nu op 1GB staat en die niet meer dan 256 gebruikt. De tmp_table_size moet nog wat omhoog. Hij maakt ze nu op disk aan. Dat is ook nog wel een probleem.

Als je drie RAID1 mirrors aanmaakt dan heb je aan een Proliant DL38x of IBM System X 365x genoeg.

Je kan dan gewoon 2x36 en 2x2x146GB SAS schijven erin proppen en gezien de huidige configuratie is dat genoeg.

Voorbeelden:
Proliant DL385: http://h10010.www1.hp.com...5-241475-f79-3219233.html
IBM x3655: http://www-03.ibm.com/systems/x/rack/x3655/index.html

offtopic:
tja, of we moeten de lui van hyves inhuren:P

http://www.youtube.com/wa...XSXb-BA&mode=user&search=
zie filmpje... is wel heel vet hoor.. 25TB opslag
maar voor ons onbetaalbaar

ja, ik ben mede beheerder van de website waar TS het over heeft

ontopic:
nja, we moeten maar even kijken, heb liever dat de site even stabiel draait en zonder enige downtime voorbij de feestdagen komt.. hopen dat we nog een beetje kunnen profiteren van de gulle opa's en oma's

dat geeft ons ook weer de gelegenheid om goed over een eventuele hardware uitbreiding te denken

[ Voor 37% gewijzigd door Archiebald op 20-11-2006 21:14 ]

ACM schreef op maandag 20 november 2006 @ 22:36:
[...]

en vervolgens wordt er myisam gebruikt, dat niks aan logs bijhoudt, waardoor ie dan 4 disks voor jan met de korte achternaam heeft gekocht

[...]

Niet bij MyISAM dus. Voor Innodb is het idd relevanter, maar ik vraag me af of het zinvoller is om twee losse raids te bouwen ipv een grote. Onze eigen tests lieten iig zien dat de lsi-logic/dell perc5 sas-controllers iig wel sneller worden met meer dan 4 disks. Of dat in de beoogde configuratie hier ook geldt durf ik niet te zeggen.

Mijn aanname was dat je altijd logs had welke je op een ander fysieke disk moet plaatsen. Blijkbaar is dat bij MySQL dus alleen bij het type InnoDB en niet bij MyISAM dus. Weer wat geleerd.

Dat maakt mijn diskconfig inderdaad een beetje overkill dus.
Overigens was mijn verwijzing naar de apollo config alleen als voorbeeld

Bernardo schreef op dinsdag 21 november 2006 @ 21:49:
Dit is misschien ook het geval op ons Forum. Net als bij de berichten de text (op titel na) gescheiden van de rest van de informatie. Dit word met een JOIN bij elkaar geknoopt. We willen best proefdraaien op InnoDB met de berichten, dit moet gewoon kunnen met de data erin neem ik aan?

Tenzij je full text indices er op hebt. Daar zijn overigens wel weer alternatieve constructies voor, waarbij je een master-slave constructie opzet en op de slave een myisam versie van de innodb-master gebruikt.

De andere optie om een nieuwe server aan te schaffen is wellicht interessant, maar wij verwachten nog een grote toename in gebruikers en een MySQL cluster lijkt ons beter schaalbaar.
We moeten nog veel uitzoeken wat beftreft de mogelijkheid van een Cluster.

Hoeveel bezoeken doe je nu? En waarom moet er zo veel geupdate worden?

Overigens heeft MySQL een "echt" cluster, wat een in-memory database systeem is met allerlei beperkingen (alleen fixed size records enzo) en een master-slave replication omgeving. Dat laatste kun je met de beste wil van de wereld eigenlijk geen cluster noemen

Als ik mij niet vergis behaal je met een cluster toch niet alleen redundancy maar toch ook snelheid (=performance). We denken op dit moment na over een 3 server config. 1 master en 2 nodes. Worden de SELECTS alleen gestriped?

Dat soort dingen moet je allemaal zelf regelen. Als jij de selects naar node 2 of 3 wilt sturen moet je dat zelf doen en dus ook twee verbindingen openen (omdat je je updates/inserts/deletes naar node 1 wilt blijven sturen), met een beetje fatsoenlijke abstractie is dat natuurlijk niet zo moeilijk. Imho zitten er allerlei lastige haken en ogen aan, waardoor we het hier op Tweakers.net voorlopig nog wel bij het optimaliseren van software en het zo nu en dan aanschaffen van een nieuwe server houden.
Maar je zegt zelf al dat je nu al zo'n 50% updates doet, oftewel de helft van je queries blijft naar je master gaan en dan kan je er wel twee extra slaves aan hangen, je master blijft een bottleneck zolang je het aantal updates niet terug weet te brengen of anderszins weet te splitsen.

Magoed, ik heb nog altijd wat moeite om voor te stellen dat je aan drie webservers genoeg hebt en dat die databaseserver met zulke specificaties dan niet voldoet voor je bezoeken, na optimalisatie van je software en databases. Het enige wat er wat ondermaats aan is, is de I/O maar je hebt niet zo'n hele grote database, dus ook dat zou toch redelijk mee moeten vallen.

Bernardo schreef op woensdag 22 november 2006 @ 19:42:
Allereerst even een overzicht van onze database, het gaat hier om het omcircelde rijtje:
[afbeelding]

Inderdaad niet zo'n grote database

Ik zie trouwens overhead staan, ik heb zelf wel eens gehad dat queries op een tabel met een paar MB overhead significant langer duurden, werk je die overhead geregeld weg (op een high-traffic site kan dat wat lastig zijn)?
Dat is nog een van de redenen om innodb te bekijken, die heeft een wat geavanceerder opslagsysteem, waardoor ook de vrijgekomen ruimte na updates en deletes mogelijk weer ingezet kunnen worden.

We hebben geen fulltext indexes. Wel enkele indexes CHARS/VARCHARS op namen. Maar dit zijn er niet veel. Behalve dat worden zo ook nooit gewijzigd.

Dat is verder geen probleem voor innodb.

Die constructie snap ik niet zo, misschien kun je een klein voorbeeld aandragen?

Je weet wel wat replicatie bij mysql inhoudt neem ik aan? Dat is dat je een master hebt met de data en een of meerdere slaves die die data overnemen.
De slaves krijgen die data in een bepaalde binary communicatie doorgezonden en verwerken dat dan lokaal (en serieel) in hun eigen versie van een gerepliceerde tabel. Die tabel hoeft daardoor niet exact hetzelfde er uit te zien als op de master-server, je zou dus zelfs een andere storage-engine kunnen gebruiken. Normaliter wil je dat waarschijnlijk niet, maar het gebruiken van innodb op je master (ivm hoge concurrentie mogelijk bij updates, en een transaction log enzo.) en myisam op je slaves (mogelijk wat sneller lezen en full text indexing beschikbaar op dezelfde data die op de master in innodb dat niet heeft/kan) kan zo zijn voordelen hebben.

De website draait 's avonds op 900+ gebruikers tegelijkertijd, die gebruikers klikken natuurlijk veel. Een pagina bestaat uit minimaal 4 querys. Dit om gegevens op te halen en 1 keer in de 60sec de online tijd bij te werken.

Met vier queries per pagina wordt het idd lastig een en ander nog verder te verminderen. Kijk wel goed of die vier dan weer niet te zwaar zijn. Mysql 4.1 is bijvoorbeeld relatief slecht met subqueries, mysql in zijn geheel is relatief slecht met queries die veel en/of complexe joins uitvoeren.
Het uitsplitsen van queries kan bij mysql (en ook wel bij postgresql en vast ook de grote jongens) grote verschillen opleveren.
En natuurlijk kijken of voor al je queries wel de goede indexen aanwezig zijn en gebruikt worden, zelfs als het maar 0,001s scheelt, kan dat een merkbaar verschil zijn als je er tientallen tot honderden per seconde van verwerkt.
En kijken of je geen data steeds opnieuw uit je database trekt die vrijwel niet verandert, die zou je eventueel in een lokale cache (bijv met eaccelerator) of globale cache (bijv met memcached) op kunnen slaan.

Dat in-memory database systeem geen echt cluster genoemd kan worden is geen punt, als het maar snel en een goede fail-over heeft. Ik zal toch eens meer tijd moeten vrijmaken om dit goed uit te zoeken. Ik heb nog nooit gehoord dat de eerstegenoemde een fixed size records type is.

Je leest het verkeerd, mysql heeft twee vormen waarbij meerdere databaseservers samen kunnen werken:
- NBD (of was het nou ndb), een echte clustering (dus verdelen van load enzo) met in-memory opslagsysteem dat dus enerzijds beperkt is tot het beschikbare ram en daarmee als groot nadeel heeft dat je fixed size records hebt (een varchar(255) kost dan bijv altijd 255 bytes!) en anderzijds dat bij uitval die specifieke machine sowieso zijn data kwijt is.
Hoe het verder precies werkt weet ik niet, maar ik zou het niet overwegen voor normaal gebruik. Hooguit voor heel-hoog verkeer oplossingen waarbij je van alles in je geheugen kan houden en heel snel weer beschikbaar moet hebben.

- Master/slave replicatie, het standaard replicatiegebeuren. Een master die alle writes moet krijgen en een of meerdere slaves die je om wat voor reden dan ook op zet. Dat kan zijn omdat je een hot-standby wilt, omdat je read-queries van je master af wilt halen, omdat je een aparte full-text-indexed database wilt hebben (zonder de extra load op je master) etc.

Wat ik las is dat je query's uitvoerd op je master/management server en dat die uitzoekt waar hij de query's moet laten en vandaan gaat halen.

Bij mijn weten moet je bij master/slave-replicatie volledig zelf zorgen voor waar de query terecht komt. Er zullen wel al libraries zijn die dat voor je regelen (bijv een regexp op de query en kijken of ie met select begint), maar misschien dat je hier NBD en gewone master/slave replicatie door elkaar.

Dit vind ik zelf geen goede methode, omdat je dan niet kunt checken (met php) of iets wel of niet gelukt is.

Hoe bedoel je dat? Je kan zien of een query gelukt is, maar je kan natuurlijk niet zien of een update voor kolomY en kolomX van tabelA inderdaad beide kolommen veranderde, maar anderzijds is dat meestal ook niet zo relevant om te weten toch?

Het lijkt op dit moment idd het IO te zijn. We verwachten wel dat ook de CPU capaciteit op een gegeven moment opraakt. We doen het liever nu goed, dan dat we bezig blijven met het aanschaffen van servers.

De makkelijkste en vooral goedkoopste manier die je hebt om uit te zoeken of het kan helpen is imho om een memory-disk (shmfs mount is het mooist in linux 2.6) aan te maken en daar je database in in te laden en te kijken hoe goed het dan presteert. Nadeel is dat het een paar minuten downtime kost en dat je niet net dan je server plat moet krijgen.
Maar zoals gezegd zal de I/O niet sneller dan dat kunnen en als met dat als enige wijziging het ineens een stuk beter gaat, dan weet je dat een verbetering van het I/O-systeem je aardig kan helpen.
Om te beginnen zou je dan naar een 4 of 6 disk raid 10 kunnen kijken met een raidcontroller die ook writes cached.

Kan me vergissen, maar ik zie nergens om wat voor RAID controller het gaat die die RAID 5 afhandelen moet. Juist met RAID 5 is dat enorm belangrijk! De controller kan je systeem maken of breken ..
De data verhuizen naar een RAID 0+1 leert snel genoeg of dat het probleem is.

't Is maar een idee

Hallo iedereen,

Ik zie deze thread wat aan de late kant, maar het is zo on topic op iets waar ik me de afgelopen tijd mee bezig heb gehouden dat ik wel moet reageren!

1: meer schijven is vooral goed voor meer IOps. Een enkele disk levert zo'n 100 - 140 IOps (on top of my head). Veel IOps is goed als je veel random (tegenovergestelde van sequentieel) IO hebt. Als ik je qps aantallen zie, dan zullen lees en schrijf acties random lijken voor de raid array.
2. misschien ten overvloedde: doe eens iostat -x 1 (zit in het sysstat package (zowel debian als redhatl)) Hier zie je zowel de wait (als je een linux 2.6 kernel hebt) en ook ergens het aantal iops. Is de wait hoog dan staat de cpu uit z'n neus te eten terwijl hij op het armpje van de disk wacht.
3. transactielogs (in oracle: redo logs) schrijven is sequentiele IO: dit mixen met random IO is slecht (zegt men) voor de IOps van de random IO en de mbps van de sequentiele IO. Maar ergens in de thread ving ik iets op dat Mysql in een of andere variant geen transactielogs schrijft, dus wie weet niet relevant.
4. Oracle heeft een coole testtool voor disks: het heet orion en is zoiets als iometer. Het is een los ding wat je kan downloaden en je kan hier snel diverse raid setups met elkaar vergelijken.
5. De mensen die RAID5 adviseren hebben iets dergelijks als stap 4 denk ik nog nooit gedaan :-)

Onze configuratie: een HP MSA configuratie (msa1000+msa30), met 28 15K scsi disks. Dit noemt HP entry level en is prima betaalbaar, en je kan er toch een redelijke performance mee halen, mits goed geconfigureerd. Hierop hebben we drie raid 1+0 volumes gedefinieerd, 4 disken zijn over voor hot spare. De SAN hangt met fibrechannel aan de db server: een enkele opteron 285 dual core. M'n high score IOps wat ik hiermee (met de testtool orion) ligt ergens bij de 5200. MBps was rond de 156MBps (maar de IOps was het belangrijkste).

Hoop dat dit nuttige info is.
Yepster

Even misschien een domme vraag, maar wat is de beste manier om je IO/s te meten? (ik spreek hier over Windows omgevingen).

Met IOMeter kan je wel enkele benchmarks doen, maar daar zijn je IO/s uiteraard afhankelijk van soorten/grootte van de schrijf&lees acties.

Intel heeft in het verleden een tool gehad waarmee je disk I/O in een trace kon vastleggen en die trace op een willekeurige disk kon afspelen. Helaas wordt die tool niet meer ontwikkeld en is hij nauwelijks bruikbaar in productieomgevingen. Erg jammer, want het lijkt me dat bijv. DBA's ook wel behoefte hebben aan tools waarmee zij disk I/O kunnen isoleren en de performance makkelijk op verschillende platformen kunnen vergelijken.

Met een zelfgemaakt toegangspatroon in IOMeter weet je nooit hoe dicht je de werkelijkheid nadert. De write-back cache op de RAID-controller zal weinig invloed kunnen uitoefenen in IOMeter-tests.

yepster2 schreef op zaterdag 25 november 2006 @ 18:31:

3. transactielogs (in oracle: redo logs) schrijven is sequentiele IO: dit mixen met random IO is slecht (zegt men) voor de IOps van de random IO en de mbps van de sequentiele IO. Maar ergens in de thread ving ik iets op dat Mysql in een of andere variant geen transactielogs schrijft, dus wie weet niet relevant.

Ik heb wel eens traces gemaakt van MySQL en Exchange 2003 in zware gesimuleerde omgevingen. In beide gevallen was de disk I/O die er door logging werd veroorzaakt minimaal. Je moet goed je best doen om zoveel belasting te veroorzaken dat er 1MB/s aan logs weggeschreven kunnen worden. 1MB/s is peanuts voor een harde schijf. Er is geen enkele RAID-controller die er moeite mee heeft om dat te mixen met hoofdzakelijk random I/O. Een goede controller lost het op door de schrijfacties van de logs een paar seconden te verzamelen en dan gecombineerd weg te schrijven op een moment dat er even weinig andere I/O is.

Vanuit het oogpunt van een veilige data-opslag wil je wel graag logs gescheiden houden van data.

11:00:01 AM	CPU	%user	%nice	%system	%iowait	%idle
11:10:01 AM	all	16.03	0.00	9.03	2.86	72.07
11:20:01 AM	all	15.27	0.00	8.84	2.71	73.19
11:30:01 AM	all	14.09	0.00	8.07	3.00	74.84
11:40:01 AM	all	13.75	0.00	8.31	2.89	75.05
11:50:01 AM	all	14.18	0.00	7.90	3.12	74.80
12:00:01 PM	all	15.96	0.00	9.55	2.74	71.75
12:10:01 PM	all	16.40	0.00	9.38	3.40	70.83
12:20:01 PM	all	16.45	0.00	9.29	3.61	70.65
12:30:01 PM	all	16.72	0.00	9.41	3.55	70.32
12:40:01 PM	all	21.24	0.00	13.03	4.98	60.75
12:50:01 PM	all	28.38	0.00	18.12	4.26	49.25
01:00:01 PM	all	28.93	0.00	18.33	4.11	48.63
01:10:01 PM	all	33.57	0.00	20.60	4.09	41.74
01:20:01 PM	all	36.25	0.00	23.85	3.77	36.13
01:30:01 PM	all	36.05	0.00	23.86	3.92	36.17
01:40:01 PM	all	35.19	0.00	23.48	3.73	37.61
01:50:01 PM	all	38.04	0.00	25.41	3.31	33.23
02:00:01 PM	all	35.94	0.00	24.89	3.31	35.87
02:10:01 PM	all	36.55	0.00	24.73	3.59	35.13
02:20:01 PM	all	34.51	0.00	23.26	3.61	38.61
Average:	all	10.19	0.00	6.10	1.69	82.02

Online: +/- 450

TOP ziet er zo uit:

top - 14:25:38 up 10 days, 22:50, 1 user, load average: 5.69, 5.02, 4.64
Tasks:	72 total,	1 running,	71 sleeping,	0 stopped,	0 zombie
Cpu0 :	43.1% us	30.4% sy	0.0% ni	23.5% id	0.0% wa	1.0% hi	2.0% si
Cpu1 :	44.0% us	16.0% sy	0.0% ni	40.0% id	0.0% wa	0.0% hi	0.0% si
Cpu2 :	19.0% us	16.0% sy	0.0% ni	65.0% id	0.0% wa	0.0% hi	0.0% si
Cpu3 :	32.4% us	10.8% sy	0.0% ni	55.9% id	0.0% wa	0.0% hi	1.0% si
Mem:	8162416k total	3602092k used		4560324k free		67164k buffers
Swap:	2031608k total	796820k used		1234788k free		1693656k cached

[ Voor 18% gewijzigd door Archiebald op 29-11-2006 14:34 ]

System time is wel vrij hoog ja, zou I/O kunnen zijn, wat zegt iostat ?

[root@mysql5 ~]# iostat
Linux 2.6.9-42.0.3.ELsmp (-----) 11/29/2006

avg-cpu:	%user	%nice	%sys	%iowait	%idle
	21.29	0.00	13.92	1.82	62.97
Device:	tps	Blk_read/s	Blk_wrtn/s	Blk_read	Blk_wrtn
sda	41.93	2.70	411.55	2592702	394723910
sda1	0.00	0.00	0.00	1360	222
sda2	51.62	2.70	411.55	2590246	394723640
dm-0	51.25	2.49	408.75	2391298	392043744
dm-1	0.38	0.21	2.79	198280	2679944

Archiebald schreef op woensdag 29 november 2006 @ 18:08:
[root@mysql5 ~]# iostat

Hier heb je op zich niet zo veel aan... iostat heeft echter ook net als vmstat en mpstat de mogelijkheid om het over een bepaalde periode te bekijken. Bijvoorbeeld 20 keer en dan steeds 5 seconden wachten.

Bernardo schreef op maandag 04 december 2006 @ 21:07:
Je kunt hieruit dus nog geen diagnose stellen om het zo maar te zeggen?

't Totaal aantal read/writes zegt natuurlijk bijzonder weinig over die tijdens de drukkere momenten

dat is waar...
alleen ik moet elke dag tot 17:00 uur (druk moment) stage lopen... kan opzich wel checken dan aangezien ik op stage putty en dergelijke heb, maar meestal gamen we het laatste half uur/kwartier... zal vandaag proberen om rond 17:00 en 20:00 (drukste momenten) even de statistieken bij te houden..
met een interval van 30 seconden en dan gedurende 10-15 minuten...

overigens hebben we (in onze ogen) scherp geprijste offerte gekregen voor 4 Woodcrests... voor een MySQL cluster. Maar we willen eerst achter de bottleneck komen voordat we iets aanschaffen, want straks is het zonde van het nogal dure MySQL cluster

Als je veel schrijft is het sowieso maar de vraag of een mysql replication set-up je heel erg gaat helpen... Ik ga er tenminste van uit dat je het niet over een NDB-cluster hebt.

En wil die woodcrest-aanschaf dan effectief zijn, dan moet ie vooral op het gebied van I/O beter zijn, niet domweg snellere procs en/of meer ram hebben.

[ Voor 30% gewijzigd door ACM op 06-12-2006 14:25 ]

hier kun je een overzichtje vinden van iostat van tussen 19:50 en 20:05 vanavond...

Is de forumsoftware zelf geschreven of is het een van de bekende pakketten?
Ik heb fora zien draaien van gelijke grootte met 400 users tegelijkertijd welke op een kwart van die servercapaciteit draaide.

wij zijn niet alleen een forum, maar ook een compleet spel eromheen (nee, geen criminals... totaal iets anders)
Het forum is wel actief en redelijk groot. De software is zelf geschreven. Er is wel kritisch gekeken naar de database structuur, waarbij we ook naar de structuur van phpBB gekeken hebben.

@ACM:
Over welk cluster de serverbouwer ons had aangeraden weet ik zo even niet, dit zou ik even moeten navragen

Hele stomme vraag misschien, maar wat is de performance van de schijven? Staan ze wel op 32 bit, DMA, etc? Want dat levert ook een heel zwaar system process op en weinig throughput..

[ Voor 26% gewijzigd door BCC op 07-12-2006 11:53 ]

Archiebald schreef op woensdag 06 december 2006 @ 20:12:
hier kun je een overzichtje vinden van iostat van tussen 19:50 en 20:05 vanavond...

Ik zou maar niet direct naar een andere I/O-oplossing op zoek gaan, want als dat je piek diskverbruik is, dan is het weinig... Je bevestigt overigens ook dat er vrijwel geen reads gedaan worden.

Je zou nog met een 1 seconde interval kunnen kijken of er hele hoge pieken tussen zitten, maar wat je nu toont is niet erg veel veel en duidt imho niet (direct) op een bottleneck bij de I/O.

Trouwens, had je al eens naar je slow query log gekeken? Daar kunnen ook allerhande interessante dingen in staan.

BCC schreef op woensdag 06 december 2006 @ 21:32:
Hele stomme vraag misschien, maar wat is de performance van de schijven? Staan ze wel op 32 bit, DMA, etc?

Dat soort dingen stel je vziw niet meer in bij SATA schijven

[ Voor 6% gewijzigd door ACM op 07-12-2006 10:35 ]

ACM schreef op donderdag 07 december 2006 @ 10:31:
[...]
Trouwens, had je al eens naar je slow query log gekeken? Daar kunnen ook allerhande interessante dingen in staan.

van gisteren staat er maar 1 query in.
en dat is nog eens een delete query ook

we hebben ook meer info over de mysql cluster, de commerciele versie hiervan wordt ons denk ik iets te veel van het goede (support kosten van 20.000 euro per jaar en dan nog eens 4000 licentie kosten per jaar per server...)

Ik hoop voor je dat MySQL er bij jou beter op schaalt dan bij ons Anders was je beter af geweest met een stel 5160's en wellicht dan ook met 667Mhz geheugen.

[ Voor 10% gewijzigd door ACM op 14-12-2006 12:02 ]

toevallig hadden we het net besteld toen we die review zagen...

Binnenkort als we klaar zijn met school (lees: zomervakantie)
wil ik een jaartje vrij nemen voordat we HBO gaan doen en lijkt het me beter om de hele site/database vanaf begin af aan opnieuw op te bouwen/zetten..

Ten eerste omdat we toen we begonnen een beetje verstand van alles hadden. Nu weten we wat wel en wat absoluut niet moet.

Ten tweede, dan hebben we de tijd om alle zaakjes op orde te zetten enzo.

En misschien beter om de mogelijkheid uit te zoeken of PostgreSQL misschien beter is voor ons dan MySQL, want ik hoor veel positieve dingen van PostgreSQL.

Nu moeten we zorgen dat we online blijven, en dan komt hopelijk alles goed

Mailtje van hostingprovider:

Zojuist de leverancier aan de telefoon gehad.

Vanwege de feestdagen en aangezien het de nieuwste processor en moederbord betreft welke vanuit de V.S. aangeleverd dienen te worden wordt de server medio januari aangeleverd.

U bent een van de eerste in Europa welke in het bezit is van de allernieuwste apparatuur in Europa.