可能影响容器化应用程序的 cgroup 内存管理问题

近日，LinkedIn工程团队发表了一篇题为“不要让Linux 控制组不受控制地运行”的文章。控制组（cgroup）是Linux 的一项特性，像Docker 和CoreOS 这样的项目使用该特性限制进程的资源使用。该文概括地介绍了cgroup 在内存管理方面存在的几个可能导致性能退化的问题以及可能的解决方案。

cgroup 是一种可以确保应用程序使用的资源不超出限额的机制，但不保证隔离性。一个操作系统实例中可以运行多个 cgroup，其中每一个所使用的内存、CPU 等都有不同的限额。不过，当有额外的内存需求（文章作者称之为“内存压力”）时，操作系统的行为可能会导致在 cgroup 中运行的应用程序出现意料之外的不良结果。

cgroup 是按层次组织的，操作系统在“根”cgroup 中运行，其他 cgroup 都是根 cgroup 的子节点。例如，Docker 容器会运行在根 cgroup 的一个子 cgroup 中。

该文探讨的问题涉及“匿名内存”和“页面缓存”，前者是程序请求的内存，后者用来存储程序数据的缓存版本。通常，这些数据是保存在类似硬盘这样的永久性存储上，供程序执行时使用。缓存用于提高那些数据的访问速度。这两种内存类型的分配总是可以被根cgroup 或操作系统作废。

当主存可用时，操作系统会将页面缓存加载到RAM，但当应用程序请求额外的内存时，它会回收内存。内存回收会导致页面缓存被删除，这是跨cgroup 的，因为在这种情况下，OS 不会遵守cgroup 自己的设置。这可能导致cgroup 的页面缓存被回收，影响了应用程序的性能。

当通过回收页面缓存满足了cgroup 的内存需求时，另一个问题出现了。用于存储页面缓存的内存是cgroup 内存限额的一部分。因此，如果cgroup（在Docker 环境里，则是容器）分得了8GB 内存，则它需要将这8GB 的空间同时用于页面缓存和匿名内存。这一点很容易忽视，因而可能会导致错误的性能预期。

当需要的主存超过系统可用的内存时，操作系统会执行交换操作，将存储在主存中的程序数据写入辅存，如硬盘。操作系统可以从任意子cgroup 把用户内存交换出去，导致那些组中的应用程序性能退化。

对于这些问题，文章作者提出了几项建议，其中包括“预触（pre-touching）”内存，即确保内存在进程启动时分配，而不是在程序请求时。在不同的平台上，具体的做法也不相同。另外，也可以更好地估计应用程序的内存占用，那样，内存分配就可以更准确。页面缓存不容易估计，但匿名内存很容易。匿名内存可以通过类似驻留集大小（RSS）这样的系统指标来估计。

新版本的cgroup 已经发布。该版本包含若干改进，但尚未针对这些情况进行测试。

查看英文原文： Memory Issues with Linux Control Groups Might Affect Containerized Applications