RootForum Community

Hi
ich habe ein lästiges Problem mit einem Webserver.

Kurz die Eckdaten:
AMD64 3.7GHz
1GB RAM

Debian 3.1
Apache 2.0.54 (MPM-Prefork)
suPHP 0.5.2
PHP 4.3.10

Auf dem Rechner laufen etwa 20 Seiten, davon die meisten sehr klein, 2-3 Blogs usw - Insgesamt ca. 2000 Besucher pro Tag - Also nicht viel.

Jetzt passiert es aber ab und zu, dass der Apache hängt. Das äussert sich so, dass keine neuen Anfragen mehr bearbeitet werden (im Browser wird einfach geladen), jedoch werden weder CPU (im einstelligen % Bereich) noch RAM (ca. 120 MB) irgendwie gross belastet. Alle anderen Dienste funktionieren problemlos.

Nach einem Apache Restart läuft es dann entweder wieder problemlos, oder innerhalb von wenigen Sekunden hängt er bereits wieder.

Habe jetzt das server-status Modul mit ExtendedStatus On aktiviert und konnte heute direkt zusehen was passiert. Immer mehr Apache Prozesse sind damit beschäftigt irgendwen (keine IP sichtbar, nur ?, siehe Screenshot) zu bedienen, verbleiben aber in einem "..reading.."-Status. Wenn ich die status-seite regelmässig aktualisiere, kriege ich sie auch schnell wie immer, nur wenn ich etwas länger warte (wahrscheinlich den Keep-Alive Timeout von 15s überschreite) werde ich auch rausgeschmissen und bekomme keine Seite mehr angezeigt.

Nach einem Restart laden dann alle Seiten, die nicht mehr bedient werden konnten nach, dann sehe ich alle Prozesse mit verschiedenen Client IPs, aber innerhalb von einigen Sekunden werden wieder alle von diesem "..reading.." Status blockiert und keine weiteren Aufrufe werden bearbeitet.

Weiss jemand was das zu bedeuten hat? Was macht der Apache genau wenn er liest ("..reading..").

Wenn dieses Problem auftritt, sehe ich jeweils mit netstat immer eine andere IP Adresse, die mit allen Instanzen verbunden ist. Wenn ich nach dieser IP in den Logs suche, finde ich dann relativ wenige, völlig normale Zugriffe auf Dateien die hunderte andere auch aufrufen.

Ein Performance Problem schliesse ich eigentlich aus, da wie gesagt, die Load sehr gering ist und auch sonst alles sehr performant läuft, selbst wenn (für diesen Server) mal viel los ist.

"Leider" passiert das ganze relativ selten, vielleicht 2-3 im Monat, sodass ich neue Einstellungen schlecht direkt testen kann.

Habe mit Google einige andere mit dem gleichen Problem finden können, jedoch auch ohne Lösung.

Hat jemand von euch eine Idee?

Vielen Dank, static

Die Client-IPs stammen nicht zufällig von Suchmaschinen? Google und LiveSearch sind recht ressourcenfressend wenn man sie nicht ausbremst...

Hi Joe User

Nein, waren bisher alles IPs von ISPs, ich gehe also von normalen Benutzern aus.

Ausserdem passt eine Suchmaschine auch nicht wirklich in das Problem - Es sind ja nicht einfach plötzlich sehr viele Requests, sondern einige wenige die aus irgendeinem Grund nicht abgearbeitet werden...

so long
static

Ich konnte das Problem heute reproduzieren.
Es reicht tatsächlich nur genügend sessions zu öffnen (bspw. mit telnet http://www.domain.tld 80) und einfach nichts zu senden. Dann ist dieser "slot" für 5 Minuten (Standardwert für TimeOut) blockiert.

Ich werde das heute Nacht genauer untersuchen, Vorschläge sind gerne willkommen. Ich glaube nicht, dass es viel bringen wird einfach die MaxClients zu erhöhen, ob ich auf der Clientseite jetzt 20 oder 200 Telnet sessions offen habe ändert nicht viel...

Ist das normal so? Warum soll denn überhaupt noch jemand grosse DDoS Geschütze auffahren, wenn ich mit einem einzigen Computer hunderte Slots besetzen kann?


so long
static

Nach einer Diskussion in der Apache Mailingliste bin ich nun schlauer... Falls sich jemand mit dem gleichen Problem auseinander setzen muss hier die Lösung:

Es ist tatsächlich so, dass bei dieser Apache Version (2.0.54) für jede Verbindung erstmal ein Slot (sprich, bei Prefork ein http child) reserviert wird, der dann maximal bis zum als Timeout definierten Zeitpunkt (Default 300s) offen bleibt.
Durch dieses Verhalten lässt sich der Server wirklich sehr leicht und ohne grossen Aufwand blockieren, da eine simple Verbindung reicht um einen Slot für 5 Minuten zu besetzen.

Seit Version 2.1.5 gibt es nun die AcceptFilter Option (bzw. ist standardmässig aktiviert). Damit lässt sich einrichten, dass die Verbindung erstmal beim Kernel behalten wird, bis wirklich eine Anfrage stattgefunden hat. Erst dann wird die Verbindung einem Apache Prozess zugewiesen.

Werde daher wohl upgraden 8)

static