我正在嘗試限制進程的記憶體使用
$ulimit -m 2
$/usr/bin/time -l ./myProcess arg1 arg2
進程運行而不會被殺死,直到time
輸出
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 5
。我也嘗試過這些選項-v
,-l
但它們似乎都沒有真正限制記憶體使用。我還嘗試time
確保它不會無法看到子進程的記憶體使用情況。這是使用 all 後的所有限制-m
,-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
如果我限制 CPU 時間 ( ulimit -t 3
),那麼它可以正常工作並在 3 秒後終止進程。
問題
我有什麼誤解嗎ulimit -m 5
?我的 ulimit 版本有錯嗎?
是否有其他方法可以ulimit
限制進程(不一定是 bash 會話)的時間和記憶體使用?
版本
我在MAC OSX 10.11.6
和bash version 3.2.57
。
相關貼文
帖子“ulimit 不限制內存使用”非常相關,但我認為接受的答案沒有提供任何關於如何解決問題的解決方案
答案1
對於現代 Linux 內核,ulimit
每個版本的意義都變得越來越小。您確實不能使用,-v
因為您的 glibc 版本可能更喜歡加載文件,mmap()
因此您必須設置-v
足夠大以包含該進程將要打開的所有文件。因此,該-v
標誌不能用於限制實體 RAM 使用。
此外,該-m
標誌不執行任何操作,因此它也不能用於限制實體記憶體的使用。
如今,人們必須使用cgroups
核心介面來限制實體 RAM 的使用,但不幸的是,API 有點難以使用。也許有一天,我們有一些類似於 的進程nice
,ionice
它可以限製作為參數給出的進程的記憶體。
理論上,最近systemd
你應該可以做類似的事情
systemd-run --scope --user -p MemoryMax=250M -- /path/to/program/to/use
它應該會神奇地起作用。沒有任何技術原因導致此功能不起作用(因為底層 Linuxcgroup
功能確實支援所需的功能),但某些systemd
版本只會默默地失敗,並且實際上不會限制記憶體使用。如果您想在不終止程式的情況下降低程式的記憶體消耗,您也可以-p MemoryHigh=200M
在選項中新增類似的內容。systemd-run
請注意,超過MemoryHigh
會大大減慢進程速度,因為核心將做額外的工作來回收該進程的所有記憶體(包括快取)以減少記憶體使用。在許多情況下,如果您想強制執行最大限制,則您不希望這樣做。