Bekijk Volledige Versie : Httpd load
Ik heb het volgende probleem
httpd httpd (pid 11599 11608 11613 11615 11787 11793 11806 11911 11913 11925 11934 11941 12039 12052 12071 12096 12128 12130 12132 12133 12177 ) 584.4 MB
Na verloop van tijd worden er geen websites meer getoond.
Na een restart werkt het vervolgens weer
Iemand enig idee
httpd is je webserver, welke duidelijk veel RAM nodig heeft; waarom er zo veel http processen zijn, moet je verder zoeken.
Bijvoorbeeld server-status (http://kb.mediatemple.net/questions/1015/How+do+I+enable+the+server-status+page+on+my+server%3F#dv) aan zetten, maar vergeet niet om deze pagina te beveiligen.
Het kan ook zijn dat gewoon hardware / resources ontoereikend zijn geworden omdat e.e.a. website welke erop draait immens populair is geworden, dan moet je gewoon upgraden :)
edit: het kan ook zijn dat er e.e.a. bagger script draait welke nooit stopt waardoor Apache telkens nieuwe proces moet starten. Maar kan ook weer zijn dat je geen HDD ruimte meer nodig hebt... Duidelijk, moet je gewoon even verder zoeken :)
Bedankt voor je antwoord ik zal een kijken wat het kan zijn.
Iemand nog meer ideeen?
[root@w01 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md2 878G 32G 802G 4% /
tmpfs 3.8G 0 3.8G 0% /dev/shm
/dev/md0 25G 224M 23G 1% /boot
Vol is die dus niet
Ook inmiddels server-status ook aangezet maar wordt ik ook niet veel wijzer uit.
Hoe kan ik nu nog verder zoeken?
Ik kan me bericht niet meer aan passen. Op de status kom ik heel veel localhost NULL tegen
Het commando top kan je mogelijk wat meer inzichten verschaffen.
Ook daar komt weinig uit. Ik heb het een tijdje in de gaten gehouden maar helaas.
Stukje uit Server-Status
24-0 28782 0/14/116 R 0.28 1 0 0.0 0.00 0.04 ? ? ..reading..
25-0 - 0/0/73 . 0.36 137 0 0.0 0.00 0.09 ::1 localhost NULL
26-0 - 0/0/20 . 0.15 360 76 0.0 0.00 0.05 ::1 localhost NULL
27-0 - 0/0/90 . 0.80 280 0 0.0 0.00 0.03 ::1 localhost NULL
28-0 - 0/0/47 . 0.00 372 4 0.0 0.00 0.01 ::1 localhost NULL
29-0 - 0/0/213 . 0.66 201 120 0.0 0.00 0.12 ::1 localhost NULL
30-0 - 0/0/23 . 0.01 368 0 0.0 0.00 0.03 ::1 localhost NULL
31-0 - 0/0/71 . 1.35 253 0 0.0 0.00 0.03 ::1 localhost NULL
Bevinden er zich toevallig vreemde scripts in /tmp
Verzonden vanaf mijn iPad met behulp van webhostingtalk
Allemaal van dit soort bestanden
sess_iiqsqlk8u5v2obmivmk7ko5sb7
Welke versie van apache draait er?
Verzonden vanaf mijn iPad met behulp van webhostingtalk
Server version: Apache/2.2.23 (Unix)
Beste,
Er zijn meerdere mensen die dit probleem hebben in de 2.2 serie. Mogelijk is een update naar 2.2.27 noodzakelijk of naar de 2.4.9 versie.
Verzonden vanaf mijn iPad met behulp van webhostingtalk
Nou dan ga ik morgen eens kijken hoe dat in zijn werk gaat. Bedankt voor je hulp alvast
Normaliter op directadmin als root /usr/local/directadmin/custombuild/build update gevolgd door /usr/local/directadmin/custombuild/build httpd
Verzonden vanaf mijn iPad met behulp van webhostingtalk
Inmiddels toegepast en nu maar even afwachten wat dit gaat doen
Als het goed is heb je nu versie 2.2.27
Verzonden vanaf mijn iPad met behulp van webhostingtalk
Ik zou aanraden meteen te upgraden naar 2.4.x. Qua performance een stuk beter.
Aanpassen kan in de options.conf en daarna httpd opnieuw compilen met ./build httpd
./build apache werkt wat beter, tijd voor koffie denk ik :)
Nou ik ben nu naar de 2.27 maar komende nacht maar naar de 2.4.x.
Bedankt voor de tip
Top, de downtime is iets langer door een rebuild van PHP daarna
Nou daarom doe ik het ook liever in de nacht. Enkel afgelopen nacht lijkt weinig geholpen te hebben naar 2.27
./build apache werkt wat beter, tijd voor koffie denk ik :)
Dat en met 2 dingen tegelijk bezig. Multitasken gaat niet altijd goed ;)
Daarom moet je het ook in de nacht doen :)
Yourwebhoster
22/04/14, 16:36
Allemaal van dit soort bestanden
sess_iiqsqlk8u5v2obmivmk7ko5sb7
Ter informatie: de sess_ bestanden zijn sessie bestanden voor PHP (session_start()). Niks geks dus.
Tip: server-status is een moment opname. Je kan CSF (http://configserver.com/cp/csf.html) instellen om je server-status te laten sturen als de server belasting hoog is. Dan hoef je niet op server-status te blijven bashen:)
Ook een goeie tip. Ga ik er vannacht gelijk even bij mee proberen te pakken.
Ook daar komt weinig uit. Ik heb het een tijdje in de gaten gehouden maar helaas.
Stukje uit Server-Status
24-0 28782 0/14/116 R 0.28 1 0 0.0 0.00 0.04 ? ? ..reading..
25-0 - 0/0/73 . 0.36 137 0 0.0 0.00 0.09 ::1 localhost NULL
26-0 - 0/0/20 . 0.15 360 76 0.0 0.00 0.05 ::1 localhost NULL
27-0 - 0/0/90 . 0.80 280 0 0.0 0.00 0.03 ::1 localhost NULL
28-0 - 0/0/47 . 0.00 372 4 0.0 0.00 0.01 ::1 localhost NULL
29-0 - 0/0/213 . 0.66 201 120 0.0 0.00 0.12 ::1 localhost NULL
30-0 - 0/0/23 . 0.01 368 0 0.0 0.00 0.03 ::1 localhost NULL
31-0 - 0/0/71 . 1.35 253 0 0.0 0.00 0.03 ::1 localhost NULL
Dat "localhost null" zijn gereserveerde processen die staan te wachten om weer aan het werk te gaan, die doen dus feitelijk bijna niets qua belasting.
Dat moet ie ook doen (dat reserveren) om snel nieuwe processen bij te kunnen schakelen als het nodig is.
Als je een tijdje je server-status monitort zul je vermoedelijk toch zien wat het probleem veroorzaakt. Tegenwoordig zijn er bijvoorbeeld nogal wat scrapers die een website van voor tot achter indexeren en downloaden, dat kan beste een pittige belasting zijn voor een shared server, omdat ze het niet pagina voor pagina doen maar gewoon alles tegelijk, verdeeld over meerdere connecties (resulterend in heel veel PID vermeldingen in je status en httpd vermeldingen in je DA).
Als je een bericht krijgt in je DA ticketsysteem (Warning: The system load average is xx.xx) staat er in het bericht zelf trouwens ook vaak al meer informatie over waar dit door veroorzaakt wordt. Als dit door een bepaalde user wordt veroorzaakt staat zijn gebruikersnaam er gewoon bij.
Soms staat er bijvoorbeeld ergens een cronjob affiliate-producten in een shop te importeren wat niet helemaal vlekkeloos gaat, omdat hij bijvoorbeeld staat te wachten op een trage verbinding van de affiliate.
Overigens is het ook best de moeite waard om eens in user-crons te kijken wat er zoal gestart wordt door je klanten. En ook kun je eens kijken wat er zoal aan backups draait op de meest ongelukkige momenten.
TotallyHosted
23/04/14, 13:00
Overigens is het ook best de moeite waard om eens in user-crons te kijken wat er zoal gestart wordt door je klanten. En ook kun je eens kijken wat er zoal aan backups draait op de meest ongelukkige momenten.
Goede tip! /var/log/cron is je vriend.
Tasks: 228 total, 3 running, 225 sleeping, 0 stopped, 0 zombie
Cpu(s): 20.7%us, 11.2%sy, 0.0%ni, 49.1%id, 18.7%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 7957156k total, 7810412k used, 146744k free, 16192k buffers
Swap: 16382900k total, 37388k used, 16345512k free, 6574864k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30013 apache 20 0 223m 19m 5212 R 93.4 0.2 0:21.97 httpd
Nu loopt dus de server de load in
Het is duidelijk dat httpd de processor 'tijd' in beslag neemt.
Wat zegt je server-status op dit moment, wie neemt httpd in beslag?
Er staat overal apache bij :S
Euhm, apache is 'eigenaar' van de proces. Maar zie je of een bepaalde URL wordt aangeroepen, of dat een specifiek IP load veroorzaakt?
edit: doe even screenshot van server-status erbij?
11523
Hoop dit duidelijk genoeg is
Intriguing!
Google leert dat NULL i.c.m. localhost Google Chrome kan zijn (opbouwen van connectie). Maar - vele van NULL localhost connecties lijken weer van soortgelijk IP range afkomstig te zijn, wat weer op e.e.a. searchbot kan zijn.
Wat zie je in je apache / httpd logs (normaliter zijn ze in /var/log/httpd of /var/log/apache te vinden zijn).
Daar staat niks raars in misschien heb ik wel de boosdoener gevonden
Goede tip! /var/log/cron is je vriend.
Je bedoeld neem ik aan /usr/local/directadmin/data/users/<DA user>/crontab.conf
- - - Updated - - -
Daar staat niks raars in misschien heb ik wel de boosdoener gevonden
Als je wilt kijk ik straks even mee, waarschijnlijk kan ik de boosdoener dan wel voor je traceren (mits het dan nog speelt).
Mark je weet me vast wel te vinden :)
/forum/styles/redsteel/theme/images/headers/rotate.php deze geeft het probleem waarschijnlijk
MKB Webhoster
24/04/14, 23:28
Wat doet het rotate.php script exact waardoor je denkt dat dit de oorzaak is van je probleem?
Wordt het mss aangeroepen in een cronjob?
TotallyHosted
25/04/14, 10:51
Je bedoeld neem ik aan /usr/local/directadmin/data/users/<DA user>/crontab.conf
Nee, ik bedoelde daadwerkelijk /var/log/cron
Daar kun je precies zien wat de uitgevoerde cronjobs zijn geweest, dus terugzoeken naar het punt waar de problemen begonnen gaat heel handig met die logfile. Als je niet weet welke DA user het probleem veroorzaakt is het nogal veel werk om al die crontab-files door te gaan.
Nee, ik bedoelde daadwerkelijk /var/log/cron
Daar kun je precies zien wat de uitgevoerde cronjobs zijn geweest, dus terugzoeken naar het punt waar de problemen begonnen gaat heel handig met die logfile. Als je niet weet welke DA user het probleem veroorzaakt is het nogal veel werk om al die crontab-files door te gaan.
Mogelijk dat deze bestaat op CentOS (niet gecontroleerd), op Debian 6 en Debian 7 bestaat dit log bestand in ieder geval niet. Hier komen de cron log informatie in een aantal bestanden terecht (bv auth.log en syslog).
TotallyHosted
25/04/14, 15:31
Mogelijk dat deze bestaat op CentOS (niet gecontroleerd), op Debian 6 en Debian 7 bestaat dit log bestand in ieder geval niet. Hier komen de cron log informatie in een aantal bestanden terecht (bv auth.log en syslog).
Wij gebruiken inderdaad CentOS, weinig ervaring met Debian.
Jochem Stobbe
20/05/14, 14:08
Waarschijnlijk is er een script die heel veel load aantrekt, daar even naar kijken.
Inmiddels was dit probleem op gelost. Het script was inderdaad de oorzaak