Hallo, wie stellt man am besten den oom-killer ab? Danke, Torsten -- 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 wrote:
[...] wie stellt man am besten den oom-killer ab?
Warum sollte man das tun wollen? Th. -- 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 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. Leider ist die DB für mich aber bei weitem nicht der geeignetste Prozess, um per SIGKILL getötet zu werden. Egal, ich habe das Problem inzwischen gelöst: echo 2 >/proc/sys/vm/overcommit_memory oder sysctl -w vm.overcommit_memory=2 Die Kiste hatte 4GB RAM + 2GB Swap. Ab und zu (nachts) läuft dort ein Prozess zusätzlich zur DB, der einen großen Klumpen Speicher braucht. Mir wäre es nun viel lieber, wenn der Kernel diesen zusätzlichen Prozess killen würde, oder noch besser, wenn er dem Prozess beim malloc sagen würde: "leider kein Speicher mehr da", als einfach zu einem unbestimmten Zeitpunkt Prozesse zu killen. 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? Ich dachte immer swap+ram ist der Platz, den alle Prozesse gemeinsam + Kernel belegen können. Ist das falsch? Ich habe hier eine Kiste mit 4GB RAM und 4GB Swap. Nach overcommit_ratio=0 meldet mir /proc/meminfo ein CommitLimit von 4GB. Mit ratio=100 entsprechend 8GB, also RAM+Swap. Was ist nun richtig, damit der Kernel unter gar keinen Umständen den oom-killer anwirft? Torsten -- A: It reverses the normal flow of conversation. Q: What's wrong with top-posting? A: Top-posting. Q: What's the biggest scourge on plain text email discussions? -- 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 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
On Fri 07 Dec 2007, Thomas Hertweck wrote:
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.
D.h. wenn der oom-killer nie in Aktion treten soll, muß ratio=0 sein. Sinnvoll ist das sicher nicht, da die meisten Programme wohl die eine oder andere Seite sinnlos anfordern. Aber bei Programmen mit großen Datensegmenten, auf die sie auch zugreifen, ist ein kleiner ratio (~10) sicher sinnvoll, oder? Trotzdem verstehe ich den Sinn dieser Formel nicht: total address space = swap + ratio * physical RAM Danach sollte doch der Adreßraum bei z.B. 3GB swap und 1GB RAM auf 3.5GB begrenzt sein. Der gesamte verfügbare Speicher von 4GB wird also nicht ausgenutzt? Das ist irgendwie unlogisch. Andererseits nach Deiner Argumentation oben käme Swap hier nochmal dazu, also total address space = 2 * swap + ratio * physical RAM Das ist aber noch unlogischer, denn wenn swap viel größer als RAM ist, hätte er den größten Einfluß auf die Menge des nicht wirklich verfügbaren RAMs. Im Beispiel hätten wir 6.5GB Adreßraum, von denen nur 4 wirklich benutzt werden können. Wo ist hier der Fehler? Ist die erste Formel richtig, würde ratio=100% bedeuten, es darf der gesamte RAM und der gesamte Swap benutzt werden. Dann wäre aber die default-Einstellung von ratio=50 irgendwie Quatsch. Die 2. Formel ist totaler Quatsch. Wenn ich mir jetzt ein System ohne Swapspace vorstelle und ratio=0 setze, dann kommt nach der ersten Formel: total address space = swap + ratio * physical RAM = 0 + 0 *X = 0 raus. Das System hat also keinen Adreßraum zu vergeben. Irre.
PS: Bitte versende keine Privatemails von Postings! Warum sollte ich Deine Email zwei Mal erhalten wollen?
Schuldigung, ich drücke meist automatisch auf "a". Das heißt Antwort an alle. Torsten -- A: It reverses the normal flow of conversation. Q: What's wrong with top-posting? A: Top-posting. Q: What's the biggest scourge on plain text email discussions? -- 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 wrote:
[...] D.h. wenn der oom-killer nie in Aktion treten soll, muß ratio=0 sein. Sinnvoll ist das sicher nicht, da die meisten Programme wohl die eine oder andere Seite sinnlos anfordern.
Ich verstehe Deinen Gedankengang nicht. Wenn kein Speicher mehr zur Verfuegung steht, der von Programmen tatsaechlich gebraucht wird, dann ist das Ende der Fahnenstange erreicht, ob mit oder ohne overcommit. overcommit erlaubt Dir lediglich, Speicher in gewissen Faellen effizienter zu nutzen. Aber das geht nicht mit allen Programmen.
[...] Trotzdem verstehe ich den Sinn dieser Formel nicht:
total address space = swap + ratio * physical RAM
Danach sollte doch der Adreßraum bei z.B. 3GB swap und 1GB RAM auf 3.5GB begrenzt sein. Der gesamte verfügbare Speicher von 4GB wird also nicht ausgenutzt? Das ist irgendwie unlogisch.
Die ausfuehrliche Formel lautet: address space = swap + (1.0 + overcommit_ratio/100.0) * RAM Bei 3GB swap und 1GB RAM ergibt sich bei overcommit_ratio=50: 3GB + (1.0+50/100.0) * 1GB = 3GB + 1.5 * 1GB = 3GB + 1.5GB also angeblich 4.5GB virtueller Adressraum. Dieser kann genutzt werden, wenn nicht alle Programme gleichzeitig ihren allokierten Speicher auch tatsaechlich benutzen. Wenn all die laufenden Programme allen ihren allokierten Speicher wirklich brauchen, wird das overcommit nicht funktionieren und der OOM Killer wird aktiv. Genau wie bei Flugzeugen, die ueberbucht werden - wenn zum Abflug tatsaechlich alle Passagiere erscheinen, dann bleiben da ein paar auf der Strecke.
Andererseits nach Deiner Argumentation oben käme Swap hier nochmal dazu, also
total address space = 2 * swap + ratio * physical RAM
Nein, wieso sollte da 2*swap erscheinen, das habe ich auch nicht geschrieben.
[...] Ist die erste Formel richtig, würde ratio=100% bedeuten, es darf der gesamte RAM und der gesamte Swap benutzt werden. Dann wäre aber die default-Einstellung von ratio=50 irgendwie Quatsch. Die 2. Formel ist totaler Quatsch.
Ich glaube nicht, dass Du overcommit / Speichermanagement wirklich
verstanden hast (ich wuerde mich auf dem Gebiet allerdings auch nicht
als Experten bezeichnen, nur programmiere ich ziemlich viel).
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#include
Wenn ich mir jetzt ein System ohne Swapspace vorstelle und ratio=0 setze, dann kommt nach der ersten Formel:
total address space = swap + ratio * physical RAM = 0 + 0 *X = 0
raus. Das System hat also keinen Adreßraum zu vergeben. Irre.
Falsch. VM = RAM in diesem Falle, 0+(1.0+0/100.0)*RAM = RAM. Cheers, Th. -- 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 07 Dec 2007, Thomas Hertweck wrote:
Die ausfuehrliche Formel lautet:
address space = swap + (1.0 + overcommit_ratio/100.0) * RAM
OK, das macht Sinn. Ratio gibt also an wieviel % des RAM virtuell nochmal zum Adreßraum dazugerechnet wird. Meine Formel bezog sich auf folgenden Satz aus Documentation/vm/overcommit-accounting: 2 - Don't overcommit. The total address space commit for the system is not permitted to exceed swap + a configurable percentage (default is 50) of physical RAM. Meiner Meinung nach steht da swap + ratio * RAM und nicht swap + RAM + ratio * RAM. Oder liegt das an meinem fehlenden English? Torsten -- A: It reverses the normal flow of conversation. Q: What's wrong with top-posting? A: Top-posting. Q: What's the biggest scourge on plain text email discussions? -- 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 07 Dec 2007, Torsten Foertsch wrote:
On Fri 07 Dec 2007, Thomas Hertweck wrote:
Die ausfuehrliche Formel lautet:
address space = swap + (1.0 + overcommit_ratio/100.0) * RAM
OK, das macht Sinn. Ratio gibt also an wieviel % des RAM virtuell nochmal zum Adreßraum dazugerechnet wird.
Die Formel address space = swap + overcommit_ratio/100 * RAM stimmt doch. Das hier stammt aus mm/mmap.c: allowed = (totalram_pages - hugetlb_total_pages()) * sysctl_overcommit_ratio / 100; /* * Leave the last 3% for root */ if (!cap_sys_admin) allowed -= allowed / 32; allowed += total_swap_pages; Daraufhin habe ich ein System ohne Swap konfiguriert. Swap ist hier eh nur ein zusätzlicher Summand. Die Kiste hat 512 MB RAM. a.out ist im weiteren Thomas' Programm ohne memset, also ohne Zugriffe auf die Seiten, a.out2 das mit memset. Ist nun overcommit_ratio=0, läuft nichts mehr. Fork liefert ENOMEM. Mit overcommit_ratio=100 enden sowohl a.out als auch a.out2 bei 456MB. oom-killer wird nicht aktiv. Mit overcommit_ratio=200 läuft a.out bis 943MB und endet normal. a.out2 wird nach 471MB vom oom-killer gekillt. Ab overcommit_ratio von ca. 104 wird der oom-killer aktiv. Was lehrt uns das? Um den oom-killer zu verhindern, kann man overcommit_ratio bis 100 erhöhen. Über 100 wird er aktiv. Die Diskrepanz zwischen 456MB bei ratio=100 und 471MB bei ratio=104 (oder 200) bedeutet wohl, daß es schon in dieser Minimalinstallation 15MB RAM gibt, die zwar allokiert, aber nie benutzt werden. Wieso nun ratio als Standardwert 50 hat, ist mir ein Rätsel. Torsten -- A: It reverses the normal flow of conversation. Q: What's wrong with top-posting? A: Top-posting. Q: What's the biggest scourge on plain text email discussions? -- 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 wrote:
[...]
Die Formel
address space = swap + overcommit_ratio/100 * RAM
stimmt doch.
Danke fuer die Richtigstellung. Ich glaube, ich geh jetzt mal meine alte RedHat Doku wegschmeissen... Th. -- 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 wrote:
[...]
Die Formel
address space = swap + overcommit_ratio/100 * RAM
stimmt doch.
Ich habe nun nochmal etwas genauer meine alte RedHat Doku studiert, auf denen meine Aussagen aus frueheren Emails beruhten. Da steht wortwoertlich (fuer RHEL; wir haben hier hpts. RedHat Systeme): "For instance, if this value was set to 50, then the kernel would treat a system with 1GB of ram and 1GB of swap as a system with 2.5GB of allocatable memory when considering whether to grant a malloc request from an application." Das scheint allerdings falsch zu sein, denn nach obiger (korrekter) Formel muesste es 1GB + 50/100*1GB = 1GB+0.5GB = 1.5GB sein, nicht 2.5GB. Ich finde das recht verwirrend und entschuldige mich nochmal fuer meine falsche Aussage bzgl. overcommit. Wie ich schon schrieb, die Aussage war nach bestem Wissen und Gewissen - das Gewissen war gut, aber am Wissen haperte es wohl etwas ;-) Dumm, wenn man sich auf offizielle Doku schon nicht mehr verlassen kann. Die restlichen Aussagen zum User Address Space und zu Optimistic Memory Allocation sollten allerdings Bestand haben... Gruesse aus London, Th. -- 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 Mon 10 Dec 2007, Thomas Hertweck wrote:
Da steht wortwoertlich (fuer RHEL; wir haben hier hpts. RedHat Systeme): "For instance, if this value was set to 50, then the kernel would treat a system with 1GB of ram and 1GB of swap as a system with 2.5GB of allocatable memory when considering whether to grant a malloc request from an application." Das scheint allerdings falsch zu sein, denn nach obiger (korrekter) Formel muesste es 1GB + 50/100*1GB = 1GB+0.5GB = 1.5GB sein, nicht 2.5GB.
Diese Beschreibung hatte ich u.a. auch im Internet gefunden und erkannt, daß sie der Doku in den Kernel-Quellen widerspricht. Das war der ursprüngliche Auslöser meiner Mail. Außerdem hatte ich noch verschiedene Ratschläge gelesen, die mal overcommit_ratio=100 mal overcommit_ratio=0 empfahlen, es meist aber gleich wegliesen. Offensichtlich bin ich nicht der einzige, der über die Erklärung gestolpert ist. Torsten -- A: It reverses the normal flow of conversation. Q: What's wrong with top-posting? A: Top-posting. Q: What's the biggest scourge on plain text email discussions? -- 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, 5 Dec 2007 12:34:00 +0100, Torsten Foertsch wrote:
wie stellt man am besten den oom-killer ab?
Warum? Mir fällt kein vernünftiger Grund ein, warum man das wollte, also bin ich neugierig. Philipp -- 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
participants (3)
-
Philipp Thomas
-
Thomas Hertweck
-
Torsten Foertsch