On Fri 01 Aug 2008, Carsten Boehlke wrote:
Ich habe die MaxClients von 150 auf 100 runter gesetzt, die MaxRequestsPerChild von 10.000 auf 1.000 und in der limits.conf bin ich Deinem obigen Beispiel gefolgt (BTW, wann wird die limits.conf eingelesen? Beim Systemstart oder wenn der Benutzer wwwrun ein Programm startet?). Was mich allerdings so ein wenig stutzig macht, ist, dass der Tod so plötzlich kommt, von einer auf die andere Minute. Wir haben auf dem Webserver tägliche Zugriffe von 1.500 - 2.000, nichts, wo ich annahm einen riesen Server zu brauchen. Eigentlich dachte ich auch, dass soetwas ein steter Prozess ist, sich also immer mehr hoch schaukelt. vm.overcommit_memory und -ratio sagen mir leider nichts, das muss ich mir erstmal anlesen.
Also, das ist eine Last, die sich auch einfach simulieren läßt, schön. MaxClients von 100 ist wahrscheinlich immer noch VIEL zu hoch. Was steht denn in der VIRT-Spalte direkt nach dem Start des Apache? Sicher nur ein paar MB. Beim Crash zeigte jeder Apache-Prozess aber >280MB. Du siehst also jeder Apache-Prozess hat vom Betriebssystem ca. 280MB RAM angefordert und das Linux hat immer schön ja gesagt. Ich kenne zwar nicht die Innereien von PHP und mod_php, aber ich kenne genügend andere Apache-Module, um zu Wissen, daß das meiste davon nicht speziell als shared memory gekennzeichnete Blöcke sind. Vermutlich hast Du einfach ein paar große dynamische Dokumente und mod_php will den Platz, um das Dokument komplett im Speicher zu rendern. Nun passiert folgendes, die erste Anfrage an solch ein Dokument bläst einen Apache-Prozess auf 280MB auf. Vermutlich wird er den größten Teil davon auch benutzen. D.h. Linux ordnet diesem Prozess vielleicht 200MB realen RAM+SWAP zu. Die nächste Anfrage für dieses Dokument trifft zufällig auf einen anderen Apache-Prozess und bläst diesen auch auf. Du siehst nach 2 Anfragen an verschiedene Prozesse ist Dein RAM alle (0.5GB für mysql schon abgezogen). Nach weiteren 8 ist auch Dein SWAP alle. Theoretisch solltest Du MaxClients nicht größer als 2 einstellen (denn Swapping ist immer schlecht für einen WEB Server)! Diese Überschlagsrechnung erklärt auch, warum der Ausfall so plötzlich stattfindet. Bei der geringen Anzahl an Zugriffen reicht wahrscheinlich im Schnitt genau ein Apache-Prozess. Die anderen 149 wird er einfach nicht oder nur selten benutzen. Irgendwann treffen sich dann mal 3 oder 4 gleichzeitige Anfragen und es platzt sofort. Aus dem access_log solltest Du herausfinden können, bei welchem Dokument Dein Speicher in die Höhe schnellt. Es ist wahrscheinlich das längste dynamische Dokument und sollte einige bis einige 10MB groß sein. Liefert der Server auch statische Dokumente aus? Wenn ja, solltest Du folgenden Setup einrichten. Ein Frontend Apache lauscht auf Port 80 oder 443 und nimmt alle Anfragen entgegen. Hier stellst Du MaxClients so ca. auf 50 (hängt im Prinzip davon ab, wie viele statische Objekte zu einem dynamischen gehören. Nimm diese Anzahl mal 2). Dieses Frontend machst Du so schlank, wie Du kannst. Also kein mod_php. Du brauchst aber mod_proxy. Dann setzt Du ein Backend auf, das vielleicht auf localhost:81 lauscht. Hier konfigurierst Du MaxClient=2. Mittels mod_proxy leitest Du im Frontend Anfragen auf dynamische Seiten an das Backend weiter (ProxyPass). Da statische Objekte direkt vom schlanken Frontend ausgeliefert werden, brauchst Du insgesamt für mehr Anfragen weniger Speicher. ListenBackLog ist standardmäßig 511. D.h. selbst wenn mehr als 2 Anfragen vom Frontend an das Backend gleichzeitig gestellt werden, gehen sie nicht verloren, sondern hängen einfach in einer Queue im Kernel rum und warten. Du brauchst diesen Wert nicht zu ändern. Selbst wenn alle Frontend Prozesse auf das Backend warten, ist die Queue nicht voll. Mit "ab" (findest Du in irgendeinem Apache-Paket) kannst Du das Ganze dann schön testen und herausfinden, wie sich das System bei unterschiedlichen Anzahlen paralleler Verbindungen verhält. Alternativ könntest Du vielleicht darüber nachdenken, PHP nicht in der mod_php-Variante, sondern als CGI-Programm zu benutzen, zumindest für das eine oder die paar Dokumente, die so groß sind. Torsten -- Need professional mod_perl support? Just hire me: torsten.foertsch@gmx.net -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org