expertenaustausch > comp.os.* > comp.os.unix.linux.misc

Ulli Horlacher (07.07.2018, 01:54)
Auf einem Server hat der OOM Killer zugeschlagen und latuernich einen
wichtigen Prozess erwischt. HMPF.

Um so was in Zukunft auszuschliessen, hab ich vor das Memory Overcommitment
auszuschalten. Lieber soll der Prozess mit Fehler enden, der zu gierig ist.

Ich bin mir aber noch unschluessig, welcher Wert fuer
/proc/sys/vm/overcommit_ratio sinnvoll ist.
Default ist ja 50, was heisst 50% vom RAM werden gar nicht benuetzt.
Warum sollte man das nicht auf 100 setzen?

Der Server hat 16 GB RAM und 16 GB Swap.
Arno Welzel (07.07.2018, 09:43)
Ulli Horlacher:

> Auf einem Server hat der OOM Killer zugeschlagen und latuernich einen
> wichtigen Prozess erwischt. HMPF.
> Um so was in Zukunft auszuschliessen, hab ich vor das Memory Overcommitment
> auszuschalten. Lieber soll der Prozess mit Fehler enden, der zu gierig ist.
> Ich bin mir aber noch unschluessig, welcher Wert fuer
> /proc/sys/vm/overcommit_ratio sinnvoll ist.
> Default ist ja 50, was heisst 50% vom RAM werden gar nicht benuetzt.
> Warum sollte man das nicht auf 100 setzen?


Du musst auch /proc/sys/vm/overcommit_memory beachten. Nur wenn das auf
2 steht, wird overcommit_ratio beachtet. Und der Standard ist 0, nicht 2.

Und ja, 50 für overcommit_ratio bedeutet, dass maximal 50% des
physikalischen RAMs belegt werden dürfen - aber eben nur, wenn
overcommit_memory auf 2 gestellt ist.

Alternativ kannst Du auch overcommit_memory auf 1 stellen, dann gelten
keine Limits mehr und es wird soviel Speicher genutzt, wie möglich. Ggf.
auch den Swap-Space vergrößern, wenn Du Dir nicht sicher bist, ob 32 GB,
wie in deinem Fall, ausreichen.

Mehr dazu auch hier:

<http://engineering.pivotal.io/post/virtual_memory_settings_in_linux_-_the_problem_with_overcommit/>
Ulli Horlacher (07.07.2018, 10:25)
Arno Welzel <usenet> wrote:

> Du musst auch /proc/sys/vm/overcommit_memory beachten. Nur wenn das auf
> 2 steht, wird overcommit_ratio beachtet. Und der Standard ist 0, nicht 2.


Ja, das hatte ich auch implizit mit meinem ersten Satz gemeint.

> Und ja, 50 für overcommit_ratio bedeutet, dass maximal 50% des
> physikalischen RAMs belegt werden dürfen - aber eben nur, wenn
> overcommit_memory auf 2 gestellt ist.


Genau das ist meine Frage: welchen Sinn hat das, NICHT 100% zu nehmen?

> Alternativ kannst Du auch overcommit_memory auf 1 stellen, dann gelten
> keine Limits mehr und es wird soviel Speicher genutzt, wie möglich.


Und wenn es dann trotzdem nicht reicht, schlaegt wieder der OOM Killer zu.
Genau das will ich ja verhindern!

Es soll das Programm einen Fehler bekommen, das zuviel Memory anfordert
und nicht irgendein beliebiger anderer Prozess abgeschossen werden.

> Mehr dazu auch hier:
> <http://engineering.pivotal.io/post/virtual_memory_settings_in_linux_-_the_problem_with_overcommit/>


Da war ich schon. Das erklaert nicht, welche Werte fuer overcommit_ratio
sinnvoll sind und warum.
Arno Welzel (07.07.2018, 10:37)
Ulli Horlacher:

> Arno Welzel <usenet> wrote:
> Ja, das hatte ich auch implizit mit meinem ersten Satz gemeint.
> Genau das ist meine Frage: welchen Sinn hat das, NICHT 100% zu nehmen?


Um auch noch Speicher für Caches zu haben.

>> Alternativ kannst Du auch overcommit_memory auf 1 stellen, dann gelten
>> keine Limits mehr und es wird soviel Speicher genutzt, wie möglich.

