PDA

Bekijk Volledige Versie : CentOS: waar zit de load bottleneck



marcel5
04/03/09, 16:32
Ik probeer inzicht te krijgen waar in mijn server de bottleneck zit wat betreft de performance. De load stijgt soms tot boven de 1.0 terwijl de CPUs and harddisk volgens mij voor het grootste deel idle zijn. In de attachment zit een screenshot van 'top' en 'iostat'.

Mijn vraag is: waarom is de load .78 terwijl de CPU 85% idle is en de harddisk een lage iowait aangeeft? Ik zou denken dat dan de load lager zou zijn. Of zit de bottleneck bijvoorbeeld in het geheugen?

De server draait alleen Lighttpd, php-cgi (+XCache) en Mysql.

WeServIT
04/03/09, 16:48
De uptime van de server is 70 dagen, je ziet ook al dat de server wat aan het swappen is. Er is nog 3 gb cached dus er is geen ram te kort, waarschijnlijk is er een keer een piek geweest waardoor er meer geheugen nodig was.

Je kunt de commands:

swapoff -a en daarna swapon -a proberen.

Ik zie overigens het nut er niet van in om je druk te maken over een load van .78, dit is helemaal niet hoog.

mikeh
04/03/09, 16:51
Als je niet meer op je doos komt via ssh, swap + geheugen 100% gebruikt word, je een load van 500+ ziet dan mag je je toch enigsinds afvragen waar het door komt :P

WeServIT
04/03/09, 16:55
Als je niet meer op je doos komt via ssh, swap + geheugen 100% gebruikt word, je een load van 500+ ziet dan mag je je toch enigsinds afvragen waar het door komt :P

Ja ok, maar dat is in dit geval niet zo.
Misschien handig om te vermelden wat je in de server hebt zitten qua hardware, dan kun je vaak al zien wat eventueel de bottleneck zou kunnen zijn.

marcel5
04/03/09, 17:12
Ik maak me ook niet echt druk hoor, maar ik moet met het oog op de toekomst er toch wel iets aan gaan doen. Een paar maanden geleden was de load gemiddeld 0.4 en nu zit ie al op 0.8 (stijgende bezoekersaantallen). Om mijn site een beetje soepel te houden wil ik de load toch zo laag mogelijk houden.

De server is een Intel SR2500 met de volgende componenten:

Xeon E5420 (Quoadcore 2,5Ghz, 12MB cache)
Intel S5000PAL mainboard
8GB memory (4 reepjes van 2 GB)
LSI MegaRaid controller

2 x 147GB 15k SAS schijven in RAID 1 (512MB IO cache)
1 x 1TB SATA schijf (voor snapshots)

Uiteraard ga ik eerst kijken of ik mijn code nog iets kan optimizen, maar ik zou ook graag weten of ik qua hardware iets kan toevoegen.

WeServIT
04/03/09, 17:26
Ik maak me ook niet echt druk hoor, maar ik moet met het oog op de toekomst er toch wel iets aan gaan doen. Een paar maanden geleden was de load gemiddeld 0.4 en nu zit ie al op 0.8 (stijgende bezoekersaantallen). Om mijn site een beetje soepel te houden wil ik de load toch zo laag mogelijk houden.

Uiteraard ga ik eerst kijken of ik mijn code nog iets kan optimizen, maar ik zou ook graag weten of ik qua hardware iets kan toevoegen.

Een server met een load van bijv. 10 kan nog goed lopen, je moet zelf gewoon kijken wanneer je merkt website langzaam wordt, want ik neem aan dat hij nu gewoon soepel draait?

marcel5
04/03/09, 17:34
De site loopt nog goed, maar als de load boven de 1.5 komt dan merk je dat de site iets langzamer reageert. Normaal verschijnt de pagina direct, maar in de piekuren gaat het net een fractie langzamer.

De site is een image gallery waarbij users gemiddeld zo'n 15 paginas per bezoek bekijken. De user browsen dus veel voordat ze vinden wat ze zoeken, als de site niet soepel reageert is dat best storend.

Als ik zou weten dat bijv. extra geheugen, processor of overstap naar RAID 10 zou schelen dan zou ik dat doen. Alleen zie ik dus niet waar de bottleneck zit omdat zowel CPU als IO niet echt overbelast zijn.

rensariens
04/03/09, 17:38
Pas boven de 4.0 gaat er merkbare vertraging optreden bij een quad core (indien we over webhosting praten).

