Heb inmiddels een freelancer ingehuurd om dit probleem voor me op te lossen. Er is nog weinig gebeurd, maar sinds het initiele kijken op dinsdag, heeft de server geen storingen meer gehad.
Toen ik wel Apache geupdate via Yum, maar we draaiden al een Apache die 2 maanden geleden geupdate was. Volgens mij is de anti-loris-patch ook nog niet verwerkt in de nieuwste release.
maleadt schreef op zondag 21 juni 2009 @ 21:05:
Doet me denken aan een (D)DOS, wat zegt je Apache access log?
EDIT: indien de queries niet te traceren vallen naar webrequests (andere apps, ik zie veel verwijzingen naar "email" staan, courier inlogprocedure oid?) kan het altijd het werk van
slowloris zijn, die net als je beschrijft een sh*tload aan threads spawnt, en ze allemaal bezet houdt waardoor je server genekt wordt.
De Apache logs had ik helaas niet meer van de dag ervoor. Deze bleken geleegd te zijn door log-rotate. Had nog wel logs van de dag ervoor van de 200 vhosts op de server.
Heb inderdaad meegekregen dat er een nieuwe grote DDOS-tool uit is, die misbruikt maakt van een zwakheid van Apache. Zal dit weekend de patch installeren.
eamelink schreef op zondag 21 juni 2009 @ 21:08:
Het kan zijn dat je een brakke query draait waardoor je een locking probleem krijgt in MySQL. Dan gaan overige queries traag of niet en dan krijg je heel veel langdurende apache processen.
Ik vind Munin een erg waardevolle tool om goed in te kunnen schatten waar de problemen zich bevinden.
Je hebt het laten zien inderdaad, maar heb nog niet echt begrepen wat Munin precies doet. Ben benieuwd of het wel geschikt voor mijn situatie is, gezien bij mij tijdens storingen geen tools zijn uit te voeren dus.
Helaas heb ik geen apache logs van de betreffende storing. Wat voor vreemde zaken zouden hier in kunnen staan?
Verwijderd schreef op zondag 21 juni 2009 @ 21:36:
Ga eens aan de gang met mod_status. Dat er tig httpd processen draaien zegt niks. De vraag is wat al die processen aan het doen zijn. Dan weet je meteen welke website(s) dit veroorzaken en heb je ook nog eens een aangrijpingspunt om verder te gaan zoeken.
Je hebt gelijk, als ik de /server-status-pagina van Apache zou kunnen benaderen tijdens een storing, dan zou dit ideaal zijn. Maar de server is onbereikbaar tijdens storingen.
kalizec schreef op zondag 21 juni 2009 @ 21:40:
Als ik de enorme hoeveelheid httpd processen zie vraag ik me af waar dat goed voor is (tenzij het echt een server is die honderden simultane gebruikers heeft).
Ook zie ik er twee tussen staan met een load van 20+. Dus er gaat iets mis met die twee httpd's.
code:
1
2
3
4
5
| apache 22245 0.7 22.0 1433444 894232 ? D 14:55 0:58 /usr/sbin/httpd
apache 22252 0.3 0.9 509780 39816 ? S 14:55 0:23 /usr/sbin/httpd
apache 23844 0.3 1.0 508868 42768 ? D 15:08 0:24 /usr/sbin/httpd
apache 23846 0.3 1.0 508900 40648 ? S 15:08 0:22 /usr/sbin/httpd
apache 25747 1.7 26.0 2652156 1054012 ? D 15:27 1:38 /usr/sbin/httpd |
Je hebt helemaal gelijk dat er tijdens de outage veels te veel httpd-processen draaien. Er staan ook te veel open queries.
Tijdens hoge load, duurt het verwerken van httpd-requests en mysql-queries langer. Indien de load gigantisch is, kan de server nog maar enkele queries per seconde verwerken. Het is dus de vraag of het aantal queries en httpd-processen oorzaak of gevolg van de hoge load is.
Rainmaker schreef op maandag 22 juni 2009 @ 02:24:
Dingen die mij opvallen (naast degene hierboven genoemd):
code:
1
| apache 4242 0.1 0.0 22620 1008 ? D 17:03 0:00 /usr/bin/perl /usr/sbin/sendmail -t -i |
Een perl scriptje wat vanuit apache wordt aangeroepen?
code:
1
| /bin/sh -c /root/scripts/dns/plesk_export.sh /var/www/vhosts/default/htdocs/dns/zones.txt >/dev/null 2>&1 |
Is dit een crontab achtig ding wat voor plesk draait?
Die 2 httpd processen hierboven genoemd, vreten inderdaad nogal wat memory. Die processen zijn echter om 14:55 en 15:27 gestart, en staan nu in een interruptable sleep (waarschijnlijk aan het wachten op I/O). De "grote lading" connecties begon om 17:01.
Hoeveel concurrent connecties heb je op deze server en hoeveel child processes start apache in je config?
Heb je access logs van de websites die erop draaien en kun je kijken of er rond 17:01 - 17:04 inderdaad een groot aantal connecties is geweest? Kun je zien of er om 14:55 en 15:27 iets of iemand geconnect heeft naar een webpagina die "normaal" niet veel wordt opgevraagd?
Het is een script dat elke 5 minuten alle DNS-records weg schrijft naar een semi publiek bereikbare locatie. De secundaire DNS-server haalt hiervandaan de DNS records op. Methode is beveiligd met ip-restrictie en gebruikersnaam/wachtwoord-combinatie.
Zie hieronder het aantal child-processen. Heb geen idee wat je bedoelt met concurrent requests, een instelling of hoeveel er waren op het moment van outage. Op het moment van outage kun je er vanuit gaan dat het er enorm veel waren, gezien het aantal httpd-pid's. Helaas weet ik niet waar de requests voornamelijk vandaag kwamen en of er verdacht verkeer tussen zat.
code:
1
2
| ThreadsperChild 25
MaxRequestsPerChild 0 |
/u/8/oog3.png?f=community)
:strip_exif()/u/2087/osiris_ani.gif?f=community)
:strip_icc():strip_exif()/u/26612/droptikkels_icon.jpg?f=community){kind=icon}