记一次服务高cpu排查

[背景]

项目上线后，收到大量的cpu使用率超过默认阈值的报警，

经排查后发现为disruptor的等待策略设置错误的问题，

修改策略后，重新上线恢复正常

 

 

[排查过程]

1、top 命令查看高cpu使用的进程 pid

2、top -Hp pid 查看该进程下的高CPU占用的线程 tid

3、将tid转为16进制形式 如 939 转换为16进制 0x3ab

4、jstack pid | grep -A10 "0x3ab" 即可查看该线程处的代码

 

[结果分析]

经排查发现该处代码为disruptor的代码，该框架为本次项目新加入的代码，而此时并未调用，那么为什么会产生如此高的cpu占用呢？

猜测1、disruptor初始化的时候会初始化ringbuffer，初始化ringbuffer是会创建设置数量的对象，代码中设置初始值为512*512，如此量级的创建，有可能短时间使cpu飙升

验证：jmap -histo pid查看对象情况

 

该数量表示，对象初始化已完毕，而cpu的占用仍旧100%，故排除该猜测

 

猜测2、disruptor定义了多种等待策略，等待策略设置的有问题

 

经查阅，常用的三种策略如下：

BlockingWaitStrategy 是最低效的策略，但其对CPU的消耗最小并且在各种不同部署环境中能提供更加一致的性能表现；
SleepingWaitStrategy 的性能表现跟 BlockingWaitStrategy 差不多，对 CPU 的消耗也类似，但其对生产者线程的影响最小，适合用于异步日志类似的场景；
YieldingWaitStrategy 的性能是最好的，适合用于低延迟的系统。在要求极高性能且事件处理线数小于 CPU 逻辑核心数的场景中，推荐使用此策略

 

如上，YieldingWaitStrategy策略性能最好，但是会占满cpu；代码中制定了该策略，至此，原因找到了；

 

调整策略为SleepingWaitStrategy ，问题解决！！