[mysql] Website traag

[kweenie]

Beste medetweakers,

Ik beheer een website waar je online een huisdiertje kunt opvoeden.
De site draait op een dedicated server met de volgende stats:

» 120gigabyte harddisk
» Pentium4
» 3.0ghz Processer
» 1024mb RAM Geheugen
» Fedora Linux

Nu gaat dit allemaal best en is het verschrikkelijk snel, totdat het spitsuur begint en de kids uit school komen. Van 15 uur tot 20 uur is het vrijwel ondoenlijk om op de site te komen, constant knalt MySQL eruit.
Per dag zijn er 5000 nieuwe registraties en op die drukke momenten zijn er 2600 mensen tegelijk online. Er zijn per dag 1,3 miljoen pagina weergaves.

Wat heb ik al geprobeerd?
» De site draait nu op Sessies en heeft hierdoor een stuk minder query's omdat er niet meer gecheckt wordt op cookies via Mysql.
» my.cnf diverse standaarden gebruikt, en diverse instellingen geprobeerd van 'mysql tweak up' sites.
» vermindering aantal querys door efficienter gebruik (complete site herschreven).
» bepaalde scripts via cron draaien en html eruitgooien ipv elke gebruiker de query's laten runnen.
» Indexes aangemaakt.

Hieronder heb ik nog enkele stats:

code:

top - 19:27:01 up 49 days,  8:01,  1 user,  load average: 25.38, 25.94, 24.44
Tasks: 499 total,  44 running, 455 sleeping,   0 stopped,   0 zombie
Cpu(s): 77.8% us, 19.5% sy,  0.0% ni,  0.0% id,  1.3% wa,  1.3% hi,  0.0% si
Mem:   1026620k total,   982132k used,    44488k free,    41532k buffers
Swap:  2040244k total,    37356k used,  2002888k free,   385080k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
25973 mysql     19   0  279m 213m 2480 R 14.3 21.3   0:00.44 mysqld
26018 mysql     15   0  279m 213m 2480 S 14.3 21.3   0:00.44 mysqld
26098 mysql     18   0  279m 213m 2480 R  7.5 21.3   0:00.23 mysqld
26073 mysql     18   0  279m 213m 2480 R  7.2 21.3   0:00.22 mysqld
20765 apache    15   0 20660  12m 8812 S  1.0  1.2   0:00.24 httpd
17463 apache    15   0 20852  12m 9204 S  0.7  1.3   0:00.44 httpd
17532 apache    15   0 20676  12m 8800 S  0.7  1.2   0:00.35 httpd

De MySQL server draait nu 5 dagen met de volgende statistieken, dan kun je ongeveer zien hoe server belastend het allemaal is

code:

Query statistieken: Sinds het opstarten zijn er, 108.051.537 queries gestuurd naar de server.
Totaal ø per uur ø per minuut ø per seconde 
108 M 859,91 k 14,33 k 238,86

Van diverse mensen heb ik te horen gekregen dat ik naar een 2e server toe zal moeten zodat er 1 Database server is en 1 webserver. Dit is nu nog niet het geval.
Maar ik heb zelf zoiets van het liefste wil ik het op 1 server vooral vanwege de hoge kosten van een 2e server. En het lijkt me dat 1 server toch mogelijk moet zijn.

Ik heb geen database structuur meegepost maar zijn er dingen die ik over het hoofd heb gezien? Kunnen dingen anders? Tips van harte welkom

[ Voor 4% gewijzigd door kweenie op 01-05-2006 19:45 . Reden: wat vergeten ;) ]

[NetForce1]

Heb je al indexen aangemaakt op relevante kolommen in je DB? Dat kan ook significant schelen.

[kweenie]

Ja vergeten te vermelden, zijn idd aangemaakt

[NetForce1]

Wellicht ook een open deur, maar prepared statements zijn ook altijd aan te raden. Anders moet je eens wat timertjes plaatsen om te kijken waar de bottleneck(s) zit(ten).

[JHS]

Vooral zoveel mogelijk onderdelen van je applicatie gaan benchmarken / timen. Zonder de code en databaseopzet te zien kunnen wij lijkt me verder niet zoveel betekenen. En het lijkt me niet de bedoeling dat mensen hier je hele code langs zou gaan lopen .

