一次详尽的问题定位记录：CPU使用率低负载高的排查过程

历史原因，当前有一个服务专门用于处理mq消息，mq使用的阿里云rocketmq，sdk版本1.2.6（2016年）。

随着业务的发展，该应用上的consumer越来越多，接近200+，导致该应用所在的ecs长时间load高，频繁报警。

现象分析

该应用所在的ecs服务器load长期飙高（该ecs上只有一个服务），但cpu、io、内存等资源利用率较低，系统负载参考下图：

ECS配置：4核8G
物理cpu个数=4
单个物理CPU中核（core）的个数=1
单核多处理器

在系统负荷方面，多核CPU与多CPU效果类似，考虑系统负荷的时候，把系统负荷除以总的核心数，只要每个核心的负荷不超过1.0，就表明正常运行。 通常，n核cpu时，load<n，系统负载都属于正常情况。

套用以上规则： 先观察load_15m和load_5m，load基本保持在3-5之间，说明系统中长期负载保持在一个较高的量级。 再观察load_1m可以看出，波动很大，并且很多时间段内远大于cpu核心数。 短期内繁忙，中长期内紧张，很可能是一个拥塞的开始。

原因定位

排查导致load高的原因

tips：系统load高，不代表cpu资源不足。Load高只是代表需要运行的队列累计过多。但队列中的任务实际可能是耗cpu的，也可能是耗i/0及其他因素的

图中load_15,load_5,load_1均大于核心数4，超负荷运行

• 用户进程=8.6%
• 内核进程 =9.7%
• 空闲=80%
• I/O等待所占用的cpu时间百分比=0.3%

通过上图CPU、内存、IO使用情况，发现三者都不高， CPU使用率低负载高，排除cpu资源不足导致load高的可能性。

再通过vmstat查看进程、内存、I/O等系统整体运行状态，如下图：

从结果上看，io的block in和block out 并不频繁，但是system的中断数（in)、