避免Linux内存不足的应用程序被拆卸

我发现偶尔我的Linux机器内存不足,它开始拆除随机进程来处理它。

我很好奇pipe理员要做什么来避免这种情况? 是唯一真正的解决scheme来增加内存的数量(单独增加交换帮助吗?),还是有更好的方法来设置软件框,以避免这种情况? (即配额,还是这样的?)。

默认情况下,Linux在内存pipe理方面存在一些大脑受损的概念:它可以让你分配比系统更多的内存,然后在出现问题时随机拍摄一个进程。 (被杀死的实际语义比这更复杂 – 谷歌的“Linux OOM杀手”有很多关于这是好是坏的细节和争论)。


为了让你的memory management恢复一些理智:

  1. 禁用OOM杀手(把/etc/sysctl.conf中的vm.oom-kill = 0
  2. 禁用内存过量使用(将/etc/sysctl.conf中的vm.overcommit_memory = 2
    请注意,这是一个三元值:0 =“估计是否有足够的内存”,1 =“总是说是”,2 =“如果我们没有内存,则说”否)

这些设置将使Linux以传统方式运行(如果进程请求的内存超过可用的malloc()将失败,并且请求内存的进程需要处理该故障)。

重新启动你的机器,使其重新加载/etc/sysctl.conf ,或使用proc文件系统立即启用,无需重启:

 echo 2 > /proc/sys/vm/overcommit_memory 

服务器的简短答案是购买并安装更多的RAM。

一个经常发生OOM (内存不足)错误的服务器,除了Linux内核中的VM(虚拟内存)pipe理器的overcommit sysctl选项之外,这不是一件好事。

如果当前值较低,则增加交换量(由内核的内存pipe理器分页到磁盘的虚拟内存)将有所帮助,并且使用涉及许多任务,每个如此大量的内存,而不是一个或几个每个进程请求大量可用的总虚拟内存(RAM +交换)。

对于分配两次以上(2x)RAM数量的许多应用程序,交换提供了递减的改进回报。 在一些大型计算模拟中,如果速度减慢是可承受的,则这可能是可以接受的。

使用内存(不pipe是否使用ECC)对于数量适中的应用程序来说是相当实惠的,例如4-16 GB,但是我不得不承认,我自己很久没有遇到过这个问题。

查看内存消耗的基础知识,包括使用freetop (按内存使用情况sorting)作为内存使用模式的两种最常见的快速评估。 所以要确保你至less理解这些命令输出中每个字段的含义。

由于没有具体的应用程序(如数据库,networking服务服务器,实时video处理)和服务器的使用情况(很less有用户,100-1000用户/客户端连接),我不能想到任何关于处理OOM问题。

在任何情况下增加物理内存的数量可能都不是有效的回应。

一个方法来检查这是'atop'命令。 特别是这两条线。

这是服务器,当它是健康的:

 MEM | tot 23.7G | free 10.0G | cache 3.9G | buff 185.4M | slab 207.8M | SWP | tot 5.7G | free 5.7G | | vmcom 28.1G | vmlim 27.0G | 

当它运行不良(并且在我们将overcommit_memory从50调整到90之前,我们会看到vmcom超过50G运行的情况,每隔几秒钟就会消耗一些进程,并且由于NFSdsubprocess崩溃,负载也会大幅度地反弹并不断重新创build。

我们最近重复了多用户Linuxterminal服务器大量过度提交虚拟内存分配的情况,但实际上只有极less数请求的页面被实际使用。

虽然不build议遵循这个确切的路线,但是我们将overcommit-memory从默认的50到90调整了,这减轻了一些问题。 我们最终不得不将所有用户移动到另一台terminal服务器,然后重新启动才能看到完整的好处。

您可以使用ulimit来减less进程在被杀死之前可以声明的内存量。 这是非常有用的,如果你的问题是一个或几个失控的进程崩溃你的服务器。

如果你的问题是你没有足够的内存来运行你需要的服务,那么只有三个解决scheme:

  1. 通过限制caching等来减less服务使用的内存

  2. 创build一个更大的交换区域。 这会花费你的performance,但可以给你一些时间。

  3. 购买更多的内存

我有类似的问题相关的这个错误 ,解决scheme是使用较旧/较新(固定)的内核。

然而,当时我无法重新启动我的机器,所以某种丑陋的解决方法是以root身份login并使用此命令清除系统caching:

 echo 3 > /proc/sys/vm/drop_caches 

@ voretaq7 linux没有脑损坏的内存pipe理的概念,默认情况下vm.overcommit_ratio是0,

 0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slightly more memory in this mode. This is the default. 

这样,如果你有4GB的RAM,而你尝试用虚拟内存的malloc分配4.2GB,你的分配将失败。

随着vm.overcommit_ratio = 1

  1 - Always overcommit. Appropriate for some scientific applications. Classic example is code using sparse arrays and just relying on the virtual memory consisting almost entirely of zero pages. 

用vm.overcommit_ratio = 2

  2 - Don't overcommit. The total address space commit for the system is not permitted to exceed swap + a configurable percentage (default is 50) of physical RAM. Depending on the percentage you use, in most situations this means a process will not be killed while accessing pages but will receive errors on memory allocation as appropriate. Useful for applications that want to guarantee their memory allocations will be available in the future without having to initialize every page. 

所以默认情况下,linux不会过度使用,如果你的应用程序有更多的内存,那么你的代码可能就是bug了