Het lijkt me dus handiger om de langzaamste delen van je applicatie proberen te achterhalen, en kijken of je deze sneller kan maken. En als je daar niet uitkomt kan je natuurlijk hier hulp vragen . Ook zou je met behulp van mysql slowlog kunnen kijken wat de trage queries zijn.

Doe dit overigens allemaal wel in een testomgeving welke, ook qua gegevens, een kopie is van je live omgeving, of in de live omgeving zelf. Als je het in een testomgeving doet zou je kunnen kijken naar tools voor stresstesten. In je development omgeving worden dingen lang niet altijd duidelijk .

Maar alhoewel ik niet de meest geschikte persoon ben om dat in te schatten, klinkt het toch enigzins alsof er toch echt een tweede server nodig is .

[moto-moi]

Wat geeft een paar minuten 'vmstat 5' draaien voor uitvoer ?

[Sybr_E-N]

Wat je nog meer kunt doen is je queries optimizen, haal ze eens door Explain wie weet kun je daar nog het een en ander winnen. Daarnaast: maak je ook gebruikt van enige vorm van caching, van zowel querie resultaten als html? Hiermee kun je zowel de database ontlasten als de webserver, die dan grote delen alleen maar terug hoeft te sturen (wat sneller gaat dan continue hele pagina's dynamisch op te laten bouwen)

[kweenie]

moto-moi schreef op maandag 01 mei 2006 @ 19:55:
Wat geeft een paar minuten 'vmstat 5' draaien voor uitvoer ?

code:

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
10  0  37624  36044  41268 380172    1    1     0     6   10    10 43 11 44  2
59  1  37624  35380  41288 380604    0    0    28  1278    0     0 82 18  0  0
 8  0  37624  35788  41300 380844    0    0     4  1514    0     0 82 18  0  0
 5  0  37624  37572  41308 381248    0    0    12  2456    0     0 79 21  0  0
60  0  37624  45624  41328 381308    0    0     4  2510    0     0 79 21  0  0
39  0  37624  50076  41332 381420    0    0     2  1422    0     0 84 16  0  0
31  0  37624  52356  41332 381648    0    0    14  1802    0     0 71 21  0  7
25  0  37624  39860  41332 382028    0    0     2  1677    0     0 82 17  0  1
 7  0  37624  38972  41348 382384    0    0    24  1894    0     0 81 19  0  0
11  0  37624  33272  41376 382988    0    0    24  4278    0     0 72 26  0  2
25  1  37624  44132  41420 382936    0    0     6  2705    0     0 79 21  0  0
30  1  37624  49132  41428 383144    0    0    14  1153    0     0 85 15  0  0
42  1  37624  47012  41440 383640    0    0    11  3017    0     0 68 23  0  9
15  0  37624  54484  41460 383964    0    0    36  1849    0     0 70 21  0  9
17  1  37624  60348  41472 384136    0    0    19  2198    0     0 81 18  0  0
28  0  37624  37056  41472 385008    0    0    33  3578    0     0 57 29  0 14
 0  2  37624  55520  41472 385212    0    0    14  2624    0     0 67 23  0 10
 2  0  37624  63836  41492 385412    0    0    10  3537    0     0 57 21  0 22
12  0  37624  67744  41520 385596    0    0     6  3398    0     0 68 28  0  4
 9  0  37624  68608  41544 385852    0    0    23  2249    0     0 77 23  0  0
58  4  37624  47776  41560 386364    0    0    11  2599    0     0 74 26  0  0
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
59  0  37624  56992  41564 386484    0    0    13  2157    0     0 78 20  0  2
10  0  37624  37248  41568 386876    0    0     2  2984    0     0 74 26  0  0
13  0  37624  51596  41588 386788    0    0     6  3673    0     0 71 29  0  0
93  2  37624  47236  41588 387132    0    0    34  2246    0     0 81 19  0  1

Sybr_E-N schreef op maandag 01 mei 2006 @ 19:59:
Wat je nog meer kunt doen is je queries optimizen, haal ze eens door Explain wie weet kun je daar nog het een en ander winnen. Daarnaast: maak je ook gebruikt van enige vorm van caching, van zowel querie resultaten als html? Hiermee kun je zowel de database ontlasten als de webserver, die dan grote delen alleen maar terug hoeft te sturen (wat sneller gaat dan continue hele pagina's dynamisch op te laten bouwen)

Door EXPLAIN heb ik ze al heen gehaald en hierbij komt naar voren dat de indexes in ieder geval hun werk goed doen.
Over dat caching verhaal: ik laat Cron een script elke x aantal minuten aanroepen die HTML code aanmaakt van de query's die die aanroept, dit zien de gebruikers dus uiteindelijk tussen de 'gewone site'.

[frickY]

Maak je gebruik van persisstent MySQL connecties? Of zijn het echt de query's zelf die de bottleneck vormen?
Sla je afbeeldingen of andere binaire data op in je tabel welke je ophaalt. welke je beter als bestand zou kunnen opslaan en alleen het pad naar het bestand opslaan?

[ Voor 102% gewijzigd door frickY op 01-05-2006 20:14 ]

[Verwijderd]

Gemiddeld 238 queries per seconde, met een relatief kleine userbase (2600 online op piekmomenten)? Daar kan waarschijnlijk wel iets aan geoptimaliseerd worden. Niet elk vergelijkbaar objectje z'n eigen data laten ophalen bijvoorbeeld, maar dit overlaten aan de list/array/collection waar die objecten in komen te staan. Of sessie/user-specifieke data niet iedere keer uit de database halen, maar opslaan in de sessie zelf.
Ook zou je system wide data die steeds nodig zijn maar niet steeds wijzigen kunnen cachen in het geheugen. Desnoods in een eigen webservice, want ik weet niet of je in PHP (neem aan dat je dat gebruikt?) zo'n system wide cache aan kunt leggen.

Overigens, het aanmaken van de juiste indexen is een vak op zich. Eerst analyseren wat de belangrijke velden in je WHERE of ORDER BY clauses zijn, en vervolgens testen welke indices het beste werken. MSSQL is bv. blij met veel enkelvoudige indexen (op 1 veld), terwijl bij InterBase compound indexen (meerdere velden tegelijkertijd) vaak veel beter performen. Hoe dat by MySQL zit weet ik niet...

[ACM]

kweenie schreef op maandag 01 mei 2006 @ 19:37:
Ik beheer een website waar je online een huisdiertje kunt opvoeden.
De site draait op een dedicated server met de volgende stats:

» 120gigabyte harddisk
» Pentium4
» 3.0ghz Processer
» 1024mb RAM Geheugen
» Fedora Linux

Draai je met een recente 2.6 kernel? Verder lijkt het er op dat je toch een behoorlijk beperkte machine hebt voor de hoeveelheid requests die je krijgt te verstouwen. Als een update financieel mogelijk is en je niet twee losse machines wil, dan zou je misschien zelfs wel naar dual dual-core opteron en 4G ram ofzo moeten kijken... Maar dat is niet bepaald een goedkope investering, dus dat je eerst de softwarekant bekijkt kan ik me goed voorstellen.
Overigens wordt een databaseserver bijna altijd blij van extra geheugen, dus je zou daar al mee kunnen beginnen.

Nu gaat dit allemaal best en is het verschrikkelijk snel, totdat het spitsuur begint en de kids uit school komen. Van 15 uur tot 20 uur is het vrijwel ondoenlijk om op de site te komen, constant knalt MySQL eruit.
Per dag zijn er 5000 nieuwe registraties en op die drukke momenten zijn er 2600 mensen tegelijk online. Er zijn per dag 1,3 miljoen pagina weergaves.

Dat zijn aardig wat requests, ik weet niet hoe zwaar ze zijn, maar toen tweakers.net dat soort aantallen haaldde hadden we geloof ik al meer en zwaardere servers...

» my.cnf diverse standaarden gebruikt, en diverse instellingen geprobeerd van 'mysql tweak up' sites.

Welke mysql en php gebruik je trouwens? Van beide is versie 5 in mijn ervaring wat sneller, vooral mysql5 zou je wel wat winst moeten geven als je dat nog niet draait.

» vermindering aantal querys door efficienter gebruik (complete site herschreven).

Hier is nog wel wat winst te halen gok ik. Bekijk welke queries er voor een pageview nodig zijn en kijk of ze niet onnodig dubbelwerk doen. Bijv twee keer in dezelfde tabel met (vrijwel) dezelfde where-clause werken maar het resultaat anders verweren of meer data dan je nodig hebt, danwel data in losse queries ophalen terwijl ze gejoined hadden kunnen worden.

» bepaalde scripts via cron draaien en html eruitgooien ipv elke gebruiker de query's laten runnen.

Probeer na te gaan hoe groot het deel van de belasting op je doos door welke pagina's komt, etc, etc. Daar moet je de performance van zien te verbeteren.

» Indexes aangemaakt.

Zoals al gezegd zegt dat nog niet dat je ook de beste indexen hebt gemaakt Sommige queries profiteren van gecombineerde indexen en sommige juist van enkelvoudige. Je zult echter zelf de queries na moeten gaan in hoeverre dat het geval is.
Let bij explain ook op het enge 'using filesort' en/of meldingen over temporary tables. In die gevallen is er nog wel winst te halen bij die query, hoewel het herschrijven en/of toevoegen van indexen tot dat niet meer nodig is behoorlijk pittig kan zijn.

17532 apache 15 0 20676 12m 8800 S 0.7 1.2 0:00.35 httpd

Je zou kunnen overwegen een lichtere webserver dan apache te draaien. Welke keuzemogelijkheden er over blijven weet ik niet, maar als je bijv apache met "Tux" combineert of zelfs compleet vervangt door een andere oplossing kom je een heel eind met het verminderen van de apache-overhead.

Van diverse mensen heb ik te horen gekregen dat ik naar een 2e server toe zal moeten zodat er 1 Database server is en 1 webserver. Dit is nu nog niet het geval.
Maar ik heb zelf zoiets van het liefste wil ik het op 1 server vooral vanwege de hoge kosten van een 2e server. En het lijkt me dat 1 server toch mogelijk moet zijn.

Bekijk de statistieken van tweakers.net es... Het kan vast wel, maar je moet wel flink moeite doen om de performance er uit te persen. Alles hangt af van de zwaarte van losse pagina's etc.

[Gomez12]

Als ik je top statistiek zie dan is het alleen mysql die vervelend zit te doen, denk eens na over een goed cache systeem zodat je mysql een stuk ontlast. Als ik jouw website zie dan denk ik dat er een paar onderdelen goed zijn voor caching.

Vb.
De poll, cache de vragen als html voor 24 uur.
Laatste nieuws, cache als html voor 15 minuten.
Nieuwste leden, cache als html voor 5 minuten.
Nieuwste Forumtopics, cache als html voor 5 minuten.
Het webpet team, cache als html voor 24 uur.
Forum, cache als html indien topic ouder is dan 1 dag, met cache invalidation indien nieuw bericht.

Oftewel ontlast je mysql zoveel mogelijk ( en kijk ook naar indexen / normalisering ). In jouw top-voorbeeld zit apache/php uit zijn neus te eten terwijl mysql al het werk doet.
Cache betekent niet gelijk crontabs, maar een user-request kan net zo goed de cache invalideren ( beter in mijn optiek ), de crontab kan je net voor de rush zetten.

Met 1,3 miljoen pageviews ruim 20 miljoen queries ( 859 k x 24 ) trekken is niet echt handig als je al last hebt van een trage site.

Dus kijk of je wel echt alle queries nodig hebt, want ik kom op een gemiddelde van 18 queries per pageview uit...

Kijk gewoon eens naar het simpele feit wat er zich moet verversen als er iemand op f5 drukt, en waar is de kans groot van dat het nog gelijk is ( dan cachen ).

Zit net eventjes compleet de site te bekijken, maar als ik het goed begrijp dan gaat het voornamelijk om de community en de spelletjes. Controleer eens bij de spelletjes wat deze doen, volgens mij hoeft elk spel namelijk maar 2 querys te doen : 1 keer punten ervanaf halen als iemand meedoet met een spel, en een keer punten erbij doen als iemand gewonnen heeft. De rest van het spel kan compleet in javascript / php plaatsvinden zonder mysql ertussen.
Online leden lijst vind ik ook zo'n ding wat ikzelf in dit geval compleet in xml / flatfile zou doen. Dan heeft je php maar wat meer werk, nogmaals ontlast je mysql...

Kijk trouwens ook eens goed naar je site, voorbeeldje wat ik nu zie is : je online.php wordt gegenereerd om de 5 minuten, maar in je menu heb je een knopje online staan met een getal ernaast wat elke refresh verandert terwijl dit helemaal geen enkel nut heeft als ik erop klik en ik zie een 5 minuten oude online page. Dus cache dit getal ook even voor 5 minuten.

[ Voor 28% gewijzigd door Gomez12 op 01-05-2006 21:14 ]

[whoami]

Wat JHS en Afterlife zeggen is wel waar; het is aan de ene kant moeilijk om er iets zinnigs over te zeggen, maar het aantal queries die je uitvoert doet wel vermoeden dat er een en ander kan geoptimaliseerd worden. Ipv 100 kleine queries uit te voeren, kan je misschien alle data met 1 of 2 queries uitvoeren. (Ik zeg maar iets, want het is onmogelijk om met de huidige info nu goede uitspraken te doen).

Afterlife:
MSSQL is bv. blij met veel enkelvoudige indexen (op 1 veld)

Vanwaar haal je dat ? Volgens mij hangt het zowiezo van de situatie en de query af en niet zozeer van het dbms, en hoe unieker hoe beter.
An index on a column can often be created different ways, some of which are more optimal that others. What this means that just because you create a useful index on a column doesn't mean that it automatically is the optimum version of that index. It is quite possible that a different variation of the same index is faster.

The most obvious example of this is that an index can be a clustered or non-clustered. Another example of how an index is created that can affect its performance is the FILLFACTOR and PAD_INDEX settings used to create it. Also, whether the index is also a composite index or not (and what columns it contains) can affect an index's performance.

[Verwijderd]

whoami schreef op maandag 01 mei 2006 @ 22:36:
Vanwaar haal je dat ? Volgens mij hangt het zowiezo van de situatie en de query af en niet zozeer van het dbms, en hoe unieker hoe beter.

Uit de (mijn/onze) praktijk. We ondersteunen voor dezelfde software zowel MSSQL als Interbase, en hebben 't voor beide databases moeten optimaliseren. Zo gauw je meer dan 1 composite index op 1 tabel in MSSQL zet, is 't vaak maar gokken welke index 'ie kiest, met soms onnodige slechte performance (als in: met de gekozen index was een 'fetch all' bijna net zo efficient geweest, terwijl die andere index handiger was). Wanneer die index werd uitgesplitst in meerdere simpele indexen, snapte MSSQL 't een stuk beter.
Diezelfde techniek (composite indexen opdelen in simpele indexen) hebben we vervolgens geprobeerd toe te passen op Interbase, en binnen een dag hadden we de klant die proefkonijn was (hotel met 500+ kamers en 100+ zalen) aan de telefoon hangen met de klacht dat de boel niet meer vooruit te branden was.

Voor Interbase ga ik sindsdien eerder voor composite indexen, en voor MSSQL voor de simpele.

[kweenie]

frickY schreef op maandag 01 mei 2006 @ 20:09:
Maak je gebruik van persisstent MySQL connecties? Of zijn het echt de query's zelf die de bottleneck vormen?
Sla je afbeeldingen of andere binaire data op in je tabel welke je ophaalt. welke je beter als bestand zou kunnen opslaan en alleen het pad naar het bestand opslaan?

Nee ik maak geen gebruik van persisstent connecties.
De afbeeldingen worden opgeslagen in een map op de server, dus niet in MySQL.

Verwijderd schreef op maandag 01 mei 2006 @ 20:16:
Of sessie/user-specifieke data niet iedere keer uit de database halen, maar opslaan in de sessie zelf.
Ook zou je system wide data die steeds nodig zijn maar niet steeds wijzigen kunnen cachen in het geheugen. Desnoods in een eigen webservice, want ik weet niet of je in PHP (neem aan dat je dat gebruikt?) zo'n system wide cache aan kunt leggen.

..

Er wordt aan de hand van een cookie een sessie aangemaakt en die zorgt er dus voor dat er geen check-query's meer nodig zijn, dat heeft in het begin geholpen maar met de huidige aantallen bezoekers helpt het niet meer

ACM schreef op maandag 01 mei 2006 @ 20:54:

Draai je met een recente 2.6 kernel? Verder lijkt het er op dat je toch een behoorlijk beperkte machine hebt voor de hoeveelheid requests die je krijgt te verstouwen. Als een update financieel mogelijk is en je niet twee losse machines wil, dan zou je misschien zelfs wel naar dual dual-core opteron en 4G ram ofzo moeten kijken... Maar dat is niet bepaald een goedkope investering, dus dat je eerst de softwarekant bekijkt kan ik me goed voorstellen.
Overigens wordt een databaseserver bijna altijd blij van extra geheugen, dus je zou daar al mee kunnen beginnen.

Ik draai idd met een recente kernel.
Dat geheugen zou een optie kunnen zijn, dualcore is idd flink duur

Welke mysql en php gebruik je trouwens? Van beide is versie 5 in mijn ervaring wat sneller, vooral mysql5 zou je wel wat winst moeten geven als je dat nog niet draait.

MySQL 4.1.14 en ook nog geen PHP 5.

Gomez12 schreef op maandag 01 mei 2006 @ 20:55:
Als ik je top statistiek zie dan is het alleen mysql die vervelend zit te doen, denk eens na over een goed cache systeem zodat je mysql een stuk ontlast. Als ik jouw website zie dan denk ik dat er een paar onderdelen goed zijn voor caching.

Vb.
De poll, cache de vragen als html voor 24 uur.
Laatste nieuws, cache als html voor 15 minuten.
Nieuwste leden, cache als html voor 5 minuten.
Nieuwste Forumtopics, cache als html voor 5 minuten.
Het webpet team, cache als html voor 24 uur.
Forum, cache als html indien topic ouder is dan 1 dag, met cache invalidation indien nieuw bericht.

Laatste nieuws, nieuwste leden, nieuwste forumtopics & webpet team worden elke 2 minuten aangemaakt. (die laatste vooral omdat er ook een online check in zit).
De poll wordt nog wel realtime aangemaakt en zou dus idd verbeterd kunnen worden in dat opzicht.
Dat forum zou idd ook best een optie kunnen zijn.

Zit net eventjes compleet de site te bekijken, maar als ik het goed begrijp dan gaat het voornamelijk om de community en de spelletjes. Controleer eens bij de spelletjes wat deze doen, volgens mij hoeft elk spel namelijk maar 2 querys te doen : 1 keer punten ervanaf halen als iemand meedoet met een spel, en een keer punten erbij doen als iemand gewonnen heeft. De rest van het spel kan compleet in javascript / php plaatsvinden zonder mysql ertussen.

De spelletjes hebben 2 query's: 1 om te checken of je genoeg geld hebt en/of je beestje nog wel leeft.
En 1 op te updaten.

Kijk trouwens ook eens goed naar je site, voorbeeldje wat ik nu zie is : je online.php wordt gegenereerd om de 5 minuten, maar in je menu heb je een knopje online staan met een getal ernaast wat elke refresh verandert terwijl dit helemaal geen enkel nut heeft als ik erop klik en ik zie een 5 minuten oude online page. Dus cache dit getal ook even voor 5 minuten.

Daar heb je gewoon volkomen gelijk in

Allen tot nu toe: harstikke bedankt voor de reacties!
Ik zal het een en ander gaan uitproberen en blijf vooral komen met de tips

[YopY]

Ik zou als ik jou was in ieder geval bedenken om naar MySQL 5.x over te stappen, in dit artikel staat een vergelijking van het hoe en wat daarvan. Kan volgens dat artikel tot wel 40% schelen, zo niet meer.

[Gomez12]

YopY schreef op maandag 01 mei 2006 @ 23:25:
Ik zou als ik jou was in ieder geval bedenken om naar MySQL 5.x over te stappen, in dit artikel staat een vergelijking van het hoe en wat daarvan. Kan volgens dat artikel tot wel 40% schelen, zo niet meer.

Ik zou als ik jou was eerst het topic lezen voor je een reactie geeft

ACM zegt hetzelfde alleen dan iets voorzichtiger ( het is niet altijd makkelijk om eventjes snel mysql versies te gaan veranderen ), en acm heeft zelfs nog meegeholpen aan het schrijven van de review waar jij naar verwijst...

[kweenie]

Okay allemaal harstikke bedankt, van het weekend als ik wat meer tijd heb zal ik is het een en ander gaan uitproberen

[Sendy]

Als je naast de database ook redelijk veel files leest moet je het filesystem mounten met -o noatime. Hierdoor wordt de laatste access tijd niet naar de inode geschreven.

[Olaf van der Spek]

Een system-wide cache of business layer/service zou waarschijnlijk een stuk helpen.

Maar heb je dingen als de slow log en mytop al geprobeerd?

[Hydra]

Die "who's online" functie, schrijft deze iedere keer als een user iets uitvoert iets naar de DB? Misschien een idee dat, als je toch die pagina's 1 keer per 2 minuten genereerd, dit ook minder frequent te updaten?

[kweenie]

Slowlog file heb ik geprobeerd maar daar kwam niet zoveel nuttigs uit.

De who's online wordt dmv sessies elke 5 minuten gecheckt of de gebruiker er nog is.
Ook de pagina zelf wordt elke 5 minuten aangemaakt.

Ik heb wel gisteren 2GB extra geheugen besteld, dus hoop dat als dat erin zit het ook merkbaar is

[kweenie]

Okay er zit nu dus 3GB aan geheugen in de server. Nu had ik wel verwacht dat het iets zou schelen, maar het helpt dus geen fluit

Zijn er instellingen die ik kan aanpassen in my.cnf van MySQL waardoor het wel kan schelen?

[Olaf van der Spek]

kweenie schreef op donderdag 18 mei 2006 @ 16:01:
Okay er zit nu dus 3GB aan geheugen in de server. Nu had ik wel verwacht dat het iets zou schelen, maar het helpt dus geen fluit

Zijn er instellingen die ik kan aanpassen in my.cnf van MySQL waardoor het wel kan schelen?

Ja. Buffer en cache sizes enzo.
Heb je al eens gekeken naar show status (en mytop)?

[kweenie]

Voor degene die het iets zegt, ik heb MRTG draaien.


Iemand die er naar zou willen kijken en er commentaar op wil geven?
Waar zit de bottleneck als je zo kijkt? Wat kan ik (makkelijk) nog verbeteren?

[ Voor 5% gewijzigd door kweenie op 02-01-2008 13:49 ]

[Creepy]

kweenie schreef op maandag 22 mei 2006 @ 17:36:
Voor degene die het iets zegt, ik heb MRTG draaien.

http://www.webpet.nl/mrtg

Iemand die er naar zou willen kijken en er commentaar op wil geven?
Waar zit de bottleneck als je zo kijkt? Wat kan ik (makkelijk) nog verbeteren?

Zo werkt het hier niet he
Wat denk je zelf waar het probleem zit? Wat heb je nu zelf al geprobeerd a.d.h.v. deze statistieken? We zitten hier niet om de boel maar even voor je op te lossen natuurlijk

[moto-moi]

Je gaat me toch niet vertellen dat je zelf daar geen onwijs grote fout ziet he ?

[ Voor 4% gewijzigd door moto-moi op 22-05-2006 19:46 ]

[Juup]

Nou ben ik wel nieuwsgierig. Hoe kan dat dan, moto-moi? Is er een of andere limiet op het geheugengebruik?

[moto-moi]

Je geeft in je configfile van mysql aan hoeveel geheugen hij mag gebruiken. Vaak is het namelijk niet 'handig' om al het geheugen te laten gebruiken, je wilt altijd iets ademruimte hebben voor cronjobs e.d. Maar als je 3 gb intern geheugen hebt wil je wel iets meer dan 630MB gebruiken, dat wil je al met 1024MB lijkt me, de rest wordt gebruikt voor filecaching, en dat is nou niet bepaald erg nodig.

[DJ Buzzz]

Heb je ook al gecontroleerd of je kernel wel >1G geheugen support op dit moment? Ook zoiets typisch dat snel vergeten wordt in een dergelijke situatie...

[ACM]

moto-moi schreef op maandag 29 mei 2006 @ 11:53:
Maar als je 3 gb intern geheugen hebt wil je wel iets meer dan 630MB gebruiken, dat wil je al met 1024MB lijkt me, de rest wordt gebruikt voor filecaching, en dat is nou niet bepaald erg nodig.

Als ik de uitleg goed begreep is het hele LAMP-setje op een server geplaatst en in dat geval wil je, lijkt me, wel wat meer ruimte vrijhouden voor andere zaken dan MySQL.
Overigens is zeker met MyISAM tabellen het hebben van ruimte voor file caching ook niet verkeerd.

Maar meer dan 630MB mag zeker wel, maar dus niet 2.5G ofzo lijkt me, eerder richting de 1.5G om eens mee te beginnen.

[ Voor 7% gewijzigd door ACM op 30-05-2006 07:26 ]

[Olaf van der Spek]

ACM schreef op dinsdag 30 mei 2006 @ 07:25:
[...]

Als ik de uitleg goed begreep is het hele LAMP-setje op een server geplaatst en in dat geval wil je, lijkt me, wel wat meer ruimte vrijhouden voor andere zaken dan MySQL.

Maar die 630 mbyte is al het totale geheugengebruik, inclusief andere zaken dan MySQL.