相关疑难解决方法(0)

我在 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 杀手不杀死我的进程？

我使用 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 …

尽管我的系统上有足够多的可用 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分钟。这就是为什么在重新启动后，缓存数据增长到正常大小，但随后又迅速下降的原因。我认识到拥有缓存是一件非常好的事情，但是直到我弄清楚... …