【翻译】Linux 内核僵尸 cgroup 的清理-阿里云开发者社区

开发者社区> 开发与运维> 正文

【翻译】Linux 内核僵尸 cgroup 的清理

简介: 翻译自原文:https://lwn.net/Articles/787614/ Cgroup是linux内核中一种有效的资源管理机制,但是当cgroup本身成为一种资源问题时又会发生什么呢?在2019年的LSMM大会上,Roman Gushchin描述了一些他遇到的删除的cgroup会继续留在系统中的问题。其中有些已经被修复,但问题并没有被真正解决。 Cgroup是通过cgroup/cg

翻译自原文:https://lwn.net/Articles/787614/

Cgroup是linux内核中一种有效的资源管理机制,但是当cgroup本身成为一种资源问题时又会发生什么呢?在2019年的LSMM大会上,Roman Gushchin描述了一些他遇到的删除的cgroup会继续留在系统中的问题。其中有些已经被修复,但问题并没有被真正解决。

Cgroup是通过cgroup/cgroup2伪文件系统来管理的,可以通过删除伪文件系统中的文件目录来删除相应的cgroup。但事实上,Gushchin说到,当删除cgroup的目录后虽然用户态已经看不到它,但在内核中代表cgroup的结构体会一直存在直到所有对它的引用被释放。只要它依然存在,就会消耗相应的资源。

由于memory cgroup中的每个页都会引用该cgroup,使得该问题在memory cgroup上表现的尤为严重。只有当被删除的memory cgroup中的页都被回收掉,相应的引用都被释放,该memory cgroup才会彻底被删除,这可能会需要很长的时间,如果当中的一些页被活跃的使用,这些页可能永远不会被回收掉。另外,还有其他各种各样的问题,同样会导致删除的cgroup继续留在系统中。

僵尸cgroup虽然不会导致严重的后果,但依然是个问题。每个僵尸cgroup都会占用200KB的内存,随着僵尸cgroup的增加相应的内存消耗也会增加。同时这些僵尸cgroup会增加遍历cgroup树的开销。另外这些内存开销能够摆脱内存管理的统计。

有些导致僵尸cgroup产生的问题相对而言比较容易被处理,比如说在处理用户页的一个rounding错误会导致最后的页不会被回收掉。这个bug同时存在于cgroup v1和v2,已经被修复。另一个问题是有关内核栈的统计。该问题是在2016年转到使用vmalloced栈引入的。这些内核栈会统计到第一个分配它们的进程的所在cgroup中,当一个栈被一个新进程重新使用后,相应的统计并没有更新,这个问题也被修复了。

目前还没有被修复的一个问题是来自于slab对cgroup的引用,当从slab分配器中分配相应的slab对象时,相应的页会被统计到相应的cgroup上同时增加对该cgroup的引用,因此只有当上述slab对象的页被回收释放解除对该cgroup的引用,该cgroup才会最终被删除释放。但是在没有太大内存压力的情况下,这些slab 对象很难被回收释放。Gushchin写了个patch来施加一些额外的压力促使系统回收这些slab对象,但这个patch会导致XFS文件系统的性能回退,因此该patch也被回退了。目前他在进行另一个方案:当删除cgroup时把它的slab缓存移到到它的父组上。关于该方案的一组patch正在review过程中,希望这个问题在不久的将来能够得到解决。

还有一些潜在的问题如通过vmalloc分配的页以及per-cpu的页都容易产生对cgroup的潜在引用从而导致相应的cgroup无法被彻底删除。

在会议的最后,Michal Hocko提到问题的一部分是来自于memory cgroup结构体的大小,如果把这个结构体拆分成两部分并且当删除memory cgroup时只保留核心的那部分,可能会缓解该问题。但是Johannes Weiner回应说目前唯一可以彻底删除这些memory cgroup的是内存压力引起的回收,如果把它们变的更小,它们就会堆积的更深。看来尽管一些问题得到了解决,但是僵尸cgroup问题还会伴随我们一段时间。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章