> Und wenn es dann trotzdem nicht reicht, schlaegt wieder der OOM Killer zu.
> Genau das will ich ja verhindern!


Dann dieses:

overcommit_memory = 2
overcommit_kbytes = 0

Prozesse, die nicht genug Speicher haben, werden halt einfach abstürzen
oder man kann gar keine neuen Prozesse mehr starten, wenn der Speicher
voll ist - aber der OOM-Killer wird dafür nicht mehr aktiv.

>> <http://engineering.pivotal.io/post/virtual_memory_settings_in_linux_-_the_problem_with_overcommit/>

> Da war ich schon. Das erklaert nicht, welche Werte fuer overcommit_ratio
> sinnvoll sind und warum.


Weil es keinen pauschalen Wert gibt, der sinnvoll wäre - sonst wäre das
nicht konfigurierbar. Es kommt darauf an, ob dein Server viel I/O macht
und der Speicher sinnvoller für Caches genutzt wird oder ob Du lieber
viel Speicher für die Prozesse brauchst usw..

Auch die swappiness ist nicht pauschal mit 10, 30 oder 90 richtig - es
hängt davon ab, wofür das Ding am Ende hauptsächlich genutzt werden soll.

Und letztlich: wenn 16 GB RAM plus 16 GB Swap generell zu wenig ist,
muss da eben mehr rein - mehr Swap oder mehr RAM oder beides. Auch ein
overcommit von 100 verschiebt nur das Problem auf einen späteren
Zeitpunkt, wenn halt noch mehr Speicher belegt ist.
Bastian Blank (07.07.2018, 11:03)
Ulli Horlacher wrote:
> Auf einem Server hat der OOM Killer zugeschlagen und latuernich einen
> wichtigen Prozess erwischt. HMPF.


Die wichtigen[tm] Prozesse laufen aber als root oder setzten andere
OOM-Prioritäten. Die werden damit nur unter sehr kaputten Umständen
gekillt.

> Um so was in Zukunft auszuschliessen, hab ich vor das Memory Overcommitment
> auszuschalten. Lieber soll der Prozess mit Fehler enden, der zu gierig ist.


Wenn das mit deinen Anwendungen kompatibel ist, Glückwunsch.

Viel Zeug alloziert halt einen großen Klumpen Speicher, ohne ihn zu
nutzen oder gar nutzen zu wollen. Für diese Anwendungen brauchst du
Overcommit damit sie überhaupt laufen.

> Ich bin mir aber noch unschluessig, welcher Wert fuer
> /proc/sys/vm/overcommit_ratio sinnvoll ist.
> Default ist ja 50, was heisst 50% vom RAM werden gar nicht benuetzt.


Du solltest eigentlich besser wissen für was so ein übliches System
seinen Speicher nutzt, wenn dort keine Userland-Daten drin liegen.

Bastian
Ulli Horlacher (07.07.2018, 11:29)
Bastian Blank <usenet> wrote:

> > Um so was in Zukunft auszuschliessen, hab ich vor das Memory Overcommitment
> > auszuschalten. Lieber soll der Prozess mit Fehler enden, der zu gierig ist.

> Wenn das mit deinen Anwendungen kompatibel ist, Glückwunsch.


Das wird sich zeigen. Die Programme werden dann schon schreien :-}
Und ich kenne den Schuldigen.

> > Ich bin mir aber noch unschluessig, welcher Wert fuer
> > /proc/sys/vm/overcommit_ratio sinnvoll ist.
> > Default ist ja 50, was heisst 50% vom RAM werden gar nicht benuetzt.

> Du solltest eigentlich besser wissen für was so ein übliches System
> seinen Speicher nutzt, wenn dort keine Userland-Daten drin liegen.


Das beantwortet meine Frage nicht.
Fuer was ist overcommit_ratio ueberhaupt gut?
Warum sollte man nicht allen RAM zur Verfuegung stellen?
Ulli Horlacher (07.07.2018, 11:36)
Arno Welzel <usenet> wrote:

> >> Und ja, 50 für overcommit_ratio bedeutet, dass maximal 50% des
> >> physikalischen RAMs belegt werden dürfen - aber eben nur, wenn
> >> overcommit_memory auf 2 gestellt ist.

> > Genau das ist meine Frage: welchen Sinn hat das, NICHT 100% zu nehmen?

