OOM杀手无法正常工作？

据我了解，当系统接近没有可用内存时，内核应开始终止进程​​以重新获得一些内存。但是在我的系统中这根本不会发生。

假设一个简单的脚本分配的内存比系统中的可用内存多得多（例如，包含数百万个字符串的数组）。如果我以普通用户的身份运行这样的脚本，它将获得所有内存，直到系统完全死机为止（只有SysRQ REISUB可以工作）。

奇怪的是，当计算机死机时，无论是否安装了交换分区，硬盘驱动器指示灯都会打开并一直保持这种状态，直到计算机重新启动为止！

所以我的问题是：

1. 这是正常现象吗？奇怪的是，以普通用户身份执行的应用程序可能会以这种方式使系统崩溃...
2. 有什么办法可以使Ubuntu在内存过多（或最多）时自动杀死那些应用程序？

附加信息

• Ubuntu 12.04.3
• 内核3.5.0-44

• RAM：4GB到3.7GB（与图形卡共享）。*

  $ tail -n+1 /proc/sys/vm/overcommit_*
  ==> /proc/sys/vm/overcommit_memory <==
  0
  
  ==> /proc/sys/vm/overcommit_ratio <==
  50
  
  $ cat /proc/swaps
  Filename                Type        Size    Used    Priority
  /dev/dm-1                               partition   4194300 344696  -1
  

从官方/proc/sys/vm/*文档中：

oom_kill_allocating_task

这在内存不足的情况下启用或禁用杀死OOM触发任务。

如果将其设置为零，则OOM杀手将扫描整个任务列表，并根据启发式方法选择要杀死的任务。通常，这会选择流氓的内存占用任务，该任务在被杀死时会释放大量内存。

如果将其设置为非零，则OOM杀手会简单地杀死触发内存不足情况的任务。这避免了昂贵的任务列表扫描。

如果选择panic_on_oom，它将优先于oom_kill_allocating_task中使用的任何值。

默认值为0。

为了总结，当设置oom_kill_allocating_task到1，而不是扫描您的系统寻找过程杀，这是一个昂贵的和缓慢的任务，内核只会杀死导致系统得到的内存溢出的过程。

根据我自己的经验，当触发OOM时，内核再没有足够的“强度”来进行这种扫描，从而使系统完全无法使用。

此外，杀死导致问题的任务会更加明显，因此我无法理解为什么0默认情况下将其设置为默认值。

为了进行测试，您只需写入中的正确伪文件/proc/sys/vm/，该伪文件将在下次重新启动时撤消：

echo 1 | sudo tee /proc/sys/vm/oom_kill_allocating_task

对于一个永久性的修复，写入以下内容/etc/sysctl.conf或到一个新的文件下/etc/sysctl.d/，具有.conf扩展名（/etc/sysctl.d/local.conf例如）：

vm.oom_kill_allocating_task = 1

更新：该错误已修复。

Teresa的答案足以解决该问题，并且很好。

另外，我已经提交了一个错误报告，因为这肯定是错误的行为。

您可以尝试Earlyoom，它是在用户空间中运行的OOM杀手，可以尝试杀死OOM情况下最大的进程。

首先，我建议更新到13.10（全新安装，保存数据）。

如果您不想更新，请将vm.swappiness更改为10，如果发现ram安装zRAM有问题。