尝试将一个相当大的文件夹 (450G) 备份到该服务器中仅作为备份目标的 2TB 驱动器时rdiff-backup（版本 1.2.8 - 最后标记为稳定的) 引起了内核恐慌。
系统：
Linux giorgio 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
磁盘：2 个 1TB 磁盘采用软件镜像 RAID 模式，1 个 2TB 磁盘仅用于备份。
我有一个怀疑：服务器上的内存是 2G RAM + 2G swap = 4G。文件大小高达 16G。是否有可能rdiff-backup在某个时候将整个文件加载到内存中？
无论如何，内核恐慌都不应该发生（因为 rdiff 进程已被终止？所以内存应该再次可用？），所以我想我的问题有两个部分，第一：关于我的怀疑，第二：关于内核恐慌。
顺便说一句，最近出现了恐慌，很多备份已经成功 - 完整和增量 - 并且那些大 GB 文件已经存在。所以我猜这是新 Debian 内核的问题，而不是 rdiff-backup 的问题？
崩溃发生时的日志文件部分http://pastebin.com/e9a5fQdh
屏幕上的最后一件事：
编辑/更新：我刚刚尝试创建一个 20GB 的交换文件（使用来自 /dev/zero 的 dd），服务器再次关闭，没有反应ping。
从日志来看：似乎内核已经终止了一些进程 - 包括我怀疑导致这一切的进程（rdiff-backup） -但显示“可终止的进程已用完”。似乎终止进程并没有释放内存？
答案1
它没有杀死 rdiff-backup，它应该杀死但它oom_score_adj是 -1000。
这是由 sshd 中的一个错误引起的。该错误已修复，但要等到下一个版本（即 openssh 6.5）才能使用。
如果您重新加载 sshd，它会无法将其创建的新 shell 的 oom_score_adj 设置回 0，从而导致您通过 SSH 生成的所有子进程（即您的 bash shell 和任何创建的子进程）都具有 -1000 oom_score_adj，随后会占用所有内存而不会被 oom-killer 杀死。
解决这个问题最快的方法是（假设 7567 是 sshd 的 pid，就像你的情况一样）：-
- 跑步
echo 0 >/proc/7567/oom_adj_score - 重新启动 sshd。
不要重新加载 sshd，重新启动它直到修复到位。（openssh 6.5 应该有它）
该错误已在此处报告并修复。https://bugzilla.mindrot.org/show_bug.cgi?id=2156