本帖最后由 duanyao 于 2019-7-30 19:45 编辑

网站： https://github.com/rfjakob/earlyoom

文档的解说已经很详细了，不过因为是英文，我简单介绍一下：
Linux 内核中的 oom-killer 严重不靠谱，往往触发得太迟。在它工作之前，系统往往已经没救了，或者用户已经被卡得失去耐心，按了重启键。
earlyoom 是个用户态服务，顾名思义它会较早的触发（默认条件是可用物理内存和交换分区都不足10%），杀掉内存消耗最多的进程，避免系统卡死。

我试了一下还是挺有效的，用 android-studio 编译一个大工程时，它先后杀掉了 chrome、 firefox、vs code，编译得以顺利完成。

建议 deepin 预装这个软件，我相信它能避免相当数量的卡死问题。

注：2017.9  deepin 已经收录了此软件，但没有预装，大家可以用 sudo apt install earlyoom 安装试用。安装后不必做什么，下次重启系统后自动生效。
注2：2019.7 deepin 15.9.2 - 15.11 稳定版仓库里没有此软件（预计v 20恢复），你可以装 debian 仓库里的： http://ftp.cn.debian.org/debian/pool/main/e/earlyoom/earlyoom_1.2-1_amd64.deb

补充：想了一下，还是把我这些年调查内存不足导致卡死的问题是做的笔记发上来。很凌乱，没什么条理，不过里面的很多链接应该是有参考价值的。
发上来的主要目的是说明：我并非是偶尔看到一个软件就兴冲冲的推荐了，这后面是有大量铺垫的。linux_memory_swap_thrashing.zip

linux_memory_swap_thrashing.zip


再补充：还没有经历过内存不足卡死，或者喜欢作死的小伙伴，可以试试这个小程序：

http://launchpadlibrarian.net/23372552/memory_overcommit.cc

来源是 ubuntu 的一个 bug 报告 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/159356
下载后用 c++ 编译，运行。你需要输入每次分配的内存大小，单位 M，直接回车表示与上次相同。
如果剩余物理内存很多可以500M每步，剩余500M左右时改为100M每步，剩余100M左右时改为30M每步，而且不要太快。这很重要，如果最后阶段步子太大、太快，很容易被OOM killer 迅速杀掉。
剩余物理内存用系统监视器或free看就行。

在我的机器（机械硬盘）上，如果关闭 earlyoom （systemctl stop earlyoom），它几乎 100% 能卡死。之前我用的测试方法（浏览器开很多页面、开虚拟机、android-studio）太繁琐了，还是这个好。

为了从卡死中恢复，可以这么做：在运行 memory_overcommit.cc 之前，先修改 /etc/sysctl.d/99-sysctl.conf （也可能是同一目录下的其它名字），把 kernel.sysrq=0 （或其它值）改为 kernel.sysrq=1 ；然后重启系统，或执行 sudo sysctl kernel.sysrq=1 立即生效。

在卡死后，按下组合键 alt + sysrq + r  然后按 alt + sysrq + f ，这是为了手工执行 oom killer。oom killer 可能要延迟几秒钟才执行，所以不要急不可耐的反复按 alt + sysrq + f ，以免杀掉很多无辜进程。sysrq 就是 print screen 键。