CPU性能问题分析

一、CPU性能指标

查证性能的问题我们可以从下面几个指标来进行排查：
1.CPU使用率
2.平均负载
3.进程上下文切换
4.CPU 缓存的命中率
用图表展示：

二、性能工具

针对上面的不同指标，使用不同的工具和命令进行查证。

1. 平均负载的案例。我们先用 uptime， 查看了系统的平均负载；而在平均负载升高
   后，又用 mpstat 和 pidstat ，分别观察了每个 CPU 和每个进程 CPU 的使用情况，进而
   找出了导致平均负载升高的进程，也就是我们的压测工具 stress。
2. 上下文切换的案例。我们先用 vmstat ，查看了系统的上下文切换次数和中断次
   数；然后通过 pidstat ，观察了进程的自愿上下文切换和非自愿上下文切换情况；最后通
   过 pidstat ，观察了线程的上下文切换情况，找出了上下文切换次数增多的根源，也就是
   我们的基准测试工具 sysbench。
3. 进程 CPU 使用率升高的案例。我们先用 top ，查看了系统和进程的 CPU 使用情
   况，发现 CPU 使用率升高的进程是 php-fpm；再用 perf top ，观察 php-fpm 的调用
   链，最终找出 CPU 升高的根源，也就是库函数 sqrt() 。
4. 系统的 CPU 使用率升高的案例。我们先用 top 观察到了系统 CPU 升高，但通过
   top 和 pidstat ，却找不出高 CPU 使用率的进程。于是，我们重新审视 top 的输出，又
   从 CPU 使用率不高但处于 Running 状态的进程入手，找出了可疑之处，最终通过 perf
   record 和 perf report ，发现原来是短时进程在捣鬼。
   另外，对于短时进程，我还介绍了一个专门的工具 execsnoop，它可以实时监控进程调用
   的外部命令。
5. 不可中断进程和僵尸进程的案例。我们先用 top 观察到了 iowait 升高的问题，
   并发现了大量的不可中断进程和僵尸进程；接着我们用 dstat 发现是这是由磁盘读导致
   的，于是又通过 pidstat 找出了相关的进程。但我们用 strace 查看进程系统调用却失败
   了，最终还是用 perf 分析进程调用链，才发现根源在于磁盘直接 I/O 。
6. 软中断的案例。我们通过 top 观察到，系统的软中断 CPU 使用率升高；接着
   查看 /proc/softirqs， 找到了几种变化速率较快的软中断；然后通过 sar 命令，发现是网
   络小包的问题，最后再用 tcpdump ，找出网络帧的类型和来源，确定是一个 SYN
   FLOOD 攻击导致的。

三、如何迅速分析 CPU 的性能瓶颈

为了缩小排查范围，我通常会先运行几个支持指标较多的工具，如 top、vmstat
和 pidstat 。为什么是这三个工具呢？仔细看看下面这张图，你就清楚了。

这张图里，我列出了 top、vmstat 和 pidstat 分别提供的重要的 CPU 指标，并用虚线表
示关联关系，对应出了性能分析下一步的方向。
通过这张图你可以发现，这三个命令，几乎包含了所有重要的 CPU 性能指标，比如：
从 top 的输出可以得到各种 CPU 使用率以及僵尸进程和平均负载等信息。
最新一手资源更新通知 加微信 sucl2015 资料整理不易 仅供个人学习 请勿倒卖
另外，这三个工具输出的很多指标是相互关联的，所以，我也用虚线表示了它们的关联关
系，举几个例子你可能会更容易理解。
第一个例子，pidstat 输出的进程用户 CPU 使用率升高，会导致 top 输出的用户 CPU 使
用率升高。所以，当发现 top 输出的用户 CPU 使用率有问题时，可以跟 pidstat 的输出
做对比，观察是否是某个进程导致的问题。
而找出导致性能问题的进程后，就要用进程分析工具来分析进程的行为，比如使用 strace
分析系统调用情况，以及使用 perf 分析调用链中各级函数的执行情况。
第二个例子，top 输出的平均负载升高，可以跟 vmstat 输出的运行状态和不可中断状态
的进程数做对比，观察是哪种进程导致的负载升高。
最后一个例子，当发现 top 输出的软中断 CPU 使用率升高时，可以查看 /proc/softirqs
文件中各种类型软中断的变化情况，确定到底是哪种软中断出的问题。比如，发现是网络
接收中断导致的问题，那就可以继续用网络分析工具 sar 和 tcpdump 来分析。
注意