小结
碰到常规问题无法解释的 CPU 使用率情况时，首先要想到有可能是短时应用导致的问题，比如有可能是下面这两种情况。
-
第一，应用里直接调用了其他二进制程序，这些程序通常运行时间比较短，通过 top 等工具也不容易发现。
-
第二，应用本身在不停地崩溃重启，而启动过程的资源初始化，很可能会占用相当多的 CPU。
对于这类进程，我们可以用 pstree 或者 execsnoop 找到它们的父进程，再从父进程所在的应用入手，排查问题的根源。
如果碰到不好解释的CPU问题时，比如现象：
通过top观察CPU使用率很高，但是看下面的进程的CPU使用率好像很正常，通过pidstat命令查看cpu也很正常。但通过top查看task数量不正常，处于R状态的进程是可疑点。
首先要想到可能是短时间的应用导致的问题，如下面的两个：
（1）应用里直接调用了其他二进制程序，这些程序通常运行时间比较短，通过top等工具发现不了
（2）应用本身在不停地崩溃重启，而启动过程的资源初始化，很可能会占用很多CPU资源
对于这类进程就需要 pstree 或execsnoop命令查找父进程，再从父进程的应用入手，找原因。
我实战的问题：
（1）centos的系统，发现通过 yum install pstress命令或其他命令，总是说没有匹配的软件包，这个很头疼
①pstress装不上可以尝试 yum install psmisc
②execsnoop这个命令我没有装上，想请教下老师如何解决这种yum install命令报没有匹配包的情况
（2）然后就是通过perf命令只能看到十六进制符号，看不到具体函数名的问题，这个可以使用上篇文章中我的留言的方法，我在copy一份，供大家参考
分析：当没有看到函数名，只看到十六进制时，说明perf无法找到待分析进程所依赖的库。
解决办法：
在容器外面把分析记录保存，到容器里面查看结果
操作：
（1）在centos系统上运行 perf record -g ，执行一会儿按ctrl+c停止
（2）把生成的perf.data（通常文件生成在命令执行的当前目录下，当然可以通过find | grep perf.data或 find / -name perf.data查看路径）文件拷贝到容器里面分析：
docker cp perf.data phpfpm:/tpm
docker exec -i -t phpfpm bash
cd /tmp/
apt-get update && apt-get install -y linux-perf linux-tools procps
perf_4.9 report
这样就可以看到函数名了