我当前的配置是：
> cat /proc/sys/vm/panic_on_oom 0 > cat /proc/sys/vm/oom_kill_allocating_task 0 > cat /proc/sys/vm/overcommit_memory 1
但是当我执行任务时，它还是被杀死了。
> ./test/mem.sh Killed > dmesg | tail -2 [24281.788131] Memory cgroup out of memory: Kill process 10565 (bash) score 1001 or sacrifice child [24281.788133] Killed process 10565 (bash) total-vm:12601088kB, anon-rss:5242544kB, file-rss:64kB
我的任务习惯于科学计算，这会花费很多记忆，看来这overcommit_memory=1可能是最佳选择。
overcommit_memory=1
实际上，我正在从事一个数据分析项目，该项目花费的内存多于16G，但是我被要求将其限制在左右5G。通过优化程序本身来实现此要求可能是不可能的，因为该项目使用许多子命令，并且其中大多数不包含Java Xms或XmxJava 中的选项。
16G
5G
Xms
Xmx
我的项目应该是一个过度使用的系统。就像所说的那样，似乎我的应用程序更喜欢xmalloc在mem分配失败时崩溃。
xmalloc
> cat /proc/sys/vm/overcommit_memory 2 > ./test/mem.sh ./test/mem.sh: xmalloc: .././subst.c:3542: cannot allocate 1073741825 bytes (4295237632 bytes allocated)
我不想投降，尽管如此多的考验使我筋疲力尽。所以，请给我看看通往光明之路; ）
OOM杀手不会消失。如果没有记忆，则必须付费。您可以做的是设置一个限制，在此限制之后内存分配将失败。这正是vm.overcommit_memory要2实现的设置。
vm.overcommit_memory
2
从文档：
Linux内核支持以下过量使用处理模式 2-不要过度使用。不允许为系统分配的总地址空间超过swap +物理RAM的可配置量（默认为50％）。在大多数情况下，这取决于您使用的数量，这意味着进程在访问页面时不会被杀死，但是会在适当的分配内存时收到错误。
Linux内核支持以下过量使用处理模式
2-不要过度使用。不允许为系统分配的总地址空间超过swap +物理RAM的可配置量（默认为50％）。在大多数情况下，这取决于您使用的数量，这意味着进程在访问页面时不会被杀死，但是会在适当的分配内存时收到错误。
通常，内核会很乐意分发虚拟内存（过量使用）。仅当您引用页面时，内核才必须将页面映射到真实的物理框架。如果无法满足该请求，则需要由OOM杀手杀死一个进程以腾出空间。
禁用过量使用意味着如果内核无法提交所请求的内存量，eg malloc(3)将返回NULL。这使事情更具可预测性，尽管有局限性（许多应用程序分配的资源超出了他们的需要）。
malloc(3)
NULL
