标签: oom

我在 server_A 上有一个 50 GB 的文件，我正在将它复制到 server_B。我跑

server_A$ rsync --partial --progress --inplace --append-verify 50GB_file root@server_B:50GB_file

Server_B 有 32 GB RAM 和 2 GB 交换。它主要是空闲的，应该有很多空闲内存。它有足够的磁盘空间。在大约 32 GB 时，传输中止，因为远程端关闭了连接。

Server_B 现在已断开网络。我们要求数据中心重新启动它。当我查看崩溃前的内核日志时，我看到它使用了 0 字节的交换空间，并且进程列表使用了很少的内存（rsync 进程被列为使用 600 KB 的 RAM），但是 oom_killer 是变得疯狂，日志中的最后一件事是它杀死了 metalog 的内核读取器进程。

这是内核 3.2.59，32 位（因此任何进程都不能映射超过 4 GB）。

就好像 Linux 更优先考虑缓存而不是长期运行的守护进程。是什么赋予了？？我怎样才能阻止它再次发生？

这是 oom_killer 的输出：

Sep 23 02:04:16 [kernel] [1772321.850644] clamd invoked oom-killer: gfp_mask=0x84d0, order=0, oom_adj=0, oom_score_adj=0
Sep 23 02:04:16 [kernel] [1772321.850649] Pid: 21832, comm: clamd Tainted: G         C   3.2.59 #21
Sep 23 02:04:16 …

Linux 上的 OOM 杀手时常对各种应用程序造成严重破坏，而且似乎在内核开发方面并没有真正做很多事情来改进这一点。作为设置新服务器时的最佳实践，在内存过量使用时反转默认设置，即关闭它 ( vm.overcommit_memory=2) ，除非您知道需要将其打开以用于特定用途，这不是更好吗？这些用例是什么，你知道你想要过度使用？

作为奖励，由于情况下的行为vm.overcommit_memory=2取决于vm.overcommit_ratio和交换空间，因此调整后两者的大小以便整个设置保持合理工作的良好经验法则是什么？

今天我（不小心）在我的 Linux 机器上运行了一些快速使用大量内存的程序。我的系统死机，反应迟钝，因此我无法杀死罪犯。

我怎样才能在未来防止这种情况？它不能至少保持一个响应式核心或其他东西运行吗？

当物理内存不足但有足够的交换空间时，如何让 Linux OOM 杀手不杀死我的进程？

我使用 sysctl vm.overcommit_memory=2 禁用了 OOM 杀戮和过度使用。

VM 有 3 GB 的完全免费的未碎片交换空间，被 OOM 杀死的进程的最大内存使用量小于 200MB。

我知道长期交换对性能来说会很糟糕，但是我现在需要使用交换来在内存要求更高的 valgrind 下进行功能测试。

Mar  7 02:43:11 myhost kernel: memcheck-amd64- invoked oom-killer: gfp_mask=0x24002c2, order=0, oom_score_adj=0
Mar  7 02:43:11 myhost kernel: memcheck-amd64- cpuset=/ mems_allowed=0
Mar  7 02:43:11 myhost kernel: CPU: 0 PID: 3841 Comm: memcheck-amd64- Not tainted 4.4.0-x86_64-linode63 #2
Mar  7 02:43:11 myhost kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Mar  7 02:43:11 myhost kernel: 0000000000000000 …

我有持续的 oom&panic 情况未解决。我不确定系统是否填满了所有内存（36GB）。为什么这个系统会触发这种oom情况？我怀疑它与 32 位 linux 系统中的 lowmem 区域有关。如何分析内核恐慌和 oom-killer 的日志？

此致，

内核 3.10.24

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0
Dec 27 09:19:05 2013 kernel: : [277622.359069] squid cpuset=/ mems_allowed=0
Dec 27 09:19:05 2013 kernel: : [277622.359074] CPU: 9 PID: 15533 Comm: squid Not tainted 3.10.24-1.lsg #1
Dec 27 09:19:05 2013 kernel: : [277622.359076] Hardware name: Intel Thurley/Greencity, BIOS 080016  10/05/2011
Dec 27 09:19:05 2013 kernel: : [277622.359078]  00000003 e377b280 e03c3c38 c06472d6 e03c3c98 …

在 Google 上查看，找不到任何解释如何proc/<pid>/oom_score计算分数的内容。为什么要使用这个分数而不是只使用使用的总内存？

