Carsten Boehlke schrieb:

Der Server ist auf dem neusten Stand, was läuft ist ein Webserver mit CMS (Typo3). Der Server hat 1GB RAM und 2GB Swap, eigentlich nicht extrem wenig.

Kommt auf die Anwendung drauf an... 100 PS sind auch nicht sehr wenig... für einen Kleinwagen durchaus mehr als genug. Für einen 40Tonner schon "etwas knapp bemessen" -- 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

On Wed 23 Jul 2008, Carsten Boehlke wrote:

Jul 22 21:08:00 www kernel: Total swap = 2096440kB Jul 22 21:08:00 www kernel: Free swap:            0kB Jul 22 21:08:00 www kernel: 261872 pages of RAM Jul 22 21:08:00 www kernel: 5185 reserved pages Jul 22 21:08:00 www kernel: 71622 pages shared Jul 22 21:08:00 www kernel: 1 pages swap cached Jul 22 21:08:00 www kernel: Out of Memory: Kill process 11459 (mysqld) score 125428 and children. Jul 22 21:08:00 www kernel: Out of memory: Killed process 11459 (mysqld). Jul 22 21:08:00 www kernel: oom-killer: gfp_mask=0x201d2, order=0

Der Server ist auf dem neusten Stand, was läuft ist ein Webserver mit CMS (Typo3). Der Server hat 1GB RAM und 2GB Swap, eigentlich nicht extrem wenig.

Was kann man da noch tun?

Ich hatte sowas mal auf einer Postgres Maschine, die nebenbei ein wenig Mailverarbeitung gemacht hat. Das Script, das dieses tat, war offenbar nur mit kleinen Mailfiles getestet. Jedenfalls las es die Mailbox komplett in den RAM und fing dann an sie zu bearbeiten. Manchmal war das Mailboxfile aber

512MB ...

Da nun aber die Postgres DB der Prozess war, der am meisten Speicher verbrauchte, entschied sich der OOM Killer im Kernel meist für diesen, was bei einer Datenbank natürlich sehr blöd ist. Ich habe dann folgende Schritte unternommen: - das Mailscript umgestellt - den OOM Killer abgestellt - zeitweise mehr Swap (swapfile), später mehr RAM Der 2. Punkt ist interessant und könnte Dir helfen. Ich würde nämlich gern selbst bestimmen, welcher Prozess das out-of-memory kriegt, und es nicht einer blöden Heuristik im Kernel überlassen, zumindest nicht auf einer Datenbankmaschine. Mit folgenden Einstellungen in /etc/sysctl.conf vm.overcommit_memory=2 vm.overcommit_ratio=90 kriegt der Prozess, der das out-of-memory auslöst, mit großer Sicherheit einfach einen memory allocation Fehler und stirbt wahrscheinlich. Die Datenbank bleibt aber am Leben. Such mal in dieser Liste nach overcommit und meiner Email Adresse. Irgendwann letztes Jahr habe ich das näher beschrieben. 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. 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

Hallo, Am Mon, 28 Jul 2008, Carsten Boehlke schrieb: [..]

Leider kann ich mit dem Output von sar und free nicht viel anfangen, lediglich die Speicherauslastung kann ich da raus lesen.

sar kenne ich nicht, aber in der Ausgabe von 'top' kannst du sehen, welche(r) Prozess wieviel Speicher und Swap belegt. Ggfs. sollte man vorher noch die angezeigten Felder anpassen, dazu top aufrufen, mit 'f' Felder hinzufügen, mit 'F' entfernen, und dann mit 'W' die toprc schreiben. Diese wird dann auch im Batchmodus verwendet. Diesen rufst du per 'top -b' auf, per '-n ANZAHL' kannst du die Wiederholungen limitieren, per '-d SEKUNDEN' kannst du die Verzögerung für die jede WH einstellen. Ein top -b -d 60 >>/var/log/top.log würde z.B. einmal pro Minute den Status ins top.log schreiben. HTH, -dnh -- <logic mode="patent office"> Die Patente sind doch nicht trivial! Bei keinem dieser Patente wurde bei der Recherche ein früheres Patent mit etwas ähnlichem gefunden, also kann es nicht trivial sein und neu sein muss es auch. </logic> -- C. Faerber -- 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

Sandy Drobic schrieb:

Carsten Boehlke wrote:

...

Sandy Drobic schrieb:

...

Carsten Boehlke wrote:

...

Hallo Liste

Auf meinem Opensuse 10.2 habe ich folgendes Problem. In relativ unregelmäsigen Abständen (1 Tag bis mehrer Wochen) friert der Server ein, so dass nur noch ein Hard-Reset (Root-Server beim Provider) hilft. Im message log steht dann folgender Eintrag:

