月度归档:2014年12月

Tomcat无响应案例分析

问题描述

生产环境下有几台tomcat,但突然某个时候发现所有的请求都不能响应了,由于我们的web server使用的是nginx,会将请求反向到tomcat上,所以起初怀疑是nginx就没有收到请求,但查看日志后发现,nginx中大量出现499的返回,这说明问题还是出在tomcat上.

问题排查

  1. 首先我想到的是不是CPU跑满了,虽说CPU没有报警但还是本能的top命令看下系统负载,发现系统只有0.x的负载,cpu,内存消耗都是正常的.
  2. 由于CPU没有出现异常,所以应该不是GC出现了问题,但还是检查了下GC log,果然GC也没问题
  3. 此时必须让jstack上场了,果然在使用jstack后发现很多线程都是WAITING状态
  4. 阅读全文…

JVM GC问题排查手段

最近生产环境上出现过两次由于JVM参数设置不当导致的频繁FGC的问题,现在做个简单的记录.

  1. 首先查看GC日志,观察每次FGC的频率以及各个区的回收情况
  2. 然后再配合使用jstat与jmap查看是否有泄露问题,分析内存泄露最佳组合就是jamp dump + MAT,先dump内存,然后MAT分析来定位问题,要jmap -heap需要慎用,在用cms gc的情况下,有些时候jmap -heap会循环输出,然后就卡死了
  3. 最后使用jstack排查各线程的状态,包括用户线程和虚拟机线程,同时结合Lock信息来检测是否发生了死锁和死锁的线程.
    ​另外在用top -H看到占用CPU非常高的pid时,可以转换成16进制后在jstack dump出来的文件中搜索,看看到底是什么线程占用了CPU

总之,GC问题是一个需要不断跟进的问题,它会随着业务与技术发展而不断出现,需要用到很多方法与经验.