背景：出现没有OOM，但是stress子进程反复重启，于是系统负载到118，死机，让机房重启，需要验证为何没有OOM？
container_memory_cache，我们会发现使用的缓存量继续增加，直到container_memory_usage_bytes达到限制，然后开始减少。container_memory_usage_bytes确实考虑了一些正在缓存的文件系统页面。我们还可以看到OOMKiller正在跟踪container_memory_working_set_bytes。这是有道理的，因为共享文件系统缓存页面可以随时从内存中逐出。
也就是说：container_memory_cache （（思考文件系统缓存））平时是不动它的一个值，但是当container_memory_usage_bytes伴随container_memory_usage_bytes的增长而增长，container_memory_usage_bytes增长到设定的limit 200M后，发现container_memory_usage_bytes还继续增长，那么它会把container_memory_cache的内存给用掉。
来自：https://medium.com/faun/how-much-is-too-much-the-linux-oomkiller-and-used-memory-d32186f29c9d
kubectl get pod memory-demo-2 --namespace=mem-example
这时候，容器可能会运行，也可能会被杀掉。如果容器还没被杀掉，重复之前的命令直至 你看到这个容器被杀掉：
NAME READY STATUS RESTARTS AGE
memory-demo-2 0/1 OOMKilled 1 24s
来自：https://www.cnblogs.com/weifeng1463/p/10174432.html
相关测试的yaml:https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/
container_memory_cache，我们会发现使用的缓存量继续增加，直到container_memory_usage_bytes达到限制，然后开始减少。container_memory_usage_bytes确实考虑了一些正在缓存的文件系统页面。我们还可以看到OOMKiller正在跟踪container_memory_working_set_bytes。这是有道理的，因为共享文件系统缓存页面可以随时从内存中逐出。
也就是说：container_memory_cache （（思考文件系统缓存））平时是不动它的一个值，但是当container_memory_usage_bytes伴随container_memory_usage_bytes的增长而增长，container_memory_usage_bytes增长到设定的limit 200M后，发现container_memory_usage_bytes还继续增长，那么它会把container_memory_cache的内存给用掉。
来自：https://medium.com/faun/how-much-is-too-much-the-linux-oomkiller-and-used-memory-d32186f29c9d
kubectl get pod memory-demo-2 --namespace=mem-example
这时候，容器可能会运行，也可能会被杀掉。如果容器还没被杀掉，重复之前的命令直至 你看到这个容器被杀掉：
NAME READY STATUS RESTARTS AGE
memory-demo-2 0/1 OOMKilled 1 24s
来自：https://www.cnblogs.com/weifeng1463/p/10174432.html
相关测试的yaml:https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：http://jackxiang.com/post/10278/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
最后编辑： jackxiang 编辑于2019-9-2 16:41
[实践OK]Docker里的php-fpm 错误日志级别由notice修
[实践OK]手把手教你打造高效的 Kubernetes 命令行终端评论列表
