PDA

Bekijk Volledige Versie : Hoge CPU-load op Apache processen in shared-(virtual)-host configuratie



martijn123
14/10/08, 09:32
Ik heb een shared hosting server met Debian sarge draaien (Apache2, MySQL4.1 en PHP4). Hier draaien zo'n 30 websites in een virtual-host omgeving.

Af en toe wordt de server zo zwaar belast dat beide core's van de CPU richting 100% gaan met als gevolg dat de websites niet benaderbaar zijn. Als ik monitor via top -d1 dan zie ik constant apache2 processen bovenaan staan die de CPU belasting veroorzaken. Na enige tijd gaan ze ook weer weg, maar soms duurt dat erg lang of ik moet Apache herstarten.

Nu probeer ik uit te zoeken welke site de belasting veroorzaakt, maar dat wordt lastig. Ik heb de extensie server-status voor Apache geactiveerd, maar kan hier niet erg boeiende informatie uit filteren. Ik zie inderdaad een aantal sites voorbij komen die op de server draaien, maar diegene die belasting veroorzaakt kan ik via deze interface niet achterhalen. Misschien snap ik de interface of het gebruik van deze extensie niet?

Concreet is mijn vraag:

Zijn er meer en vooral duidelijkere mogelijkheden om in een virtual-host omgeving een bepaald Apache proces te monitoren? In eerste instantie zou ik van een bepaald Apache proces willen weten bij welke website deze hoort.

Ik ben benieuwd.

Detonator
14/10/08, 09:40
Je moet de processen hebben waar in de vierde kolom een "W" staat, dit zijn de processen die momenteel draaien. Als je de PID's (2e kolom) vergelijkt met de processen die veel cpu gebruiken in top, weet je wat ze doen.

Je kunt het beste een scriptje maken die de output van apache server-status parsed en de nuttige processen weergeeft.

martijn123
14/10/08, 09:46
Je moet de processen hebben waar in de vierde kolom een "W" staat, dit zijn de processen die momenteel draaien. Als je de PID's (2e kolom) vergelijkt met de processen die veel cpu gebruiken in top, weet je wat ze doen.

Je kunt het beste een scriptje maken die de output van apache server-status parsed en de nuttige processen weergeeft.

Ah, dat is inderdaad een nuttige tip om de W processen in de gaten te houden. Bedankt!

Enuh.. dat scriptje? Heb jij daar toevallig als iets voor of weet je ergens een script te staan? :)

Japje
14/10/08, 10:12
apt-get install htop

en als je een process ziet met hoge load dan kun met de "s" toets een strace starten hier zie je veel info voorbijkomen wat een proces aan het doen is (en vaak ook waar)

wat je ook kunt doen is de PID pakken, en dan doe je "lsof |grep <PID>" (zonder <>)
Zie je direct waar het script of process vandaan komt.

Wat je ook kunt doen is mod_ruid (of suphp) installeren dan zie je zelfs in je ps van elke user het gestarte proces is.

martijn123
14/10/08, 10:40
apt-get install htop

en als je een process ziet met hoge load dan kun met de "s" toets een strace starten hier zie je veel info voorbijkomen wat een proces aan het doen is (en vaak ook waar)

wat je ook kunt doen is de PID pakken, en dan doe je "lsof |grep <PID>" (zonder <>)
Zie je direct waar het script of process vandaan komt.

Wat je ook kunt doen is mod_ruid (of suphp) installeren dan zie je zelfs in je ps van elke user het gestarte proces is.

Net weer een piek gehad, maar de "s" toets (via Putty ingelogd) werkt niet. Kan je hier meer over vertellen? Wel een handige tool overigens htop.

Lsof geeft mij nog niet echt de informatie die ik zoek. Tussen alle regels door zie ik wel een richting van een website die de belasting veroorzaakt, alleen ik wil graag weten wat er uitgevoerd wordt op deze site.

Japje
14/10/08, 10:52
Net weer een piek gehad, maar de "s" toets (via Putty ingelogd) werkt niet. Kan je hier meer over vertellen? Wel een handige tool overigens htop.

apt-get install strace i guess :P