> Um auch noch Speicher für Caches zu haben.


"FS-Cache", das ist die Erklaerung. Ok, das ergibt Sinn :-)

Gut, dann nehm ich erstmal 90 fuer overcommit_ratio und schaue, wie sich
das System damit verhaelt.
Helmut Waitzmann (07.07.2018, 12:38)
Ulli Horlacher <framstag>:
>Auf einem Server hat der OOM Killer zugeschlagen und latuernich einen
>wichtigen Prozess erwischt. HMPF.
>Um so was in Zukunft auszuschliessen, hab ich vor das Memory Overcommitment
>auszuschalten. Lieber soll der Prozess mit Fehler enden, der zu gierig ist.
>Ich bin mir aber noch unschluessig, welcher Wert fuer
>/proc/sys/vm/overcommit_ratio sinnvoll ist.
>Default ist ja 50, was heisst 50% vom RAM werden gar nicht benuetzt.
>Warum sollte man das nicht auf 100 setzen?


Ich bin mir nicht sicher:

Schreibt Linux RAM?Inhalte auch schon vorbeugend ins Swap? Werden
also RAM?Inhalte, die schon einige Zeit nicht mehr angefasst
wurden, schon mal ins Swap geschrieben, wenn das Swap?Device
gerade nichts zu tun hat, obwohl freies RAM im Augenblick nicht
knapp ist?

So ein Verhalten könnte das Beschaffen von RAM, wenn es mal nötig
wird, beschleunigen.

Falls Linux so vorbeugend arbeitet, könnte es das mit

»overcommit_ratio = 100?%«

im Fall, dass dem System der virtuelle Speicher knapp wird, nicht
mehr tun: RAM?Inhalte werden erst dann ins Swap geschrieben, wenn
das RAM anderweitig gebraucht wird.

Von daher könnte man sich, wenn man das vorbeugende
Herausschreiben schätzt, sogar für

»overcommit_ratio = 0?%«

entscheiden. Achtung! Das sollte man erst dann tun, wenn das
Swap?Space mit »swapon« zur Verfügung steht, und beim
Herunterfahren auch wieder abändern, bevor man das Swap?Space
entfernt.

Wenn ich das alles richtig verstehe, ist

»overcommit_ratio = 0?%«

auch Voraussetzung dafür, dass Suspend to Disk in jedem Fall
funktioniert.

>Der Server hat 16 GB RAM und 16 GB Swap.


Wenn Du ihm noch 8?GB Swap zusätzlich spendierst, hat er mit

»overcommit_ratio = 0?%«

genau so viel virtuellen Speicher zur Verfügung wie zuvor mit

»overcommit_ratio = 50?%«.
Tim Ritberg (07.07.2018, 14:22)
Am 07.07.2018 um 12:38 schrieb Helmut Waitzmann:
> Ulli Horlacher <framstag>:
> Ich bin mir nicht sicher:
> Schreibt Linux RAM?Inhalte auch schon vorbeugend ins Swap?

Das dürfte dann die "swappiness" sein.
cat /proc/sys/vm/swappiness

Tim
Helmut Waitzmann (07.07.2018, 21:47)
Tim Ritberg <tim>:
>Am 07.07.2018 um 12:38 schrieb Helmut Waitzmann:


>> Schreibt Linux RAM?Inhalte auch schon vorbeugend ins Swap?

>Das dürfte dann die "swappiness" sein.
>cat /proc/sys/vm/swappiness


Swappiness beeinflusst die Antwort auf die Frage, welche
Hauptspeicherseiten bei Hauptspeicherknappheit ins Swap
ausgelagert werden: Hauptspeicherseiten, die Arbeitsspeicher
eines Prozesses sind, oder lieber Hauptspeicherseiten, die Kopien
eines Datei? oder Verzeichnis?Inhalts sind?

Je niedriger man »/proc/sys/vm/swappiness« setzt, desto mehr
schreckt der Betriebssystemkern davor zurück, Hauptspeicherseiten,
die Arbeitsspeicher eines Prozesses sind, auszulagern. Statt
dessen versucht er erst, den Hauptspeicherhunger mit dem Auslagern
von page cache zu stillen.

Siehe dazu auch <https://lwn.net/Articles/83588/>.
Helmut Waitzmann (07.07.2018, 23:01)
Ulli Horlacher <framstag>:

