jboss宕机排查
问题描述
现有公司某产品运行在jboss上,线上运行一段时间后会出现宕机现象,宕机频率为2周左右。每次宕机后需要重新启动jboss后应用才可使用。运维人员已经多次反馈,此问题影响客户体验,急需解决。
问题排查思路
- 网络层。运维人员已有监控,对jboss应用HTTP接入端口9999进行了监听,如果9999端口无响应时,应用无法对外提供服务。此时在网络层Telnet检查9999端口是否可用,同时发送HTTP请求,检查是否有返回。
- 线程日志。抓取线程日志,检查是否存在死锁等情况。
- 内存堆栈。抓取线程日志,分析是否存在超大对象未释放。
- 分析jboss日志,对gc.log、boot.log、server.log等jboss日志与应用日志进行分析,检查报错信息。
问题排查步骤
准备应用日志抓取脚本
- 网络监听脚本:checklink.sh
- 应用端口状态脚本:checknetstat.sh
- 线程日志脚本:checkjstack.sh
- 内存堆栈脚本: checkjmap.sh
具体脚本内容见附件1
应用正常运行时抓取对照组
应用正常运行时,执行日志抓取脚本得到日志文件,作为结果对照组。
宕机时抓取日志
应用宕机时,执行日志抓取脚本,抓取错误日志。并取下当天jboss日志与应用日志。
结果分析
对比两次checklink.sh结果
端口都是处于监听状态,配置应用端口与对照组一致。初步排除网络问题,问题应该在应用层。
对比两次checkjstack.sh结果
两次结果中,比参照组中少了红色部分,当中并未异常线程,同时整个日志中并未查询到死锁等情况。初步排除应用有线程死锁等现象。
对比两次checkjmap.sh结果
将jmap执行出的.hprof文件,使用Eclipse Memory Analyzer Tools进行分析,整体内存占用情况如下:
对比两次结果,内存明显增长,逼近配置的最大内存1G。对照组为宕机前3天获取,3天内存由原来的761增长至94