![Linux 中的空闲内存或可用内存是 OOM 杀手的触发因素吗?](https://linux22.com/image/226670/Linux%20%E4%B8%AD%E7%9A%84%E7%A9%BA%E9%97%B2%E5%86%85%E5%AD%98%E6%88%96%E5%8F%AF%E7%94%A8%E5%86%85%E5%AD%98%E6%98%AF%20OOM%20%E6%9D%80%E6%89%8B%E7%9A%84%E8%A7%A6%E5%8F%91%E5%9B%A0%E7%B4%A0%E5%90%97%EF%BC%9F.png)
我正在开发一个基于 SOC 平台的嵌入式 Linux 系统。
我有两台机器运行相同的内存工作负载,并且得到以下内存输出。
机器1.
total used free shared buff/cache available
Mem: 50616 35304 2516 48 12796 13100
Swap: 0 0 0
机器2.
total used free shared buff/cache available
Mem: 57328 45320 2856 56 9152 9572
Swap: 0 0 0
机器1的内存比机器2少free
,但是机器1的内存比机器2多available
。在这种情况下,哪台机器触发OOM Killer的风险更高?
有内存调整建议吗?
通过设置 overcommit_memory 进行了更新(有点题外话)
根据 Fritz 的回答,在另一个系统中,我将 更改overcommit_memory
为 2,没有其他更改,我得到了关注。
# cat /proc/sys/vm/overcommit_ratio
50
#
# free
total used free shared buff/cache available
Mem: 84244 25256 35196 92 23792 56772
Swap: 0 0 0
# echo 2 > /proc/sys/vm/overcommit_memory
#
# ls
-/bin/sh: can't fork: Cannot allocate memory
比率是50,但是它表示cannot allocate memory
禁用内存过量使用时。
即使echo 100 > /proc/sys/vm/overcommit_ratio
,当echo 2 > /proc/sys/vm/overcommit_memory
,它仍然遇到错误,我不得不重新启动系统。
因此,根据我的测试,更改内存过度使用可能不会出现pre-defined
分段错误。
我已经接受了 Fritz 关于内核内存回收的回答available
和free
。
我们可以再开一个问题来讨论Linux内存过量使用。
答案1
free
内存完全未使用,而available
如果需要内存可以立即被内核释放。它包含文件系统缓存等内容,避免从磁盘读取并加快系统速度。如果你仔细观察,你会发现金额available
与 类似buff/cache
。
因此,内核应该available
除非内存耗尽,否则不会调用 OOM Killer 。
正如安德鲁在评论中指出的那样:安全的选择是禁用内核中内存的过度使用。这样,当程序请求的内存多于当前可用的内存时,调用malloc
将返回NULL
而不是成功。这意味着分配的内存永远不会多于实际可用的内存,因此 OOM 杀手(希望)永远不会被调用:
# Assuming swap is disabled because it is an embedded system:
echo 100 > /proc/sys/vm/overcommit_ratio # Commit max 100% of physical RAM (+ Swap, which is off)
echo 2 > /proc/sys/vm/overcommit_memory # Disable overcommit heuristics
但是,这要求 (a) 您的程序请求的内存不超过其打算使用的内存,并且 (b) 检查所有malloc
调用的返回值并执行某些操作明智的当他们回来时NULL
。否则,您将面临与 OOM 杀手相同的行为(您的进程随机死亡),在这种情况下是由于段错误/空取消引用。
如果没有有关您所面临的特定场景的信息,就很难提供更多调整建议。但是,如果物理内存在过度使用时耗尽,那么内核除了以下之外无能为力:交换,杀死一个进程, 或者惊慌失措。您可以尝试启用zram
或者 zswap
(因此“交换”到 RAM)或添加swapfile
,但是当内存(几乎)已满时,两者都可能会降低系统性能。最好确保您的应用程序没有内存泄漏。