与这个问题类似，我们有一个96GB RAM的计算服务器，用于并行运行大型作业。
偶尔会超出物理RAM的总量，导致服务器无响应，从而导致重新启动。 对我来说，这是不可接受的行为，所以我正在寻找方法来解决这个问题。
我知道一种方法是使用“ulimit -v”设置限制。 但是，如果可能的话，我想避免沿着这条路线走，因为偶尔会有一个非常大的过程（而不是很多小过程），所以设置一个有用的阈值将是困难的。
我怀疑这个问题可能来自系统有20GB交换的事实：而不是杀死有问题的进程，系统会在磁盘上分配内存，使其无响应。 减less交换量是一个好主意？
任何有关类似问题的见解或经验高度赞赏！
编辑
我使用以下泄漏的C ++程序做了一些实验：
#include <vector> #include <unistd.h> using namespace std; int main(int argc,char * argv[]) { while(true) { vector<double>* a = new vector<double>(50000000); sleep(1); } } 我第一次用256MB的交换文件运行它。 系统完全挂了5分钟左右，比起了生机。 在日志中，我看到OOM杀手已经成功地杀死了我的漏洞程序。
我第二次运行它，没有交换。 这一次，机器至less还没有恢复到十分钟，此时我重新启动了机器。 这对我来说是一个惊喜，因为我期望OOM杀手能够在一台没有交换机器的机器上提前开火。
我不明白的是：为什么linux要等到系统完全挂起来才能对违规进程做些什么？ 期望一个操作系统不会被一个严重编码的程序完全杀死，是否太多了？
如果你希望你的服务器仍然能够响应，你需要尽力避免交换。 但是，减less交换金额或禁用它不会解决您的问题。
你需要控制你的工作内存使用情况，或者在服务器上安装更多的内存。
您可以尝试cgroups （控制组）来控制您的进程CPU和内存使用情况。
你有/ var / log / messages中的oom日志。
我build议检查/proc/meminfo并在高峰使用时间监视它。 Committed_AS参数显示当内核允许所有进程的所有内存请求时，需要多less内存。 如果该值低于可用内存，那么系统最终有可能会出现OOM。
一如既往，适应硬件可以容纳的工作量。 最好增加内存或减less工作量。