>Ich bin mir aber noch unschluessig, welcher Wert fuer
>/proc/sys/vm/overcommit_ratio sinnvoll ist.
>Default ist ja 50, was heisst 50% vom RAM werden gar nicht benuetzt.


Die werden schon benutzt, selbst wenn man es auf 0?% setzt.

»/proc/sys/vm/overcommit_ratio« beantwortet nur die Frage, wieviel
virtuellen Speicher das Betriebssystem an alle Prozesse insgesamt
vergibt, bis es weitere Speicherwünsche von Prozessen ablehnt.

>Warum sollte man das nicht auf 100 setzen?
>Der Server hat 16 GB RAM und 16 GB Swap.


Angenommen »/proc/sys/vm/overcommit_ratio« steht auf 100?%. Dann
kann das System knapp 32?GB virtuellen Speicher an Prozesse
vergeben (ein wenig wird es auch selber noch behalten wollen).

Szenario: Das System hat nahezu allen virtuellen Speicher
vergeben. 90?% des virtuellen Speichers werden im Augenblick vom
Prozessor nicht angefasst, weil die Prozesse, denen sie gehören,
gerade schlafen.

Von den 50?% des virtuellen Speichers, die im Haupspeicher liegen,
werden also 80?% ( = 40?% des insgesamt verfügbaren virtuellen
Speichers) im Augenblick nicht angefasst und könnten problemlos
(vorbeugend) ausgelagert werden. Nur ist das nicht möglich, weil
es keinen freien Swap mehr gibt.

Wenn jetzt ein Prozess virtuellen Speicher, der im Swap liegt,
anfassen will, muss das Betriebssystem erst einen Teil des sich im
Hauptspeicher befindenden virtuellen Speichers auslagern, um Platz
zum Hereinholen des virtuellen Speichers zu schaffen: Das Swap
bekommt gleichzeitig Arbeit sowohl zum Schreiben als auch zum
Lesen.

Anderes Szenario: gleicher virtueller Speicherbedarf wie oben,
aber jetzt seien statt 16?GB 32?GB Swap installiert, und
»/proc/sys/vm/overcommit_ratio« steht auf 0?%. Dann steht dem
System die gleiche Menge virtueller Speicher wie oben zur
Verfügung. Und wieder werden 90?% des virtuellen Speichers im
Augenblick vom Prozessor nicht angefasst, weil die Prozesse, denen
sie gehören, gerade schlafen.

Diese 90?% des virtuellen Speichers können problemlos (vorbeugend)
ausgelagert werden, weil sie im Augenblick nicht angefasst werden.

Und das ist möglich, weil es nicht mehr virtuellen Speicher als
Swap gibt. Also tut das das Betriebssystem auch, weil das
Swap?Device gerade nichts anderes zu tun hat.

Wenn jetzt ein Prozess virtuellen Speicher, der im Swap liegt,
anfassen will, braucht das Betriebssystem nur einen Teil des sich
im Hauptspeicher befindenden virtuellen Speichers herzunehmen und
mit dem Inhalt des in den Swap ausgelagerten virtuellen Speichers
zu füllen: Ins Swap muss nicht geschrieben werden, weil der
Hauptspeicher, der jetzt überschrieben werden soll, bereits
vorbeugend ins Swap geschrieben worden war: Das Swap bekommt
Arbeit nur zum Lesen.

»/proc/sys/vm/overcommit_ratio = 0« mit gleichzeitigem
entsprechend größerem Swap macht es möglich, vorbeugend
auszulagern und so gleichzeitiges Lesen vom Swap und Schreiben ins
Swap zu vermeiden. Das System läuft mit derselben Menge RAM und
demselben Bedarf an virtuellem Speicher flüssiger als vorher.
Helmut Waitzmann (07.07.2018, 23:37)
Ulli Horlacher <framstag>:

>Ich bin mir aber noch unschluessig, welcher Wert fuer
>/proc/sys/vm/overcommit_ratio sinnvoll ist.
>Default ist ja 50, was heisst 50% vom RAM werden gar nicht benuetzt.


Die werden schon benutzt, selbst wenn man es auf 0?% setzt.

»/proc/sys/vm/overcommit_ratio« beantwortet nur die Frage, wieviel
virtuellen Speicher das Betriebssystem an alle Prozesse insgesamt
vergibt, bis es weitere Speicherwünsche von Prozessen ablehnt.