WeServIT
04/03/09, 17:51
Dan raad ik je aan om over te gaan op RAID 10, geheugen zou je ook kunnen uitbreiden, de processor is zeker niet de bottleneck.

Tim.Bracquez
04/03/09, 19:45
Nu ligt het vermoedelijk aan mij, maar lighttpd vind ik niet zo 'light' als ze beweren, maar toch miste ik extra performance in cpu's die gemakkelijk meerdere threads aankunnen.

Zelf zou ik voor nginx eens gaan zitten(testen op andere poort/IP?) en kijken wat die doet, eventueel php in fast-cgi draaien kan ook wel eens extra performance geven.

http://www.wikivs.com/wiki/Lighttpd_vs_nginx
Static content: http://superjared.com/entry/benching-lighttpd-vs-nginx-static-files/
... google er maar naar.

Tegen een bestaande config kun je moeilijk altijd hardware geweld tegenaan gooien...

Het hangt uiteraard allemaal af hoe de applicatie allemaal in elkaar zit en wat de mogelijkheden zijn om dit softwarematig op te lossen. Maar het is raadzaam dat eens goed te controleren. Bespaard je hardware kosten, blijven upgraden is niet altijd mogelijk.

EDIT: zelf zéér nare effecten van performance gevonden van lighttpd, een geoptimaliseerde apache2 bleek in dat geval zelfs sneller te lopen...

marcel5
04/03/09, 20:03
Dan raad ik je aan om over te gaan op RAID 10, geheugen zou je ook kunnen uitbreiden, de processor is zeker niet de bottleneck.
Maar 'iostat' zegt dat de IOWait heel laag is, dan is de doorvoer van en naar de harde schijf toch geen bottleneck?


Nu ligt het vermoedelijk aan mij, maar lighttpd vind ik niet zo 'light' als ze beweren, maar toch miste ik extra performance in cpu's die gemakkelijk meerdere threads aankunnen.

Zelf zéér nare effecten van performance gevonden van lighttpd, een geoptimaliseerde apache2 bleek in dat geval zelfs sneller te lopen...

Dat is grappig, ik ben juist heel tevreden over Lighttpd.

Lighttpd is zeker een factor 2 sneller dan de Apache die ik gebruikte (default install, maar wel goed geconfigureerd). Ook de stabiliteit is prima, ik draai al meer dan 3 maanden zonder enige downtime.

Mijn site bestaat voornamelijk uit thumbnails (3-15kb), misschien dat dat er iets mee te maken heeft.

PHP draait al in fast-cgi, en ik gebruik een PHP Opcode cacher (XCache) die ook ongeveer 20% snelheids winst geeft.

Tim.Bracquez
04/03/09, 20:07
Lighttpd is zeker een factor 2 sneller dan de Apache die ik gebruikte (default install, maar wel goed geconfigureerd). Ook de stabiliteit is prima, ik draai al meer dan 3 maanden zonder enige downtime.

Klopt wat je zegt bij de default install is dit alles wel veel sneller. Maar apache kan ontdaan worden van vele modules en van tweaks voorzien worden. Zelf ben ik meer voor nginx voor het dedicated draaien van (zware) sites omdat deze nog beter uitkwam in tests (nignx vs apache vs lighttpd). Uiteraard hangt het ook van de tweaks af...

Mikey
04/03/09, 20:10
Nu ligt het vermoedelijk aan mij, maar lighttpd vind ik niet zo 'light' als ze beweren, maar toch miste ik extra performance in cpu's die gemakkelijk meerdere threads aankunnen.

Zelf zou ik voor nginx eens gaan zitten(testen op andere poort/IP?) en kijken wat die doet, eventueel php in fast-cgi draaien kan ook wel eens extra performance geven.

http://www.wikivs.com/wiki/Lighttpd_vs_nginx
Static content: http://superjared.com/entry/benching-lighttpd-vs-nginx-static-files/
... google er maar naar.

Tegen een bestaande config kun je moeilijk altijd hardware geweld tegenaan gooien...

Het hangt uiteraard allemaal af hoe de applicatie allemaal in elkaar zit en wat de mogelijkheden zijn om dit softwarematig op te lossen. Maar het is raadzaam dat eens goed te controleren. Bespaard je hardware kosten, blijven upgraden is niet altijd mogelijk.

