Torsten Foertsch schrieb:
On Fri 01 Aug 2008, Sandy Drobic wrote:
Jedenfalls würde ich an deiner Stelle den Apache erst einmal an die Leine nehmen, damit zumindest der Server nicht mehr komplett zusammenbricht und du besser die Ursachen erforschen kannst.
/etc/security/limits.conf: wwwrun hard memlock 1048576
Schau dir mal die Beispiele dort an.
Oder verwende "ulimit -v 1048576" im Startscript des Apache.
Und dann solltest du nachforschen, warum der Apache so ein Ramschlucker ist.
Das habe ich ihm schon am 24. Juli gesagt, ohne das Log gesehen zu haben: <cite> On Thu 24 Jul 2008, Torsten Foertsch wrote:
Nun eine Vermutung, wer der Verursacher Deines Problems ist, nämlich mod_php im Apache. Ich denke, Du hast einen WEB Server, nicht eine Frontend/Backend Architektur? Und Du hast wohl MaxClients recht hoch eingestellt. Damit hast Du eine Menge Prozesse, die alle relativ viel RAM verbrauchen, zusammen mehr als Du verkraften kannst.
Mach ein Frontend/Backend Setup, bei dem das Frontend mit relativ hohem MaxClients nur statische Files (Bilder, Stylesheets, ...) ausliefert und dynamische Seiten von einem Backend mit niedrigem MaxClients und mod_php erzeugt werden.
Für beide Prozesse ist vielleicht auch ein ulimit Aufruf im Startscript angebracht, das den Speicherverbrauch begrenzt. Wenn Du vielleicht auch mod_perl benutzt, kann Apache2::SizeLimit helfen, Worker-Prozesse, die ungewöhnlich viel RAM verbrauchen, kontrolliert zu beenden.
</cite>
Zusätzlich zu dem Frontend/Backend Setup solltest Du mit MaxRequestsPerChild (relativ klein) und MaxClients (auch relativ klein) im Backend experimentieren. Letzteres legt die max. Anzahl der Apache-Prozesse fest. Ersteres die Anzahl der Verbindungsanfragen von Clients, die ein Prozess bearbeitet bevor er sich selbst beendet. Da Deine Apache-Prozesse offensichtlich langsam immer mehr Speicher verbrauchen, sollte ein häufigerer Wechsel die Durchschnittsgröße verringern.
mysql hat 500 MB geschluckt, den Rest hat sich der Apache geschnappt. Ich würde erst den Apache etwas einschränken, danach mysql. Jedenfall würde ich mehr RAM empfehlen mit Typo.
Normalerweise sollte auch der oom-killer dann Prozesse abschießen. Wahrscheinlich würde der den mysql-Prozess töten, weil der doch so viel RAM schluckt. (^-^)
mysql ist in diesem Fall aber das unschuldige Opfer. Und gerade für einen Datenbank ist "kill -9" vom oom-killer recht schädlich. Stell zusätzlich zum ulimit für den Apache noch den Speichermanager Deines Linux so ein, daß er nur soviel Speicher vergibt, wie Dein Rechner auch hat. Damit wird sich wahrscheinlich der Prozeß verabschieden, der als letzter Speicher wollte und nicht irgendeiner, den Linux am wenigsten mag.
In der Standardeinstellung macht Linux nämlich folgendes. Ein Prozeß braucht Speicher (malloc). Linux sagt einfach "Hier nimm! Es ist eh bloß virtueller RAM. Kannst kriegen, soviel Du willst (ok, <~3GB bei 32 bit Architektur)". Linux reserviert dabei nur Platz im virtuellen Adreßraum des Prozesses, keinen realen Speicher. Realen Speicher gibt's seitenweise, also in 4kb Häppchen, erst, wenn der Prozeß auch wirklich darauf zugreift. Und zu diesem Zeitpunkt kann es nun passieren, daß kein Speicher mehr da ist. Dann tritt der oom-killer in Aktion, wählt nach einer Heuristik einen Prozeß aus und killt ihn mit SIGKILL.
Über vm.overcommit_memory und vm.overcommit_ratio in /etc/sysctl.conf läßt sich das Verhalten ändern.
Torsten
Hallo Thorsten. 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. Danke und Gruß Carsten -- 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