|
这里只是进行回忆和梳理了一下,因为很久之前的,所以没有截图,具体截图可以参考我之前写的《线上故障排查思路》那个文章
1.GC问题排查
频繁GC导致系统卡顿
(1)现象: 服务器更新后,每到上班高峰期就出现卡顿情况
(2)通过jinfo查看服务器jvm配置,jvm内存为4G,新生代和老年代都是2G,edgn 为1.6G s0 为0.2G
(3)通过jstat查看gc情况,发现有频繁的fgc,大概半个小时一次
(4)通过监控平台查看,发现35分钟一次,每次挥手500M左右
(5)Jmap查看堆状态,最大的对象是一个string 和char
(6)堆快照下载下来,jmat分析堆快照,发现一个hashmap大对象大概100M,但是经过排查发现这个是预加载的一些数据,加载后就没有在操作过
(7)这时候思路没了,在进行各方面排查,最终发现一个第二大的对象,这个对象占大约20M左右,分析这个对象生成位置,定位到这个是人脸识别厂商提供的开发接口jar包,里面是把人脸识别服务器的消息存到一个阻塞队列里,当我处理不过来时,就会在队列里堆积,使这些对象生命周期变长,进而晋升到老年代,大约每分钟产生20M
(8)经过计算基本符合前面查看到的gc情况
(9)解决方案:
① 我这读到后,先不消费这些消息,先把他们放到MQ队列中,然后再慢慢消费
②优化消费逻辑,提升消费速度
2.Tomcat 假死宕机问题
(1)现象 :服务出现响应慢,最终出现Nginx超时界面,tomcat日志停止
(2)初步判断是服务器卡死,这里可能有两种情况
①服务器内存或者CPU爆满导致服务器卡死
②项目出现死锁导致卡死
(3)Top指令查看整个服务器的内存和cpu使用率,以及top界面右上角负载信息
(4)通过jinfo,jmap等指令查看内存信息和jvm配置信息
(5)这些信息都正常,通过jstack指令和进程id 查看tomcat 线程信息,这里没有发现死锁情况
(6)后来经过观察这里出现很多waiting线程,这些线程都停在了同一个地方
(7)查看是druid中的takelast()方法,经过查看源码发现这个是调用了阻塞队列的take方法,没有超时时间, 这里应该是调用polllast 加上超时时间的,定位到问题时druid线程池没有配置waittime线程池参数,默认是-1,即不超时,无限等待
(8)最后查看配置发现是因为上线时运维弄错了配置文件,使用了test文件,默认demo配置,最大连接数也是只有15个
(9)但是我感觉问题不只是这些,根本原因可能是慢查询导致的,druid监控页面上找到几个慢查询语句,通过explain分析sql执行过程,进行优化重新上线,问题解决
|