Onderwerp: CentOS: waar zit de load bottleneck

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.

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.

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

Oorspronkelijk geplaatst door mikeh

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.

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.

Oorspronkelijk geplaatst door marcel5

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?

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.

Pas boven de 4.0 gaat er merkbare vertraging optreden bij een quad core (indien we over webhosting praten).

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.

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...-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...

Oorspronkelijk geplaatst door R.Vos

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?

Oorspronkelijk geplaatst door Tim.Bracquez

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.

Oorspronkelijk geplaatst door marcel5

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...

Oorspronkelijk geplaatst door Tim.Bracquez

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...-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.

Oorspronkelijk geplaatst door rensariens

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.

Oorspronkelijk geplaatst door Mikey

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

Oorspronkelijk geplaatst door Mikey

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

Oorspronkelijk geplaatst door Tim.Bracquez

éé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/lig...ocs:ModFastCGI zie nginx dit nog niet nadoen, of ik heb de plank gemist

[ot] eigenlijk weinig toe te voegen voor probl. van ts [/ot]