Because of it ,the image of php.fpm is not completed

Env:
kernel 3.10
os centos7

Description:
倪前辈，我在学习了贵专栏后解决实际问题过程中遇到了无从分析OOM的问题，还请老师指教思路

我的思路如下：

1. 观察到在kernel cgroup代码中达到memory限制，查看memory组成
2. 查阅得知memory由rss + cache 组成，但是由图上得知cgroup对应进程和子进程的rss+cache 也未达到6291456KB，于是猜测如下

• 有尚未分析出的内存组成部分（好像加上kernel memory刚刚好）
  -kmem为啥这么高？？？泄漏？（但未在对应版本发现kernel memory leak bug）
• total-vm？？？？

还望倪前辈指教一二

i am sorry to communicate with you in such a way，this is the only way i can found，i will use chinese following for convenience

在 极客时间 订阅了您的 linux 性能优化专栏，受益匪浅。

最近有个想法，在做性能监控时，一般会按照 USE的原则来实施，最近也刚接触到prometheus监控系统，参考过一些其他人的监控模板，链接如下：https://grafana.com/dashboards/8919 ，但是这个dashboard看起来并没有按照 USE的原则来组织。

因为了解到您也参与到kubernet的社区中，prometheus和kubernet联系也比较紧密，所以才 冒昧的向您 请教，不知道 您 那边是否有更好的类似的监控模板？ 或者您有其他更好的建议。（目标是 在回溯性能问题时，能够直观的判断出原因）

我相信这个如果有个比较权威的模板供参考，会节省不少相关技术人员的时间。不胜感激！

@feiskyer 你好, 在<<Linux性能优化实战>> 22讲，有人提问: OOM 是按照虚拟内存还是实际内存来打分?

你的回答是:

OOM 触发的时机基于虚拟内存。换句话说，进程在申请内存时，如果申请的虚拟内存加上服务器实际已用的内存之和，比总的物理内存还大，就会触发OOM。

这个回答应该是错误的，Linux本身就采用延迟分配的策略，申请的虚拟内存并不能等于实际物理内存，OOM的计数规则应该是对应实际的物理内存. 之前自己总结过一篇博客关于Linux内核源码分析-理解cgroup内存资源控制，在里面分析了关于分配访问文件分配物理Page的cgroup计数，只有在page_alloc()申请物理页成功的情况下，cgroup才成功计数, 所以OOM killer应该是基于物理内存的，而不是虚拟内存.

我的分析:
OOM killer是基于虚拟内存还是物理内存?

linux机器上下载安装了perf后，需要将要监测的应用的源码也放到相应目录吗？不然火焰图上能出现应用内的方法吗？