Torsten Foertsch wrote:
On Thu 06 Dec 2007, Thomas Hertweck wrote:
Torsten Foertsch wrote:
[...] wie stellt man am besten den oom-killer ab? Warum sollte man das tun wollen?
Nun z.B. weil man will, daß auch der Prozess gekillt wird, der zu der oom Condition geführt hat.
Auf dem Rechner läuft eine Postgres-Datenbank, die ca. 2GB Adressraum belegt. Wenn nun der oom-killer einen geeigneten Prozess zum killen sucht, erscheint ihm die DB am geeignetsten, weil er damit durch das Killen von nur einem Prozess eine große Menge Speicher kriegt.
In den OOM-Score fliessen noch andere Parameter ein, nicht nur die Menge des belegten Speichers: VM Groesse der Prozesse und von Child-Prozessen, nice-Werte (Prioritaeten), Runtime der Prozesse und Hardware-Zugriffe (Prozesse, die auf die Hardware zugreifen, sollten besser nicht gekillt werden). Einige Prozesse sind auch immun gegen den OOM Killer (z.B. init).
Leider ist die DB für mich aber bei weitem nicht der geeignetste Prozess, um per SIGKILL getötet zu werden.
Den Score gibt es unter: /proc/<pid>/oom_score
Egal, ich habe das Problem inzwischen gelöst:
echo 2 >/proc/sys/vm/overcommit_memory
oder
sysctl -w vm.overcommit_memory=2
[...]
Was ich noch nicht richtig verstanden habe ist der richtige Wert für overcommit_ratio. Default ist 50. Heißt das nun, daß ein alle Prozesse gemeinsam+Kernel einen Platz von swap+0.5ram belegen dürfen? Ist das nicht Verschwendung? 0.5ram wird doch dabei irgendwie nicht benutzt, oder? Ich habe irgendwo auch als Beispiel gelesen, daß eine Maschine mit 1GB RAM und 1GB Swap mit dieser Einstellung als 2.5GB Maschine betrachtet würde. Das widerspricht dem doch aber?
Steht overcommit_memory auf 2, dann ist overcommit_ratio die Prozentzahl, um die der Kernel die Memory-Resourcen ueberbewertet. In anderen Worten, damit gaukelt man vor, man haette mehr RAM als eigentlich tatsaechlich vorhanden ist. Entsprechend reagiert der Kernel dann anders auf Speicheranforderungen. Das geht mit manchen Programmen gut, weil sie ueber die gesamte Laufzeit gesehen nicht allen angeforderten Speicher auch tatsaechlich stets beanspruchen (siehe dazu auch "optimistic memory allocation"). Mit anderen Programmen (die tatsaechlich allen angeforderten Speicher nutzen) fuehrt es zu ziemlichen Performance-Einbruechen (weil staendig geswappt wird). Bei 2GB RAM und 50% overcommit_ratio gaukelt man 2GB + 50% * 2GB = 3GB plus entsprechenden Swap-Space vor.
Ich dachte immer swap+ram ist der Platz, den alle Prozesse gemeinsam + Kernel belegen können. Ist das falsch?
Die Frage verstehe ich nicht ganz. Wenn der OOM Killer aktiv wird, dann gibt es entweder keine Pages im VM mehr, oder es ist kein User Address Space mehr vorhanden (bei 4GB Speicher ist das Verhaeltnis normalerweise 1GB zu 3GB Kernel Space/User Space). Oder beides tritt ein. Der Heap, aus dem allokiert wird, ist aber nicht die vollen 3GB, da muss man die Bereiche fuer Mapping, Stack, Code Segments, etc. abziehen. Alle Angaben nach bestem Wissen und Gewissen. Cheers, Th. PS: Bitte versende keine Privatemails von Postings! Warum sollte ich Deine Email zwei Mal erhalten wollen? -- 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