Mesos Task Killed by OOM Killer

问题

前几天工作中遇到一件很“诡异”的事，我用Mesos启动的task总是运行了一段时间就自己死掉了(FAILED)，查看log发现进程的退出码是137，即被人强行kill了(SIGKILL)。通常会做这种事的就是OOM killer了。查看了dmesg之后发现果然是由于内存用量超出了设置的限定量而被OOM killer杀掉了。但是“诡异”的就在于，我仔细地观察了该task运行的容器里面的所有进程的内存用量（即top命令输出中的RES列），加起来比我设置的限制量要小得多得多，为什么OOM killer认为它超出限制量了呢？

原因

在google了一轮之后，终于在cgroups的维基百科页上找到了一个可疑点：cgroups的内存限制包括file system cache！

File system cache，即page cache，可以暂且简单地认为是读写硬盘的一个buffer。由于机械硬盘的寻址比较慢，所以每次读写的overhead很大，所以用内存来作为读写硬盘的一个buffer可以提高整体的读写速度。Linux就是利用空闲的内存来做page cache的。

这样看来就有合理的解释了。我的task要从网络上下载文件，最快的时候要以每秒50MB的速度下载10G以上的文件。如此快的下载速度，而我的硬盘速度又比较慢，所以kernel来不及清理page cache使得page cache的用量迅速上升，很快就过了我设置的内存限制量，所以OOM killer就开始杀掉我的进程了。为了确认这一点，我又仔细地看了一眼dmesg中关于OOM的部分，原来有列出来各类内存的使用量，果然其中cache的使用量占了大部分。

解决方法

Linux kernel有与page