[PHP / MySQL] Hoge server load - wat nu ?

[CT]

Ik loop al een tijdje een 'duidelijk' antwoord te zoeken maar dat wil niet helemaal lukken.
Op dit moment hebben we een SQL server en een PHP/Apache server. Beide communicren met elkaar over het netwerk en beide zijn het P4 2.4GHZ systemen.
Nu krijgen we vooral in de avond uren gigantisch veel traffic, elke seconde wel een pageview.
De content is elke view anders per gebruiker, dus caching is ook geen optie.

De load (zoals in 'top' vermeld) van de mysql server piekt op een load van 14 en die van de php rond de 200. (Dan is er dus een timout bij een request en dat resulteert in dat iedereen wegvalt en de piek opnieuw opbouwt).

Nu snap ik weinig van vmstat en kan ik er ook weinig info over vinden hoe je dit precies moet interpeteren. Hier enige voorbeelden van momenten dat de load hoog is op beide servers:

PHP server:

code:

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
14  0 398648 165364 111968 466428    5    4     6     6    7     2 36  8 55  0
 7  0 398648 174152 111968 466428    0    0     0     0 11146  8449 65 35  0  0
 7  0 398648 173704 111968 466432    0    0     0     0 8129  6067 69 31  0  0
 7  0 398648 175296 111968 466436    0    0     0     0 11263  8541 65 35  0  0
 6  0 398648 174052 111976 466440    0    0     0   775 9732  7979 69 31  0  0
 9  0 398648 172380 111976 466440    0    0     0     0 9977  7543 74 26  0  0
 8  0 398648 159676 111976 466448    0    0     3     0 7230  4983 74 26  0  0
 8  0 398648 158696 111976 466452    0    0     0     0 8331  5703 68 32  0  0
 9  2 398648 157616 111980 466448    0    0     0   617 6497  5049 73 27  0  0
 7  0 398648 158460 111980 466452    0    0     0     1 8561  6840 77 23  0  0

SQL server:

code:

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
10  2    860  81432  86604 649868    0    0     5     9    6     3 33  8 59  0
 0  0    860  84160  86604 649880    0    0     0  1304 10774  9155 55 29 16  0
 9  0    860  83972  86612 649880    0    0     0   140 9734  8470 54 12 34  0
 4  0    860  84360  86612 649880    0    0     0    60 13467 10887 59 26 15  0
 2  0    860  84356  86612 649880    0    0     0     0 11546 10145 45 29 27  0
 4  0    860  84568  86612 649884    0    0     0    68 6994  6143 48 13 40  0
 3  0    860  84544  86612 649884    0    0     0     0 9935  9093 57 16 27  0
 2  0    860  84084  86612 649884    0    0     0   124 8989  8138 38 21 42  0
 6  0    860  83576  86612 649884    0    0     0     0 10062  9084 53 22 25  0
 4  0    860  83576  86612 649884    0    0     0     0 12478 10801 71 16 13  0

Mijn vragen zijn concreet:
Is de i/o hier ook de bottleneck? Of alleen de CPU?
Als we van die 2 servers alles, sql en php/apache op 1 hele dikke server gooien (dual xeon bijv.) helpt dat? Of moet hier duidelijk gezocht worden naar een uitgebreidere oplossing (3 servers, load balancing etc..) ?

Bedenk wel dat we op langere termijn overgaan op een java framework, en het hele php achterlaten.
En dat de php-code al vele malen geoptimaliseerd is. (De load was nog veel hoger).

Dus de oplossing moet 'nu' direct werken en het platform nog even dragen.
Zelf zouden we kiezen voor 1 hele dikke server en daar alles op draaien.
Omdat ik de indruk heb dat de i/o op sql server de boosdoender is en de cpu op php server. Als je dat combineert en deelt door 2 (omdat alles sneller is) zou de load nog maar 50 moeten zijn op piek momenten ? Is dit zo, of leert de ervaring dat een php/mysql server die veel load genereert niet meer te redden is?

[TimDJ]

tsja ik weet niet of een dual xeon veel beter is dan een tweede server, maar zou het ipv de io niet het netwerk kunnen zijn die zorgt voor een hoge load. Al je database verkeer moet natuurlijk van de ene naar de andere machine getransporteerd worden.

[CT]

Ja maar 'load' zou toch eerder betekenen dat de server de data niet optijd meer kan doorvoeren. En de CPU staat in vmstat hoog, en niet de io waiting time (eventueel van het netwerk).
Dus het, ik neem aan 100mbit of 1000mbit netwerk, dat intern ligt, snel genoeg is voor een serialize string met wat info.De query zelf en het inpakken van de query kost denk ik meer tijd.

Dus juist door de zaken weer op 1 server te zetten, zou kunnen schelen in het serialize verhaal (omdat de php code direct met de db kan praten).

Maar zal dan ook de load afnemen? Dat is de grote vraag

[crisp]

Ik zou toch eerst eens een code-analyze doen om te kijken waar de bottlenecks nu precies zitten. Te denken valt aan parsetime, hoeveelheid queries en de executietijden van die queries. 3600 views per uur is echt niet veel (de Tnet frontpage doet 50x zoveel op drukke momenten)...

[CT]