Jul 22 21:08:00 www kernel: Total swap = 2096440kB Jul 22 21:08:00 www kernel: Free swap: 0kB Jul 22 21:08:00 www kernel: 261872 pages of RAM Jul 22 21:08:00 www kernel: 5185 reserved pages Jul 22 21:08:00 www kernel: 71622 pages shared Jul 22 21:08:00 www kernel: 1 pages swap cached Jul 22 21:08:00 www kernel: Out of Memory: Kill process 11459 (mysqld) score 125428 and children. Jul 22 21:08:00 www kernel: Out of memory: Killed process 11459 (mysqld). Jul 22 21:08:00 www kernel: oom-killer: gfp_mask=0x201d2, order=0

Der Server ist auf dem neusten Stand, was läuft ist ein Webserver mit CMS (Typo3). Der Server hat 1GB RAM und 2GB Swap, eigentlich nicht extrem wenig.

Was kann man da noch tun?

Grins! Mehr RAM ist immer die billigste Lösung. Wenn du stundenlang nach dem Problem suchen musst, kannst du diese Kosten auch gleich in RAM investieren.

...

...

Finde heraus, welche Prozesse den Speicher belegen und warum. Erst dann kannst du mit dem Lösen des Problems anfangen. Es kann sein, das das Problem persistent connections ist oder dass MySQL nicht genügend Verbindungen erlaubt oder was auch immer. Ohne harte Zahlen wirst du nicht weiterkommen.

Ein Script, welches die RAM-Belegung in periodischen Abständen zeigt, könnte bereits helfen. Schau dir auch mal sar an.

Hallo Sandy.

Ich lasse mir jetzt jede Minute mit sar und free die Speicherauslastung in eine Datei schreiben und der Server mailt sie mir jede Stunde zu. Alles, was ich erkennen kann ist, dass die Speicherauslastung von einer auf die andere Minute drastisch nach oben schnellt (Swap-Usage liegt bei 90%+). Das dauert ein paar Minuten, dann läuft garnichts mehr und ich muss den Server resetten.

Wenn dies so schnell erfolgt, dann ist entweder ein Prozess aus cron angestossen worden, der enorm Ressourcen verbraucht, oder der Webserver wird von vielen Anfragen bestürmt. Überprüfe beide Möglichkeiten.

...

Leider kann ich mit dem Output von sar und free nicht viel anfangen, lediglich die Speicherauslastung kann ich da raus lesen. Im Messages Log gibt es zu der fraglichen Zeit auch keinen Eintrag. Irgendwelche Ideen?

Free gibt nur einen Überblick. Mehr Details verrät dies Ausgabe von top (interaktiv) oder "ps aux".

Wenn du den Prozess oder wenigstens den User identifiziert hast, dann kannst du in /etc/security/limits.conf als Reissleine einige Limits für den user setzen, die den Amoklauf in Grenzen halten, damit wenigstens der Server weiterläuft.

Nun war es wieder soweit. Hier der letzte Eintrag in mein Top-Log: top - 20:25:56 up 2 days, 22:53, 0 users, load average: 79.41, 64.77, 33.58 Tasks: 250 total, 72 running, 177 sleeping, 0 stopped, 1 zombie Cpu(s): 0.4%us, 91.1%sy, 0.0%ni, 0.0%id, 7.7%wa, 0.1%hi, 0.7%si, 0.0%st Mem: 1027004k total, 1018912k used, 8092k free, 2588k buffers Swap: 2096440k total, 2096440k used, 0k free, 5564k cached USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND root 10 -5 0 0 0 D 17.2 0.0 0:52.03 kswapd0 mysql 18 0 501m 13m 792 R 4.0 1.3 61:35.50 mysqld wwwrun 18 0 280m 12m 2064 R 3.0 1.2 0:05.18 httpd2-prefork wwwrun 18 0 287m 14m 2012 R 1.7 1.5 0:02.78 httpd2-prefork wwwrun 18 0 278m 9416 1864 R 1.6 0.9 0:02.50 httpd2-prefork wwwrun 18 0 295m 13m 2024 R 1.6 1.4 0:04.73 httpd2-prefork wwwrun 18 0 302m 14m 2020 R 1.5 1.5 0:04.29 httpd2-prefork wwwrun 18 0 287m 11m 2012 R 1.5 1.2 0:02.13 httpd2-prefork wwwrun 18 0 287m 17m 2012 R 1.5 1.8 0:02.07 httpd2-prefork wwwrun 18 0 287m 14m 2012 R 1.4 1.5 0:02.60 httpd2-prefork Und sar gibt folgendes als letztes aus: 20:25:25 kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad 20:25:27 9928 1017076 99.03 2656 6816 4 2096436 100.00 8716 Das ist doch nun der mysqld, oder täuscht mich das? 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

Sandy Drobic wrote:

/etc/security/limits.conf: wwwrun hard memlock 1048576

sollte rss sein, nicht memlock. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- 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

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

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