历史原因,当前有一个服务专门用于处理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等系统整体运行状态,如下图:

从结果上看&

本文记录了一次排查Java服务CPU使用率低但负载高的问题,通过分析发现线程上下文切换频繁和线程数量过多是主要原因。问题源于RocketMQ SDK的轨迹回传模块和消费者线程池配置。解决方案包括设置消费者线程数和优化轨迹回传机制。
最低0.47元/天 解锁文章
3万+

被折叠的 条评论
为什么被折叠?