>Warum sollte man das nicht auf 100 setzen?
>Der Server hat 16 GB RAM und 16 GB Swap.


Angenommen »/proc/sys/vm/overcommit_ratio« steht auf 100?%. Dann
kann das System knapp 32?GB virtuellen Speicher an Prozesse
vergeben (ein wenig wird es auch selber noch behalten wollen).

Erstes Szenario: Das System hat nahezu allen virtuellen Speicher
vergeben. 90?% des virtuellen Speichers werden im Augenblick vom
Prozessor nicht angefasst, weil die Prozesse, denen sie gehören,
gerade schlafen.

Von den 50?% des virtuellen Speichers, die im Haupspeicher liegen,
werden also 80?% ( = 40?% des insgesamt verfügbaren virtuellen
Speichers) im Augenblick nicht angefasst und könnten problemlos
(vorbeugend) ausgelagert werden. Nur ist das nicht möglich, weil
es keinen freien Swap mehr gibt.

Wenn jetzt ein Prozess virtuellen Speicher, der im Swap liegt,
anfassen will, muss das Betriebssystem erst einen Teil des sich im
Hauptspeicher befindenden virtuellen Speichers auslagern, um Platz
zum Hereinholen des virtuellen Speichers zu schaffen: Das Swap
bekommt gleichzeitig Arbeit sowohl zum Schreiben als auch zum
Lesen.

Zweites Szenario: gleicher virtueller Speicherbedarf wie oben,
aber jetzt seien statt 16?GB 32?GB Swap installiert, und
»/proc/sys/vm/overcommit_ratio« steht auf 0?%. Dann steht dem
System die gleiche Menge virtueller Speicher wie oben zur
Verfügung. Und wieder werden 90?% des virtuellen Speichers im
Augenblick vom Prozessor nicht angefasst, weil die Prozesse, denen
sie gehören, gerade schlafen.

Diese 90?% des virtuellen Speichers können problemlos (vorbeugend)
ausgelagert werden, weil sie im Augenblick nicht angefasst werden.

Und das ist möglich, weil es nicht mehr virtuellen Speicher als
Swap gibt. Also tut das das Betriebssystem auch, weil das
Swap?Device gerade nichts anderes zu tun hat.

Wenn jetzt ein Prozess virtuellen Speicher, der im Swap liegt,
anfassen will, braucht das Betriebssystem nur einen Teil des sich
im Hauptspeicher befindenden virtuellen Speichers herzunehmen und
mit dem Inhalt des in den Swap ausgelagerten virtuellen Speichers
zu füllen: Ins Swap muss nicht geschrieben werden, weil der
Hauptspeicher, der jetzt überschrieben werden soll, bereits
vorbeugend ins Swap geschrieben worden war: Das Swap bekommt
Arbeit nur zum Lesen.

»/proc/sys/vm/overcommit_ratio = 0« mit gleichzeitigem
entsprechend größerem Swap macht es möglich, vorbeugend
auszulagern und so gleichzeitiges Lesen vom Swap und Schreiben ins
Swap zu vermeiden. Das System läuft mit derselben Menge RAM und
demselben Bedarf an virtuellem Speicher flüssiger als vorher.

Drittes Szenario: gleicher virtueller Speicherbedarf wie oben,
jetzt seien wieder statt 16?GB 32?GB Swap installiert, und
»/proc/sys/vm/overcommit_ratio« steht auf 100?%.

Worin besteht jetzt der Unterschied zum zweiten Szenario? Darin,
dass das System jetzt noch weitere 16?GB virtuellen Speicher an
Prozesse vergeben könnte, wo das System im ersten oder zweiten
Szenario bereits weitere Speicheranforderung ablehnen müsste.

Anders ausgedrückt: Mit »/proc/sys/vm/overcommit_ratio = 100« und
derselben Menge an RAM und Swap wie im zweiten Szenario hat das
System mehr virtuellen Speicher zur Verfügung, kann aber, wenn es
dieses Mehr an virtuellem Speicher nutzt, in Situationen kommen,
in denen es nicht umhin kommt, gleichzeitig vom Swap zu lesen und
in es zu schreiben, Situationen, die im zweiten Szenario nicht
vorkommen, weil das System da bereits die Herausgabe weiteren
virtuellen Speichers ablehnt.

