CPU & 线程

和 CPU 相关的指标主要有以下几个：

• CPU 利用率（CPU Utilization）
• CPU 平均负载（Load Average）
• 上下文切换次数（Context Switch）

常用的工具有 top、ps、uptime、vmstat、pidstat 等。

CPU 异常指标的分析思路包括了：

• CPU 利用率：如果我们观察某段时间系统或应用进程的 CPU 利用率一直很高（单个 core 超过 80%），那么就值得我们警惕了。我们可以多次使用 jstack 命令 dump 应用线程栈查看热点代码，非 Java 应用可以直接使用 perf 进行 CPU 采采样，离线分析采样数据后得到 CPU 执行热点（Java 应用需要符号表进行堆栈信息映射，不能直接使用 perf）。

• CPU 平均负载：平均负载高于 CPU 数量 70%，意味着系统存在瓶颈点，造成负载升高的原因有很多，在这里就不展开了。需要注意的是，通过监控系统监测平均负载的变化趋势，更容易定位问题，有时候大文件的加载等，也会导致平均负载瞬时升高。如果 1 分钟/5 分钟/15 分钟的三个值相差不大，那说明系统负载很平稳，则不用关注，如果这三个值逐渐降低，说明负载在渐渐升高，需要关注整体性能；

• CPU 上下文切换：上下文切换这个指标，并没有经验值可推荐（几十到几万都有可能），这个指标值取决于系统本身的 CPU 性能，以及当前应用工作的情况。但是，如果系统或者应用的上下文切换次数出现数量级的增长，就有很大概率说明存在性能问题，如非自愿上下切换大幅度上升，说明有太多的线程在竞争 CPU。

CPU 上的的一些异动，通常也可以从线程上观测到，但需要注意的是，线程问题并不完全是由 CPU 导致的。与线程相关的指标，主要有下面几个（均都可以通过 JDK 自带的 jstack 工具直接或间接得到）：应用中的总的线程数、应用中各个线程状态的分布、线程锁的使用情况，如死锁、锁分布等。

关于线程，可关注的异常有：线程总数过多（体现在 CPU 就是导致频繁的上下文切换，可能是线程池设置不当）、WAITING/BLOCKED 线程过多（线程数设置过多或锁竞争剧烈）、存在大量消耗 CPU 的线程等。

问题排查

我们更应该关注 CPU 负载，CPU 利用率高一般不是问题，CPU 负载 是判断系统计算资源是否健康的关键依据。

# 按照 CPU/内存的使用情况列出前10 的进程
$ ps axo %mem,pid,euser,cmd | sort -nr | head -10
$ ps -aeo pcpu,user,pid,cmd | sort -nr | head -10

# 显示系统整体的 CPU利用率和闲置率
$ grep "cpu " /proc/stat | awk -F ' ' '{total = $2 + $3 + $4 + $5} END {print "idle \t used\n" $5*100/total "% " $2*100/total "%"}'

CPU 利用率高 & 平均负载高

这种情况常见于 CPU 密集型的应用，大量的线程处于可运行状态，I/O 很少，常见的大量消耗 CPU 资源的应用场景有：

• 正则操作
• 数学运算
• 序列化/反序列化
• 反射操作
• 死循环或者不合理的大量循环
• 基础/第三方组件缺陷

排查高 CPU 占用的一般思路：通过 jstack 多次（> 5 次）打印线程栈，一般可以定位到消耗 CPU 较多的线程堆栈。或者通过 Profiling 的方式（基于事件采样或者埋点），得到应用在一段时间内的 on-CPU 火焰图，也能较快定位问题。

还有一种可能的情况，此时应用存在频繁的 GC（包括 Young GC、Old GC、Full GC），这也会导致 CPU 利用率和负载都升高。排查思路：使用 jstat -gcutil 持续输出当前应用的 GC 统计次数和时间。频繁 GC 导致的负载升高，一般还伴随着可用内存不足，可用 free 或者 top 等命令查看下当前机器的可用内存大小。

CPU 利用率过高，是否有可能是 CPU 本身性能瓶颈导致的呢？也是有可能的。可以进一步通过 vmstat 查看详细的 CPU 利用率。用户态 CPU 利用率（us）较高，说明用户态进程占用了较多的 CPU，如果这个值长期大于 50%，应该着重排查应用本身的性能问题。内核态 CPU 利用率（sy）较高，说明内核态占用了较多的 CPU，所以应该着重排查内核线程或者系统调用的性能问题。如果 us + sy 的值大于 80%，说明 CPU 可能不足。

CPU 利用率低 & 平均负载高

这种情况常见于 I/O 密集型进程，这很容易理解，毕竟平均负载就是 R 状态进程和 D 状态进程的和，除掉了第一种，就只剩下 D 状态进程了（产生 D 状态的原因一般是因为在等待 I/O，例如磁盘 I/O、网络 I/O 等）。

使用 vmstat 1 定时输出系统资源使用，观察 %wa(iowait) 列的值，该列标识了磁盘 I/O 等待时间在 CPU 时间片中的百分比，如果这个值超过 30%，说明磁盘 I/O 等待严重，这可能是大量的磁盘随机访问或直接的磁盘访问（没有使用系统缓存）造成的，也可能磁盘本身存在瓶颈，可以结合 iostat 或 dstat 的输出加以验证，如 %wa(iowait) 升高同时观察到磁盘的读请求很大，说明可能是磁盘读导致的问题。

此外，耗时较长的网络请求（即网络 I/O）也会导致 CPU 平均负载升高，如 MySQL 慢查询、使用 RPC 接口获取接口数据等。这种情况的排查一般需要结合应用本身的上下游依赖关系以及中间件埋点的 trace 日志，进行综合分析。

CPU 上下文切换次数变高

先用 vmstat 查看系统的上下文切换次数，然后通过 pidstat 观察进程的自愿上下文切换（cswch）和非自愿上下文切换（nvcswch）情况。

如果自愿上下文切换次数较高，意味着 CPU 存在资源获取等待，比如说，I/O、内存等系统资源不足等。如果是非自愿上下文切换次数较高，可能的原因是应用内线程数过多，导致 CPU 时间片竞争激烈，频频被系统强制调度，此时可以结合 jstack 统计的线程数和线程状态分布加以佐证。