一次线上死循环的排查

1、问题发现

      Prometheus报警某服务的一个节点 Old GC过多,需要排查。

2、查看GC日志

      使用tail -f gc.log命令查看异常节点的GC日志,从日志可以看出Young GC过于频繁,竟然在1s内有9次Young GC:
866783-20190702222925356-1348332451.jpg
      使用tail -f gc.log命令查看正常节点的GC日志,从日志可以看出,正常节点,很久才进行一次Young GC:
866783-20190702223241912-1435531101.jpg
      两个节点的JVM参数配置是完全一样的,并且负载均衡策略使用的是Ribbon默认的轮询策略,也就是说,两个节点能够接受到的请求是均衡的,不存在一个节点比另一个阶段负载大的情况。
      使用jstat命令查看异常节点的Young GC频率,发现确实存在异常:
866783-20190702223938205-216600424.jpg

3、使用jps命令找出该应用进程的pid,再使用top -Hp pid命令查看该进程下占用CPU最多的线程id:

866783-20190702224438852-1142362658.jpg

4、将查到的线程id 9182,使用printf "%x\n" 9182命令,转换为16进制:

866783-20190702224752213-306197600.jpg

5、使用jstack 9088 | grep 23de -A 30命令查看堆栈信息(多次查看):

      第一次:
866783-20190702224953021-1334192147.jpg
      第二次:
866783-20190702225104977-38226836.jpg
      该线程一直处于Running状态,并且两次查看中发现,堆栈中有共同的方法调用,怀疑问题可能发生在RedPackUtilV3.java:169处,需要查看业务同学代码。

6、查看业务同学代码

866783-20190702230322282-1549931679.png
发现极有可能是while循环中break条件一直没成立,导致了死循环,最后就请业务同学自己检查代码逻辑了。

转载于:https://www.cnblogs.com/cuizhiquan/p/11123559.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值