-
Het is natuurlijk moeilijk om hierover goed advies te geven zonder gedetailleerde gegevens te kunnen inkijken. Het kan van alles zijn.
Zijn de pieken in de grafiek dagelijks rond dezelfde tijdstippen terug te vinden?
Dan zou het bijvoorbeeld een cronjob kunnen zijn die zwaar belastend is.
Het zou evengoed een geautomatiseerde attack kunnen zijn (brute force login pogingen bijvoorbeeld...).
Er zijn nog zoveel mogelijkheden dat het echt wel noodzakelijk is verder in het systeem te kijken, wil men hier de reden kunnen aanhalen.
In een virtuele omgeving bestaat natuurlijk ook de kans nog dat de disks soms zodanig belast worden door andere VM's dat je eigen VM er hinder van gaat ondervinden. Hoewel dit niet zou mogen, het kan zeker gebeuren als de hosting zou gebeuren op oversubscribed hardware.
-
Wellicht heb je wat aan de onderstaande info:
Het gaat natuurlijk altijd om de echte oorzaak. Rottige query, posts op een formulier , enorme bestanden, constant indexeren of gewoon veel bezoekers.
Disk I/o. Is die hoog? Waarom dan? 9 van de 10 keer is hij aan het swappen.. Maar als hij dat niet is, welk proces zorgt dan dat hij druk is.
Dat resulteert ook een hoge i/o wait. Daar wordt een server nooit sneller van :-). De processor is dan overigens niet zo druk. Die staat immers te wachten en kan niets doen en dat kan je dus op het verkeerde been zetten als je alleen daar naar kijkt.
Swappen? Dan is hij dus geheugen op disk aan het zetten omdat hij te kort komt. Meer geheugen zou helpen.
Maar is hij niet aan het swappen en de disk is niet druk dan moet haast wel de processor gewoon druk zijn. Daardoor wordt er ook weer meer geheugen gebruikt (omdat alles een beetje staat te wachten). Als dat dan weer te erg wordt, gaat hij alsnog swappen en wordt de processor weer wat rustiger maar alles dus weer super traag.
-
denk dat het handig is om eerst vast te stellen wel process de load veroorzaakt.
- database (mysql, mongo etc)
- crontab
- webserver
Daarna kan je op process / applicatie kijken wat het veroorzaakt welk script of welke query.
-
Zoals al een paar keer gezegd, is het op afstand heel moeilijk bepalen wat er aan de hand is.
Probleem analyse is een 'kunst' die niet te bevatten is door in het wilde weg maar dingen te proberen of te bekijken. (Wat vaak wel gebeurd doordat het op een forum wordt aangekaart. Elk lid kijkt vanuit zijn/haar eigen perspectief en ervaring, dus krijg je van alle kanten tips)
Uit ervaring weet ik dat in geval van hosting servers er legio mogelijkheden zijn waarom een server 'trager' is geworden. Van een (ddos) aanval, tot een gehackte site waar (grote) bestanden worden gedownload, tot hacks die (spam)mails versturen en ga zo maar door. Sommigen die zelfs heel vernuftig in elkaar zitten zodat het nauwelijks op valt. Het is dus zaak om goed door logs heen te spitten, eventueel extra monitoring aan te zetten, php mail te loggen zodat je ziet welk script wanneer mailt, top bij te houden, en zo langzaam te analyseren waar de vertraging vandaan komt.
En, als het probleem is opgelost, ga naar een goede systeem monitoring. Je hebt dan a) history van tijden dat alles normaal is, b) sneller zicht op een eventueel probleem en dus kun je bepalen wanneer het probleem begonnen is, en dat relateren aan acties/bestanden van rond het tijdstip dat de problemen begonnen.
