性能测试实战30讲 CentOS：操作系统级监控及常用计数器解析
思考：为什么 CPU 是很多性能问题分析的方向性指标？
CPU 常见的计数器是 top 中的 8 个值，也就是下面这些：
%Cpu(s): 0.7 us, 0.5 sy, 0.0 ni, 98.7 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st常见的问题大部分都是体现在这么几个计数器上（排名有先后）：
- us
- wa
- sy
- si
读者：
如果应用部署在k8s上 ，用top或是vmstat等命令查看都是node节点的指标，如何精确排查应用问题导致的性能问题呢
作者回复: 首先，k8s只是编排工具，容器才是应用的载体。如果你是用的k8s docker，那就先把k8s、node（也就是你说的用top、vmstat看的部分）、docker监控起来，然后把其中的应用监控起来，这就取决于你是什么样的应用了。 如果是java应用，可以用专栏关于java分析部分的工具。如果是基他语言，可以用其他语言提供的分析工具。
读者：
应用无非就是两种计算密集型和IO密集型，计算密集集就体现在CPU忙，IO密集型就体现在CPU空闲，我想接下来无非就是围绕这两种类型展开分析，所以说CPU是性能分析的方向性指标。
作者回复: 理解的很正确。
- 我为什么不建议在生产环境中一开始就上 APM 类工具来抓取方法的执行时间呢？
- 你有什么方法可以抓取到 Java 语言中的方法执行时间？
- 如果你擅长其他语言，也可以描述其他语言中的方法执行时间抓取工具。
读者：
我觉得某些生产环境还是可以直接上APM的： 1. 能接受10%性能损耗的，比如原来耗时1秒，上了变成1.1秒其实感觉不明显；原来高峰期CPU使用率30%，上了变成40%也还在可接受范围内； 2. APM的成功失败不影响业务的运行，就是即使APM挂了，业务也还能正常运行； 3. 在docker k8且又有大量虚机大量服务的情况下，上APM也是一个方案，不然当出现问题时要在那么多服务里面把问题定位到，用jmx这类监控很容易措手不及和慌手慌脚。 4. 现在好些公司没有专职性能测试，好些系统没有经过性能测试就上线的，此时APM是开发和运维人员的一个救命稻草了，这种公司我相信很多。
作者回复: 很不幸的是，你说的非常对。 我觉得我们对大量服务的场景其实需要的只是一个链路监控系统，这个功能APM基本都有提供，我们要用的就是这个功能而已。 另外，我不知道你有没有遇到过APM的agent导致业务系统挂掉的情况，在我的工作中有遇到过，一级故障，损失也是惨重。 所以用不用APM，只有在具体的应用场景中，测试好了再决定上不上吧。
