快速定位bug_mqclientfactoryscheduledthread event executor term-CSDN博客

快速定位bug
一、响应报错
4XX 客户端报错
400 Bad Request
403没有权限
404 路由不存在
413 request entity too lang
请求体过大
1、修改nginx client_max_body_size 默认1m
配置文件
2、修改tomcat大小 server.tomcat.max.http.post.size 默认2m
3 、修改单个请求文件大小 spring.servlet.multipart.max.request.size
414 request url too lang
调整请求方案，不要做太长的请求
将get请求改为post请求
5XX服务端报错
500 internal server error 服务内部报错查看应用日志
502 Bad Gateway 网关错误，服务大概率挂了，
telnet ip:port 检查ip端口
curl 测试请求
504 Gateway time
请求超时
分析定位服务慢的原因，
修改nginx配置 proxy_connet_timeout
功能异常
对照排除
不同版本不同环境不同账号不同网络
逐层排除找出问题
性能问题

二，进程存在，服务响应慢

查看资源消耗情况内存 cpu 硬盘带宽
centOS自带 free -hm df -h ,top ,iftop -p, netstat
进程是否还在
jstack -l 进程pid命令查看所有线程堆栈是否有死锁
top -Hp 进程pid查看所有线程资源状态
jstack 进程pid| grep 线程pid十六进制(printf "%x\n" 线程pid)

服务CPU100%定位方法
1，执行top -c ，(-c显示进程详细名称)显示进程运行信息列表键入P (大写p)，进程按照CPU使用率排序

2，根据进程号找到对应的服务名
ps aux | fgrep 30914

3，找到最耗CPU的线程
top -Hp 10765 ，显示一个进程的线程运行信息列表键入P (大写p)，线程按照CPU使用率排序
4，将线程PID转化为16进制

printf “%x\n” 10804
5，查看堆栈，找到线程在干嘛

-F强制打印dump信息

jstack -F10765 | grep '0x2a34'

jstack Dump 日志文件中的线程状态

dump 文件里，值得关注的线程状态有：

死锁，Deadlock（重点关注）
执行中，Runnable
等待资源，Waiting on condition（重点关注）
等待获取监视器，Waiting on monitor entry（重点关注）
暂停，Suspended
对象等待中，Object.wait() 或 TIMED_WAITING
阻塞，Blocked（重点关注）
停止，Parked

三，进程不在了
1进程误被kill掉
2被操作系统kill掉 Linux的OOM killer ，不会导致jvm的 HeapDumpOnOutOfMemeryError
查看系统日志 /var/log/messages：
Oct 15 14:13:07 ticket05 kernel: java invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Oct 15 14:13:07 ticket05 kernel: Killed process 434 (java) total-vm:10250092kB, anon-rss:1859676kB, file-rss:0kB, shmem-rss:0kB
anon-rss+file-rss = 当时占用内存

3JVM 异常致命错误导致crash
4进程自己OOM
大概99%的JVM Crash 源自两个原因

内存不足 - Running Out of Native Memory

- 日志会以”There is insufficient [ˌɪnsəˈfɪʃn] memory for the Java Runtime Environment to continue.”(没有足够内存给Java Runtime Env)开头。
内存越界 - segmentation [ˌseɡmenˈteɪʃn] fault
- 日志会以”A fatal error has been detected by the Java Runtime Environment”(Java Runtime Env监测到致命错误)开头

案例1
- 某系统线上服务无响应，查看服务进程正常，查看服务日志打印不正常，几乎不打印。

解决方案：

1.将流量切换到备机上。
2. 通过 jstat -gc <pid> interval 观察，full gc频率偏高，时间偏长。进一步通过 jmap -dump:live,format=b,file=heap-dump.bin <pid> 将 heap 导出来进行分析，
看到 ExecutorService（十几个）实例偏多，结合客户反馈，在点击页面进行某个操作（具体哪个记不清了）越操作越卡，查看相应代码，整个流程偏长，
整个流程有多处不合理创建、使用线程池。按照定位方向在stage复现，修复问题。

结论：线程池使用不合理，导致服务资源耗尽，服务不可用（服务大概持续运行一周后就大概率报出异常）。

案例2
表现：某系统线上服务不可用。

解决方案：
查看日志，有OOM内容：
java.lang.OutOfMemoryError: GC overhead limit exceeded
Dumping heap to /data/logs/ecm/java_pid23954.hprof ...
Exception in thread "MQClientFactoryScheduledThread" Exception in thread "RxIoScheduler-1 (Evictor)" Exception in thread "RebalanceService" java.lang.OutOfMemoryError: GC overhead limit exceeded
可以知道MQClientFactoryScheduledThread引起OOM, 进一步查看 /data/logs/ecm/java_pid23954.hprof 文件未生成。
下方继续看到JVM Crash信息
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f8644274cbb, pid=23954, tid=0x00007f861fefe700
# JRE version: Java(TM) SE Runtime Environment (8.0_181-b13) (build 1.8.0_181-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.181-b13 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V [libjvm.so+0x699cbb] java_lang_Class::signers(oopDesc*)+0x1b
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

JVM Crash时，会将日志保存在 hs_err_pid<pid>.log 默认保存在工作目录，也可以通过JVM参数指定 -XX:ErrorFile=./hs_err_pid<pid>.log
tomcat日志里会看到日志保存的提示：
# An error report file with more information is saved as:
# /xxx/hs_err_pid<pid>.log

结论：MQClientFactoryScheduledThread 频繁创建未销毁引起OOM

参照地址：

https://www.cnblogs.com/shengulong/p/8513652.html