Wenn Du also problemlos mehr Swap zur Verfügung stellen kannst, tu
es und setze dafür »/proc/sys/vm/overcommit_ratio = 0«.
Arno Welzel (08.07.2018, 02:59)
Helmut Waitzmann:

> Ulli Horlacher <framstag>:
> Ich bin mir nicht sicher:
> Schreibt Linux RAM?Inhalte auch schon vorbeugend ins Swap? Werden
> also RAM?Inhalte, die schon einige Zeit nicht mehr angefasst
> wurden, schon mal ins Swap geschrieben, wenn das Swap?Device
> gerade nichts zu tun hat, obwohl freies RAM im Augenblick nicht
> knapp ist?


Ja. Das wird über /proc/sys/vm/swappiness geregelt. Siehe dazu z.B.:

<https://debian-blog.org/linux-swappiness/>
Tim Ritberg (08.07.2018, 12:06)
Am 07.07.2018 um 21:47 schrieb Helmut Waitzmann:
> Tim Ritberg <tim>:
> Swappiness beeinflusst die Antwort auf die Frage, welche
> Hauptspeicherseiten bei Hauptspeicherknappheit ins Swap
> ausgelagert werden: ...


Nein, das ist auch wie du fragtest "vorbeugend". Das hast nichts mit
Knappheit zu tun.

Helmut Waitzmann (08.07.2018, 13:45)
Tim Ritberg <tim>:
>Am 07.07.2018 um 21:47 schrieb Helmut Waitzmann:
>> Tim Ritberg <tim>:
>>> Am 07.07.2018 um 12:38 schrieb Helmut Waitzmann:


>>>> Schreibt Linux RAM?Inhalte auch schon vorbeugend ins Swap?


>>> Das dürfte dann die "swappiness" sein.
>>> cat /proc/sys/vm/swappiness

>> Swappiness beeinflusst die Antwort auf die Frage, welche
>> Hauptspeicherseiten bei Hauptspeicherknappheit ins Swap
>> ausgelagert werden: ...


Da habe ich wohl ein Missverständnis verursacht: Ich habe die
Frage zu eng gestellt. Eigentlich wollte ich fragen: Schreibt
Linux RAM?Inhalte auch schon vorbeugend auf die Massenspeicher?

>Nein, das ist auch wie du fragtest "vorbeugend". Das hast nichts
>mit Knappheit zu tun.


Das hört sich in <https://lwn.net/Articles/83588/> ganz anders
an. Zitat:

So... swappiness, which is exported to /proc/sys/vm/swappiness,
is a parameter which sets the kernel's balance between
reclaiming pages from the page cache and swapping out process
memory.

Dort ist davon die Rede, dass Rechnernutzer verärgert sind, wenn
ihr OpenOffice am Morgen nicht mehr im Hauptspeicher sondern nur
noch im Swap liegt, weil ein Backup?Programm über Nacht das
Betriebssystem veranlasst hat, virtuellen Speicher ins Swap zu
schreiben, um freien Hauptspeicher für page cache (Datei? und
Verzeichnisinhalte) zu gewinnen. Würde »/proc/sys/vm/swappiness«
nur beeinflussen, ob vorbeugend oder erst bei akutem
Hauptspeichermangel ausgeswappt würde, würde
»/proc/sys/vm/swappiness« auf sehr kleine Werte zu setzen den
verärgerten Rechnernutzern nicht helfen: Ob virtueller Speicher
bereits vorbeugend oder erst bei Hauptspeicherknappheit ins Swap
geschrieben wird, spielt im Fall, dass der Hauptspeicher knapp
wird, zur Frage, ob virtueller Speicher aus dem Hauptspeicher
entfernt wird, einerseits keine Rolle mehr. Andererseits
bedeutet, dass virtueller Speicher vorbeugend ins Swap geschrieben
wird, nicht automatisch, dass er aus dem Hauptspeicher entfernt
wird.

>


Zitat:

swappiness

This control is used to define how aggressive the kernel will
swap memory pages. Higher values will increase aggressiveness,
lower values decrease the amount of swap. A value of 0
instructs the kernel not to initiate swap until the amount of
free and file-backed pages is less than the high water mark in a
zone.

The default value is 60.

Von »vorbeugend« ist da nicht die Rede, sondern von »aggressive«.

Ähnliche Themen