Mailinglist Archive: opensuse-de (1081 mails)

< Previous Next >
Re: mysqld und Swap
  • From: Torsten Foertsch <torsten.foertsch@xxxxxxx>
  • Date: Thu, 24 Jul 2008 13:03:06 +0200
  • Message-id: <200807241303.06890.torsten.foertsch@xxxxxxx>
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@xxxxxxx

--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+unsubscribe@xxxxxxxxxxxx
Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken
Sie eine Mail an: opensuse-de+help@xxxxxxxxxxxx

< Previous Next >
References