EDIT: zelf zéér nare effecten van performance gevonden van lighttpd, een geoptimaliseerde apache2 bleek in dat geval zelfs sneller te lopen...

Ik haak eerst even in op de benchmark link die je poste, de gemaakte conclusie is een beetje krom, en veel te kort door de bocht. Twee files testen en daarmee maar een conclusie trekken... een groot noemenswaardig nadeel nginx kan zelf geen processen extra spawnen, dat terwijl ze misschien wel nodig zijn.

Kortom lighttpd lekker laten staan, ik zou zelf meer in de hoek zoeken van caching en query optimalisatie, verder zet bepaalde functies op de website tijdelijk uit (automatisch) als je load hoger dan een bepaald niveau komt. En begin vanaf dat moment automatisch debug informatie te verzamelen. Ik gok niet dat het in je hardware configuratie zit maar eerder op een programmeer vlak. Een load van 500, jouw logfiles zouden hier ook uitsluitsel mee kunnen geven, weet niet of je tevens mail host op deze machine met spamassasin, als je geen max aantal childs op geeft, kan bij een spamrun dat ook een huge load veroorzaken. Er zijn 1001 trukjes om dit op te sporen :)

Wij kunnen niet anders dan lof spreken over lighttpd, mede doordat je andere machines in kan zetten door enkel php te processen en deze gewoon in de config op te nemen. Nog niet te spreken over de automatisch failover etc etc.



Pas boven de 4.0 gaat er merkbare vertraging optreden bij een quad core (indien we over webhosting praten).
Onzin, dit is per machine, applicatie of opbouw anders. Ik kan je namelijk voorbeelden geven waarbij de load structureel hoog is, maar nog steeds flitsende websites levert.

Tim.Bracquez
04/03/09, 20:17
Ik haak eerst even in op de benchmark link die je poste, de gemaakte conclusie is een beetje krom, en veel te kort door de bocht. Twee files testen en daarmee maar een conclusie trekken...
zoals ik zei google, er staan uitgebreide test online die voor véél content testen en uiteindelijk komt nginx er veel beter uit in het serveren van pages voor vele hits... het hangt uiteraard van je content af


een groot noemenswaardig nadeel nginx kan zelf geen processen extra spawnen, dat terwijl ze misschien wel nodig zijn.

één groeiend lighttpd process zorgt ook voor een leuk effect op de performance... zeker als die op sommige configuraties ook nog eens tegen een memory leak aan loopt

Mikey
04/03/09, 22:48
één groeiend lighttpd process zorgt ook voor een leuk effect op de performance... zeker als die op sommige configuraties ook nog eens tegen een memory leak aan loopt

Ik mis hier denk ik iets, het is niet lighttpd die groeit, maar de bijhorende cgi processen :)

Verder kijk eens naar: http://redmine.lighttpd.net/wiki/lighttpd/Docs:ModFastCGI zie nginx dit nog niet nadoen, of ik heb de plank gemist :thumbup:

eigenlijk weinig toe te voegen voor probl. van ts ;)

marcel5
04/03/09, 22:52
eigenlijk weinig toe te voegen voor probl. van ts ;)

Geen probleem, ik sta aan de kant met mijn Lightttpd vlaggetje te zwaaien. Go Lighty! :thumbup:

Mikey
04/03/09, 22:58
ik denk ook niet dat daar het probleem zit, maar voornamelijk in de hoeveelheid bezoekers en de bijhorende cgi processen, kun je bepaalde delen van de website die weinig tot niet veranderen niet cached maken, hiermee haal je je aantal cgi requests omlaag en waarschijnlijk ook de sql query's.

marcel5
06/03/09, 12:04
Het grootste deel van mijn website is statisch. Mijn php script cached paginas in Mysql, wat op zich best snel is (of misschien toch niet aangezien mijn load?).

Ik zal eens kijken naar een oplossing die paginas buiten PHP om cached, want het is inderdaad een beetje zonde om voor een pagina die gecached is een php process te starten en een Mysql query te moeten doen.

Heeft iemand ervaring met Modcache ism Lighttpd?

http://www.linux.com.cn/modcache/

marcel5
06/04/09, 15:02
Kleine update: de bottleneck lag toch ook bij de harddisks, ondanks de lage "IOWait."

Ik heb ivm ruimtegebrek twee schijven toegevoegd en mijn data op een aparte RAID1 array gezet, de load is nu zo'n 30% lager.