Ich versuche, den Speicherverbrauch eines Prozesses zu begrenzen
$ulimit -m 2
$/usr/bin/time -l ./myProcess arg1 arg2
Der Prozess wird ohne Abbruch ausgeführt, bis timedie Ausgabe
7.00 real 4.83 user 2.16 sys
4154855424 maximum resident set size
0 average shared memory size
0 average unshared data size
0 average unshared stack size
1014384 page reclaims
0 page faults
0 swaps
0 block input operations
2 block output operations
0 messages sent
0 messages received
0 signals received
0 voluntary context switches
15 involuntary context switches
ulimit -m 5zeigt an, dass das Limit trotz der Befehlszeile überschritten wurde . Ich habe auch die Optionen ausprobiert -v, -laber keine davon scheint den Speicherverbrauch tatsächlich zu begrenzen. Ich habe auch versucht, timesicherzustellen, dass der Speicherverbrauch eines Unterprozesses nicht übersehen wird. Hier sind alle Limits nach Verwendung von all -mund-v-l
$ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 3
max memory size (kbytes, -m) 2
open files (-n) 256
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 709
virtual memory (kbytes, -v) 2
Wenn ich die CPU-Zeit begrenze ( ulimit -t 3), funktioniert es einwandfrei und beendet den Prozess nach 3 Sekunden.
Frage
Habe ich da etwas falsch verstanden ulimit -m 5? Liegt in meiner ulimit-Version ein Fehler vor?
Gibt es eine Alternative, um ulimitdie Zeit und den Speicherverbrauch eines Prozesses (nicht unbedingt der Bash-Sitzung) zu begrenzen?
Versionen
Ich bin auf MAC OSX 10.11.6und bash version 3.2.57.
Verwandter Post
Der Beitrag „ulimit begrenzt die Speichernutzung nicht“ist sehr verwandt, aber ich glaube nicht, dass die akzeptierte Antwort eine Lösung zur Lösung des Problems bietet
Antwort1
Bei modernen Linux-Kerneln ulimitwird dies mit jeder Version weniger sinnvoll. Sie können es wirklich nicht verwenden, -vda Ihre Version von glibc möglicherweise das Laden von Dateien mit bevorzugt . mmap()Sie müssen es also groß genug einstellen, -vum alle Dateien einzuschließen, die der Prozess öffnen wird. Daher kann das -vFlag nicht verwendet werden, um die physische RAM-Nutzung zu begrenzen.
Darüber hinaus -mhat das Flag keine Funktion und kann daher auch nicht zur Begrenzung der physischen Speichernutzung verwendet werden.
Heutzutage muss man cgroupsdie Schnittstelle zum Kernel verwenden, um die physische RAM-Nutzung zu begrenzen, aber die API ist leider etwas schwierig zu verwenden. Vielleicht haben wir eines Tages einen ähnlichen Prozess, niceder ioniceden Speicher für einen als Parameter angegebenen Prozess begrenzen kann.
Theoretisch systemdsollten Sie mit ausreichend aktuellem Material in der Lage sein, so etwas zu tun wie
systemd-run --scope --user -p MemoryMax=250M -- /path/to/program/to/use
und es sollte wie von Zauberhand funktionieren. Es gibt keinen technischen Grund, warum dies nicht funktionieren sollte (da die zugrunde liegende Linux- cgroupFunktion die erforderlichen Dinge unterstützt), aber einige systemdVersionen schlagen einfach stillschweigend fehl und begrenzen die Speichernutzung nicht wirklich. Sie können -p MemoryHigh=200Mden systemd-runOptionen auch etwas wie hinzufügen, wenn Sie das Programm dazu bringen möchten, den Speicherverbrauch zu senken, ohne es zu beenden. Beachten Sie jedoch, dass eine Überschreitung MemoryHighden Prozess erheblich verlangsamt, da der Kernel zusätzliche Arbeit leisten wird, um den gesamten Speicher (einschließlich Caches) von diesem Prozess zurückzufordern und die Speichernutzung zu reduzieren. In vielen Fällen möchten Sie dies nicht, wenn Sie die maximale Grenze durchsetzen möchten.