Lsof geeft mij nog niet echt de informatie die ik zoek. Tussen alle regels door zie ik wel een richting van een website die de belasting veroorzaakt, alleen ik wil graag weten wat er uitgevoerd wordt op deze site.
nou weet je al de website, kun je in server-status kijken of in de log van die file wat er op gevraagt word. En strace zal je al wat meer vertellen over wat ie doet ;-)

suc6 :thumbup:

martijn123
14/10/08, 11:26
apt-get install strace i guess :P

Helaas, ik zie niets gebeuren (had strace al geïnstalleerd staan). Doe ik het wel goed? Ik start htop op, sorteer kolom op CPU en dan typ ik de "s" in??



nou weet je al de website, kun je in server-status kijken of in de log van die file wat er op gevraagt word. En strace zal je al wat meer vertellen over wat ie doet ;-)
suc6 :thumbup:

Yep, bedankt voor je (jullie) hulp. Ik denk dat ik een stuk wijzer ben geworden met het analyseren van logbestanden. Volgens mij zit mijn hoge belasting in het feit dat er gigantisch veel bots / spiders over de websites gaan. :cursing:

Misschien handig om hier een apart topic voor te openen.

j00p34
09/12/08, 09:37
Ik heb iets soortgelijks ervaren, bij het gebruik van een oud forum zonder registratie of captcha. Werd dus constant op gepost door spambots. Die vervolgens hun eigen posts gaan oproepen. Om zo bovenaan te komen bij "meest bekeken" vermoed ik. Misschien heb je ook last van zoiets?

marcel5
09/12/08, 10:46
De meeste spiders of harvesters faken hun user agent string, maar als ze 'm wel netjes laten zien dan is het bijvoorbeeld vaak:

Java/1.6.0_05
Wget/1.11.1

Ik blokkeer daarom alle bezoekers met user agents:

Java/
Wget/

Per dag zijn dat er een stuk of 10, dus dat scheelt me toch een hoop pageviews.

Ik doe dit al een paar maanden en ik heb nog geen klachten gehad van legitieme gebruikers (mijn email is nog steeds voor ze te zien), dus ik ga er vanuit dat ik geen normale users blokkeer.

Als je last hebt van mensen die je hele website downloaden (met programmas als HTTrack) dan heb ik nog wel een lijst met user agents die je ook in de ban kan doen.

_HB_
09/12/08, 16:45
De meeste spiders of harvesters faken hun user agent string, maar als ze 'm wel netjes laten zien dan is het bijvoorbeeld vaak:

Java/1.6.0_05
Wget/1.11.1

Ik blokkeer daarom alle bezoekers met user agents:

Java/
Wget/

Per dag zijn dat er een stuk of 10, dus dat scheelt me toch een hoop pageviews.

Ik doe dit al een paar maanden en ik heb nog geen klachten gehad van legitieme gebruikers (mijn email is nog steeds voor ze te zien), dus ik ga er vanuit dat ik geen normale users blokkeer.

Als je last hebt van mensen die je hele website downloaden (met programmas als HTTrack) dan heb ik nog wel een lijst met user agents die je ook in de ban kan doen.

Stuk of 10 is toch niet zoveel? Of veroorzaken die 10 dan zoveel pageviews?

En soms is het gebruik van wget wel handig, maar nu blokkeer je dat dus voor iedereen... weet niet of dat opweegt tegen die 10?

marcel5
09/12/08, 21:48
Stuk of 10 is toch niet zoveel? Of veroorzaken die 10 dan zoveel pageviews?

En soms is het gebruik van wget wel handig, maar nu blokkeer je dat dus voor iedereen... weet niet of dat opweegt tegen die 10?

M'n site is een soort image gallery, elke foto heeft een subpagina dus als een harvester die allemaal langs gaat dan loopt dat in de tienduizenden.

Ik heb nog nooit klachten gehad dat Wget niet werkt, dus ik denk niet dat mensen het missen.

_HB_
09/12/08, 22:12
M'n site is een soort image gallery, elke foto heeft een subpagina dus als een harvester die allemaal langs gaat dan loopt dat in de tienduizenden.

Ik heb nog nooit klachten gehad dat Wget niet werkt, dus ik denk niet dat mensen het missen.

Aha, dat levert wel een aardige load op inderdaad. En als klanten er dan geen last van hebben, is blokkeren wel zo logisch.