jvm故障排查

背景:

   服务在正常运营中,偶尔出现进程被杀死的情况,所以总结一下排查问题的方法


1.应用日志

   如:根据配置的logback-spring,logback配置的日志路径下去寻找


2.容器日志

  如:tomcat崩溃,去catalina.201X-XX-XX.log,localhost.201X-XX-XX.log等容器配置的日志文件中寻找


3.JVM奔溃日志

  当JVM发生致命错误导致崩溃时,会生成一个hs_err_pid_xxx.log这样的文件,该文件包含了导致 JVM crash 的重要信息,我们可以通过分析该文件定位到导致 JVM Crash 的原因,修复

  默认情况下,该文件是生成在工作目录下的,当然也可以通过 JVM 参数指定生成路径:

 -XX:ErrorFile=/var/log/hs_err_pid.log


4.系统日志

  (1)系统报错日志:/var/log/messages

     top查看资源占用情况(M排序由高到低)这是实时的参考率不大

     OOM killer(Out Of Memory killer),这个东西会在系统内存耗尽的情况下跳出来,选择性的干掉一些进程以求释放一些内存

     OOM killer是通过/proc//oom_score这个值来决定哪个进程被干掉的。这个值是系统综合进程的内存消耗量、CPU时间(utime + stime)、存活时间(uptime - start time)         和oom_adj计算出的,消耗内存越多分越高,存活时间越长分越低。总之,总的策略是:损失最少的工作,释放最大的内存同时不伤及无辜的用了很大内存的进程,并且杀掉的进         程数尽量少。


   我们可以开启dump core 和 启动配置内存泄露的jvm参数获取dump文件的方式获取错误资料,core和dump是可以互转的

  1)dumo core

    ulimit -c unlimited(开启)

     在/usr/local/apps/获取core文件

    gdb java core分析

  2)dump

    内存泄漏是指本应该被GC回收的无用对象没有被回收,导致的内存空间的浪费,当内存泄露严重时会导致OOM

    启动时配置jvm参数

   -XX:+HeapDumpOnOutOfMemoryError

   -XX:HeapDumpPath=/xx/java.hprof;

     注:+HeapDumpOnOutOfMemoryError  需要放在-jar前面

     如java  -XX:+PrintGCDetails  -XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/xx/java.hprof  -jarxx-1.0-SNAPSHOT.jar

     出现异常,可以去找配置路径的dump快照文件,接下来借助VisualVM这种可视化工具分析就行,定位问题。


(2)内核日志:dmesg

        去内核日志里头查询。有时Linux系统或者系统上运行的java或者其它进程,会发生一些莫名其妙的问题,比如突然挂掉了,比如突然重启等等。在软件上找不到问题所在,此时     我们应该怀疑硬件或者内核的问题,此时我们就可以使用 dmesg来查看:

  dmesg | grep java

   输出如下


你可能感兴趣的:(jvm故障排查)