当我使用默认设置时:
vm.overcommit_memory = 0 vm.overcommit_ratio = 50
我可以从/proc/meminfo
文件读取这些值:
CommitLimit: 2609604 kB Committed_AS: 1579976 kB
但是,当我将vm.overcommit_memory
从0
更改为2
,我无法启动在更改之前启动的同一组应用程序,特别是amarok。 我必须将vm.overcommit_ratio
更改为300
,因此可以增加限制。 现在,当我启动amarok时, /proc/meminfo
显示如下:
CommitLimit: 5171884 kB Committed_AS: 3929668 kB
这台机器只有1GiB的RAM,但是当vm.overcommit_memory
设置为0时,amarok没有问题。但是在设置为2
的情况下,amarok需要分配超过2GiB的内存。 这是一个正常的行为? 如果是这样,任何人都可以解释为什么,例如,firefox(消耗比amarok多4-6倍的内存)在更改之前和之后以相同的方式工作?
您可以在man 5 proc
( 或kernel.org )中find文档:
该文件包含内核虚拟内存记帐模式。 价值观是:
0: heuristic overcommit (this is the default) 1: always overcommit, never check 2: always check, never overcommit
在模式0中,不检查具有
MAP_NORESERVE
的mmap(2)
调用,并且默认检查非常弱,导致获得进程“OOM杀死”的风险。 在Linux 2.4下,任何非零值都意味着模式1。在模式2(从Linux 2.6起可用)中,系统上的总虚拟地址空间限制为(SS + RAM *(r / 100)),其中“SS”是交换空间的大小,RAM是大小的物理内存,“r”是文件
/proc/sys/vm/overcommit_ratio
。
简单的答案是设置overcommit为1,将设置阶段,以便当程序调用类似malloc()
来分配一块内存( man 3 malloc
)时,无论系统是否知道它将不会有所有正在被请求的内存。
要理解的基本概念是虚拟内存的概念。 程序看到一个虚拟地址空间,可能或不可能被映射到实际的物理内存。 通过禁用overcommit检查,您告诉操作系统假设总是有足够的物理内存来备份虚拟空间。
为了强调为什么有时候这很重要,请查看Redis指南 ,了解为什么vm.overcommit_memory
应该设置为1。