我试图找出并理解OOM杀手如何在容器上工作。
为了弄清楚这一点，我读了很多文章，我发现OOM杀手杀死了基于oom_score的容器。oom_score由oom_score_adj和该进程的内存使用量决定。
cAdvisor中有两个指标container_memory_working_set_bytes和container_memory_rss，用于监视容器的内存使用情况。
看起来RSS内存（container_memory_rss）对oom_score有影响，所以我可以理解使用container_memory_rss度量，如果该度量达到内存限制，OOM杀手将杀死该进程。
- https://github.com/torvalds/linux/blob/v3.10/fs/proc/base.c#L439
- https://github.com/torvalds/linux/blob/v3.10/mm/oom_kill.c#L141
- https://github.com/torvalds/linux/blob/v3.10/include/linux/mm.h#L1136
但从下面的文章：
- https://faun.pub/how-much-is-too-much-the-linux-oomkiller-and-used-memory-d32186f29c9d
- https://blog.freshtracks.io/a-deep-dive-into-kubernetes-metrics-part-3-container-resource-metrics-361c5ee46e66的
更好的指标是container_memory_working_set_bytes，因为这是OOM杀手正在关注的。
**我无法理解OOM杀手正在监视容器的工作集内存的事实。**我想我不明白容器上的工作集内存的含义是“总使用量-非活动文件”。
- https://github.com/google/cadvisor/issues/2582#issuecomment-644883028
我在哪里可以找到参考资料？或者你能解释一下工作集内存和容器上的OOM-kill之间的关系吗？
1条答案
按热度按时间wixjitnu1#
如你所知，
container_memory_working_set_bytes是：工作集内存的数量，包括最近访问的内存、脏内存和内核内存。因此，Working set（小于或等于）</=“usage”。
container_memory_working_set_bytes用于OoM决策，因为它不包括在内存压力情况下可能被驱逐的缓存数据（Linux Page Cache）。因此，如果
container_memory_working_set_bytes增加到极限，将导致oomkill。您可以发现，当Linux内核检查可用内存时，它会调用
vm_enough_memory()来确定有多少页面可能可用。然后当机器内存不足时，包括缓存在内的旧页帧将被回收，但内核仍然可能发现它无法释放足够的页来满足请求。现在是时候调用
out_of_memory()来终止进程了。为了确定要杀死的候选进程，它使用oom_score。因此，当工作集字节达到限制时，这意味着内核即使回收包括缓存在内的旧页面也无法找到可用页面，因此内核将触发OOM杀手来杀死进程。
您可以在Linux内核文档中找到更多详细信息：