jvm故障排查

Posted 2023-02-19

参考技术A 背景：

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

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/<pid>/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

   输出如下