尽管我们将近一半的内存用于 FS 缓存，但我们还是遇到了 OOM 杀手。我们每分钟记录一次内存统计信息（如 top 所报告的），但似乎有很多可用性。

...

Mem:  15339640k total, 15268304k used,    71336k free,     3152k buffers
Swap:        0k total,        0k used,        0k free,  6608384k cached

Mem:  15339640k total, 14855280k used,   484360k free,    13748k buffers
Swap:        0k total,        0k used,        0k free,  6481852k cached

[OOM killer: postgres killed]

Mem:  15339640k total,  8212200k used,  7127440k free,    32776k buffers
Swap:        0k total,        0k used,        0k free,  2394444k cached

...

来自系统日志的 OOM 详细信息：

...
Jun 10 05:45:25 db kernel: [11209156.840462] wal-e invoked oom-killer: …

问题

服务器在多次“内存不足”消息后崩溃，我试图查明罪魁祸首。如果它在用户空间 - 哪个进程。如果它在内核中 - 哪个内核模块。

细节

我试图找出如何使用崩溃实用程序来调查是什么触发了服务器上的 OOM。

作为安装一对新服务器的一部分，我开始了一个 14TB DRBD设备的初始化。大约在那个时候，在使用 DRBD 同步器速率配置并启动和关闭一些绑定的网络接口时，其中一台服务器崩溃了。在 30 秒的时间内，它产生了 39 条Out of memory: Kill process ####消息。然后它崩溃了：

Kernel panic - not syncing: Out of memory and no killable processes...

系统崩溃触发了kdump。现在我有一个不错的vmcore.flat文件，应该可以直接使用它来调查问题，但是我很难找出所有内存的去向。

我知道的唯一资源是Dedoimedo 的网站，它有很好的说明，以及内核崩溃手册。这些也恰好是答案中建议的唯一资源，所以我认为这crash是唯一的调查方法。

如果有另一种方式对事件进行事后分析，我愿意接受。这只是crash我所知道的唯一实用程序。我现在拥有的只是vmcore.flat文件，我需要知道的是哪个组件占用了所有内存。我怀疑是内核模块问题，更具体地说是绑定模块之一（因为它在我关闭接口时被触发）、DRBD 模块（在 CentOS 6.3 上用树构建的版本 8.3.15），或其中一个10G 以太网模块（mlnx_en构建在树外，即我关闭的接口，或树内bnx2x，即保持活动状态的接口）。我只需要知道是否有办法验证我的怀疑。

到目前为止，我只设法使用crash实用程序提取了以下信息：

检查使用了多少内存

$ crash /usr/lib/debug/lib/modules/2.6.32-279.5.2.el6.x86_64/vmlinux vmcore.flat
....
crash> …

尽管我的系统上有足够多的可用 RAM，但 OOM 杀手似乎正在杀死一些东西：

（全分辨率）

（全分辨率）

27 分钟和 408 个进程后，系统再次开始响应。大约一个小时后我重新启动它，此后不久内存利用率恢复正常（对于这台机器）。

经过检查，我的盒子上运行了一些有趣的进程：

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
[...snip...]
root      1399 60702042  0.2 482288 1868 ?     Sl   Feb21 21114574:24 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4
[...snip...]
mysql     2022 60730428  5.1 1606028 38760 ?   Sl   Feb21 21096396:49 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
[...snip...]

这个特定的服务器已经运行了大约。8 小时，这是仅有的两个具有这种……奇数值的过程。我怀疑是“其他事情”正在发生，可能与这些荒谬的价值观有关。具体来说，我认为系统认为内存不足，而实际上并非如此。毕竟，它认为 rsyslogd 始终使用 55383984% 的 CPU，而无论如何在该系统上理论最大值为 400%。

这是具有 768MB RAM 的完全最新的 CentOS 6 安装 (6.2)。任何有关如何弄清楚为什么会发生这种情况的建议将不胜感激！

编辑：附加虚拟机。sysctl 可调参数..我一直在玩swappiness（它是100），我还在运行一个非常糟糕的脚本，它转储我的缓冲区和缓存（vm.drop_caches 是3）+同步磁盘每个15分钟。这就是为什么在重新启动后，缓存数据增长到正常大小，但随后又迅速下降的原因。我认识到拥有缓存是一件非常好的事情，但是直到我弄清楚... …

有没有办法获得核心转储或能够调试已被 oom-killer 杀死的进程？

或者甚至设置 oom-killer 来尝试使用 ABRT 来终止进程？