本文记录了一次由于jmap检测脚本引发的Dubbo服务超时及CPU高负载问题的排查过程。通过分析日志、JVM状态、GC日志，发现频繁的Full GC（Heap Inspection Initiated GC）导致服务器负载增加，影响了Dubbo服务。最终解决方法是停止执行jmap脚本，CPU使用率恢复正常，超时问题得到缓解。
记一次Dubbo超时&CPU高负载问题排查
1.问题背景
最近经常有同事反馈我们灰度环境老的交易系统，这里简称trade，dubbo消费者调用其他服务超时，因为该项目维护人员众多，加上灰度环境发布较多，一直没有排查，然后五一前再次有同事反馈这个问题，刚好有空就准备分析一下引起超时的原因。
2.问题排查
2-1 问题描述
大量Dubbo服务调用超时
2-2 问题排查
查看日志（上图）发现dubbo超时日志里面的两个时间异常
client elapsed ,server elapsed 时间较长，加起来超过了timeout时间3s，导致服务超时，其中client elapsed 达到了699ms，看到这里第一感觉是很惊讶，为啥消费者端会花费这么长的时间
带着这个疑问，首先确认了这个时间的计算逻辑，具体源码见附图
error日志
最低0.47元/天 解锁文章
扫一扫
1451
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