crisp schreef op donderdag 01 december 2005 @ 13:58:
Ik zou toch eerst eens een code-analyze doen om te kijken waar de bottlenecks nu precies zitten. Te denken valt aan parsetime, hoeveelheid queries en de executietijden van die queries. 3600 views per uur is echt niet veel (de Tnet frontpage doet 50x zoveel op drukke momenten)...

De code is al uitvoerig geanalyseerd en de reden dat het opnieuw gemaakt wordt in een ander platform komt omdat de code gewoon niet beter kan (in zijn huidige vorm dan). Queries zijn ook al enorm aangepast.

Dus eigenlijk is de vraag min of meer, gaat een dikkere server helpen, of niet?
Ik kan namelijk bar weinig succesverhalen vinden van mensen die een soortgelijke oplossing wilde toepassen. vaak werkte caching al voor hun.. (wat voor ons in dit platform niet toepasbaar is op een kort termijn, terwijl het verhuizen naar een dikkere server wel kort te realiseren is)

[Vuurvlieg]

Zo te zien maxed op je php server de cpu in ieder geval uit (onder cpu de id (idle) kolom), een snellere of eventueel 2 (snellere) processoren helpen hier dus zeker. Je SQL server heeft nog idletime over. Afhankelijk van hoeveel geheugen je in je servers hebt zitten kan het ook helpen om je geheugen te vergroten.

Mijn oplossing zou zijn om een snellere cpu (de snelste die beschikbaar is voor je socket) te kopen en extra geheugen (en apache/php/mysql hiervoor verder te optimaliseren) en te kijken wat dit met de load doet.

[ Voor 5% gewijzigd door Vuurvlieg op 01-12-2005 16:57 ]

[kmf]

hoge load wordt heel vaak veroorzaakt door een paar heftige queries die de hele db locken waar php weer op moet wachten. En dan wordt het zo'n lekkere sneeuwbaleffect. Wat staat er in de proceslijst van mysql op zo'n hoge load moment dan?
Zeker als de geheugen een beetje vol raakt en mysql fijn gaat swappen of tmp-tables gaat maken...

puur php vreet meestal echt niet zoveel cpu. Je moet niet een paar duizend keer door een paar honderd array's loopen, maar toch..

Oh, en ja, een flinke server met een hoop geheugen zal veel uithalen.
even ter vergelijking. recentelijk moest ik mijn site even onderbrengen op een P4 3Ghz 1GB-ram server. Load gemiddeld tot 20 en dat terwijl ik alle resource hogs al uitgezet had. En dat allemaal omdat mysql het niet meer trok met 30 queries per seconde.
Gooi ik die site eindelijk weer op mijn opteron, is de load weer netjes onder de 2 gemiddeld. Met alle resource hogs weer aan.

[ Voor 34% gewijzigd door kmf op 10-12-2005 00:30 ]

[CyBeR]

Een dikkere server gaat altijd helpen, evenals extra servers met load balancing (en da's mits goed geimplementeerd ook goed voor je availability, btw). Maar kijk voor je php server eens naar eAccelerator. Dat helpt bij mij de load al iets omlaag te houden door flink wat te cachen. Zo hoeven je scripts niet steeds opnieuw geparsed te worden.

[Verwijderd]

CT schreef op donderdag 01 december 2005 @ 14:09:
[...]


De code is al uitvoerig geanalyseerd en de reden dat het opnieuw gemaakt wordt in een ander platform komt omdat de code gewoon niet beter kan (in zijn huidige vorm dan). Queries zijn ook al enorm aangepast.

Als je de code al geanalyseerd hebt dan weet je toch precies welke PHP pagina's met welke SQL queries de load veroorzaken? Je zou dan ook moeten weten of het probleem op de mySQL server zit, de PHP code of de netwerkverbinding. Dus ik begrijp je situatie niet helemaal, je hebt je code geanalyseerd maar kan daar geen zinnige conclusie uit trekken? En wij moeten het zonder de code te kennen wel weten? Zonder zaken als gegevens over wat het probleem is, valt er weinig zinnigs te zeggen.

Maar in eerste instantie ga ik er niet vanuit dat je netwerkverbinding het probleem is. Je stuurt tenslotte enkel een query (vrij korte string) heen en krijgt wat resultaten terug (zullen ook geen duizenden rijen zijn per query). Dat mag op een apart 100 of 1000mbit netwerk eigenlijk geen probleem zijn. (snelheid minimaal 10 megabyte per seconde, dus (even simpel denkend) in jou geval heeft het netwerk ruimte om 10 MB per pagina over te pompen. Dat zou echt voldoende moeten zijn)

Dan blijft de overhead voor het serializeren van het netwerk verkeer over maar dat staat natuurlijk niet in verhouding tot de rest van de applicatie. Het combineren van de MySQL server en PHP server zal dus weinig winst opleveren. Tuurlijk, een dual cpu oplossing met dual core 2.8GHz cpus en een sloot geheugen zal het beter doen dan je 2 huidige systeempjes, maar je lost er geen structurele problemen mee op en je weet nog niet waar je probleem zit. En wat doe je als je site nog vaker bezocht wordt? Zet je dan een 4weg Xeon neer? Localiseer eerst het probleem en neem dan pas beslissingen over hoe je het op gaat lossen.

[Gurbe de n00b]

Hoeveel ram heb je er nou in ?
Ik denk dat belangerijk is, vooral in de MySQL server.
En eventueel de PHP server wat omhoog pompen met een wat krachtigere procressor.