[OT] Linux Kernel 2.6 Speicherverwaltung - Verständnisproblem
Hallo,
ich habe einige Probleme mit einem Debian Rechner bzgl. dem
Speichermanagement.
$ free
total used free shared buffers cached
Mem: 2074224 2017112 57112 0 44 719996
-/+ buffers/cache: 1297072 777152
Swap: 987956 111076 876880
Die Kiste hat also 2GB Speicher, davon werden momentan ~700MB als Cache
verwendet.
Folgende Betrachtung stelle ich an, da ich nach einem Festplatten-Tausch
einen Tag ohne Swap gearbeitet hatte und dort die Kiste zur Primetime
der Speicher ausgegangen war. Dabei zeigte der Munin-Speicher Graph
(http://www.freierbund.de/~nias/memory-week.png) das bis zu 2.6GB
Commited wurden und als die dann irgendwann auch benutzt werden sollte
der OOM Killer angesprungen war.
Solche Überlast/OOM Orgien möchte ich gerne verhindern. Daher habe ich
mir das OverCommit System des Kernel mal genauer betrachtet und
Veränderungen vorgenommen.
Nach meinen Anpassungen sieht das OverCommit wie folgt aus.
/proc/meminfo
CommitLimit: 2439912 kB
Committed_AS: 2041808 kB
Das Limit habe ich von Hand gesetzt: Ratio 70% Algo 2 (also nicht
default Algo 0)
Vorher hatte ich mit 50% gespielt, dabei jammerte dann aber Postgres zur
Primetime rum, das es keinen Speicher mehr bekommen würde, obwohl
weiterhin ~700MB als Cache angeblich verfügbar sind. Gejammert wurde,
verständlicher Weise, weil Committed_AS das Limit erreicht hatte.
Jetzt ist mir klar, das Committed_AS nur allozierter Speicher der
Programme ist, diese den aber bisher nicht benutzt haben könnten und
daher er noch nicht mit Pages hinterlegt ist. Leider kann man das
OverCommiten ja nicht ganz abschalten (wäre wohl auch nicht sinnvoll).
Das Problem was ich aber irgendwie nicht lösen kann ist:
- ich lasse overcommitten generell zu (bis 3GB pro Prozess bei 3GB/1GB
Split). Dann habe ich das Problem, wenn der OverCommitted Speicher mal
versucht wird zu benutzen -> OOM Situation -> Stillstand, keine
Admintätigkeit mehr möglich
oder:
- ich begrenze OverCommits auf ein Limit das machbar ist (also %XX-Ram +
Swap). Dann habe ich nie Kernel-OOM und kann immer noch die Kiste
managen. Allerdings können jetzt Programm den Commit-Bereich blockieren
und verhindern, das andere Programme notwendigen Speicher allozieren
können.
Gibt es keine dritte Variante oder lässt sich eine der beiden noch
sinnvoll verbessern?
Klar kann man in die Kiste einfach mehr Speicher stecken, aber
grundsätzlich muss das Problem doch in den Griff zu bekommen sein. Im
Normalbetrieb (auch Primetime) reichte der Speicher bis dato immer aus.
--
Markus Schulz
> > Ich kann warten.
> Du bist noch jung?
Ich komme langsam in das Alter, in dem man zwar das warten gelernt, aber
nicht mehr viel Zeit hat ;-)
Reply to: