Apache Reverseproxy Keepalive

[Terminal]

Ahoi

Habe einen Reverseproxy unter Debian 5.03 in der Version 2.2.9 laufen der ansich auch gut funktioniert. Als Backendserver dient ein Ubuntu Intrepid mit einem Apachen in der Version  2.2.9.

Das Problem ist jetzt folgendes:

Lässt man den Reverseproxy in der Standardkonfiguration, verwendet er Keepalive zu den Backendservern. Nachdem der Content geholt wurde, bleibt allerdings eine CLOSE_WAIT Verbindung zurück (die nur durch einen Neustart wegzukriegen ist).

Dreht man das Keepalive zu den Backendservern mit SetEnv proxy-nokeepalive 1 ab, funktioniert alles wunderbar und die Verbindungen werden auch ordnungsgemäß geschlossen

strace sagt mir, dass die Apache Workers mit CLOSE_WAIT bei einem semop hängen (und zwar alle auf die gleiche Semaphoren ID).

Hoffe ihr könnt mir weiterhelfen, da Keepalive doch einen gewaltigen Geschwindigkeitsvorteil bringt.

LG

[Edgar Ehritt]

Hallo,

Das Problem ist jetzt folgendes:

da werden wir wohl warten müssen: Apache Bug 45362.

Gruß aus Berlin!
eddi

[Terminal]

Hallo,

Das Problem ist jetzt folgendes:

da werden wir wohl warten müssen: Apache Bug 45362.

Gruß aus Berlin!
eddi

Hui, danke für die schnelle Antwort!

Leider sieht das Problem nur so ähnlich aus wie meins. Meine CPU bleibt völig unangetastet, es sind einzig und allein die Socketleichen die mich stören (und die auf Dauer Memory verschlingen). Folglich dürfte es sich hier wohl um einen anderen Bug handeln

Lg

[Edgar Ehritt]

Re:

Leider sieht das Problem nur so ähnlich aus wie meins. Meine CPU bleibt völig unangetastet, es sind einzig und allein die Socketleichen die mich stören (und die auf Dauer Memory verschlingen). Folglich dürfte es sich hier wohl um einen anderen Bug handeln

Wird von Dir auch mpm_worker genutzt?

Ansonsten viele mir nur ein, mit MaxRequestPerChild zu experimentieren und den Wert immer geringer werden zu lassen, bis (hoffentlich) das Problem nicht mehr auftritt. Und was das Hängen der Kindprozesse des Webservers an einer Semaphore anbelangt, sehe ich dort eigentlich kein Problem. Wenn es Dich stört, würde ich konfigurativ den Mutex ändern.

Gruß aus Berlin!
eddi

[Edgar Ehritt]

Was mich auch noch interessieren würde, was netstat -tv zu diesen hängenden Verbindungen ausgibt.

Gruß aus Berlin!
eddi

[Terminal]

Die Childs zu reduzieren wäre natürlich eine Möglichkeit, allerdings fällt das unter Symptombekämpfung (einen Workaround hab ich ja bereits mit KeepAlive abdrehen). Mich würde einfach echt interessieren woran das liegt.

Da auf dem Reverseproxy auch ein paar kleine PHP Seiten laufen (in einem anderen VirtualHost) habe ich apache2-mpm-prefork.

netstat -natpv | grep CLOSE_WAIT sagt folgendes:

tcp 1 0 192.168.0.240:50812 192.168.0.31:80   CLOSE_WAIT  7880/apache2
tcp 1 0 192.168.0.240:50813 192.168.0.31:80   CLOSE_WAIT  7881/apache2
tcp 1 0 192.168.0.240:50811 192.168.0.31:80   CLOSE_WAIT  7879/apache2
tcp 1 0 192.168.0.240:50815 192.168.0.31:80   CLOSE_WAIT  7883/apache2

Lg

[Edgar Ehritt]

Re:

Die Childs zu reduzieren wäre natürlich eine Möglichkeit, allerdings fällt das unter Symptombekämpfung (einen Workaround hab ich ja bereits mit KeepAlive abdrehen).

ja, leider.

Mich würde einfach echt interessieren woran das liegt.

Mir fällt da zweierlei ein:

Debian, soll(te) auf andere Bibliotheken umgestellt werden (vlg. http://blog.aurel32.net/?p=47). Da Debian (was als Kind dessen auch Ubuntu beträfe) versorgt sich ja mit fertigen Kompilaten. Es könnte also zu einem Konflikt der gelinkten Bibliotheken gekommen sein, was auch innerhalb verschiedener Versionen derer geschehen kann. ldd -v /pfad/zu/httpd könnte da im Vergleich zum System etwas ergeben. Im Zweifel würde ich mir den neusten Apachen besorgen und selbst kompilieren.

Viel eher habe ich da aber die TCP/IPv6-Ebene im Verdacht. Kernel eben mal mit allen entsprechenden Modulen unterhalb von "TCP/IP networking" durchgucken; notfalls neubauen.

Gruß aus Berlin!
eddi

[Terminal]

Um jetzt allzu tief in das Networking vom Linux Kernel hineinzugraben fehlt mir leider das Wissen. IPv6 hab ich bereits vorsorglich deaktiviert. Gibt es Standardüberprüfungen die man auf jeden Fall einmal durchführen sollte um auf Probleme zu stoßen?

Lg und vielen Dank für die Kompetente Hilfe

[Edgar Ehritt]

Re:

Gibt es Standardüberprüfungen die man auf jeden Fall einmal durchführen sollte um auf Probleme zu stoßen?

Mir fiele jetzt nichts weiter ein.

Ich würde Dich aber bitten nochmals zu überprüfen, dass die Prozesse im Status CLOSE_WAIT verharren. Dazu konfigurierst Du bitte beide Server (Web und Proxy) mit TimeOut 5 und KeepAliveTimeOut 5 (sicherheitshalber beim Proxy auch ProxyTimeOut 5) sowie LogLevel debug, isolierst die beiden Server von Anfragen, die von Außerhalb kommen, setzt einen einzelnen Request mit einem Browser ab und beobachtest, ob der Status CLOSE_WAIT dauerhaft (über 10 Minuten) bestehen bleibt.

Sollte das nicht der Fall sein, haben wir es hier einfach nur mit einem Missverständnis meinerseits zu tun. HTTP/1.1 sieht auf TCP-Ebene persistente Verbindung vor (vgl. RFC 2616; 8). CLOSE_WAIT sagt nur, dass der Server auf ein Beenden der Verbindung durch den Client wartet. Wird nicht beendet, setzt ein time out ein. Das ist der Normalzustand. Dumm wäre eben nur, wenn das System mit diesen Hängern bis zur konfigurierten Obergrenze verschlackent.

Bleiben die Prozesse im Status verharren, erscheint es mir als gesichert, dass in der TCP-Schicht etwas gehörig schief läuft. Damit würde ich Dir anraten, dann in ein Debian-Forum zu gehen. Dafür sind dann vielleicht auch die debug-Logs des o. g. Test hilfreich.
 Selbst kenne ich mich mit Debian nicht aus, um Dir weiter helfen zu können.

Gruß aus Berlin!
eddi

[Terminal]

Ja leider, die Verbindungen bleiben. Nagut dann werde ich mal die Debianer bemühen!

Vielen Dank für deine Hilfe!

Lg