性能调优案例分享：jvm crash的原因 1

性能调优案例分享：jvm crash的原因

 

poptest是国内唯一一家培养测试开发工程师的培训机构，以学员能胜任自动化测试，性能测试，测试工具开发等工作为目标。如果对课程感兴趣，请大家咨询qq：908821478，咨询电话010-84505200。poptest培训的课堂上通过实际案例来帮助学员提高性能测试的能力，胜任企业性能测试的工作。

jboss服务器经常莫名地突然停止运行，查看jboss控制台错误日志，发现只有下面一行：

/opt/.../jboss/bin/run.sh: line 181: 26430 段错误                  "$JAVA" $JAVA_OPTS -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" -classpath "$JBOSS_CLASSPATH" org.jboss.Main "$@"

一开始对上面的错误日志也没引起重视，一直在找JVM crash的日志hs_err_<pid>， 看了很多网上的帖子，包括JVM官网的介绍，为什么没有生成hs_err_pid日志，可能的原因就是没权限或者空间不够，查看了磁盘空间是足够的，于是 想到可能没有权限（其实默认目录就是JVM的工作目录，应该是有权限的，但当时唯一能怀疑的就是这个），所以就想到JVM参数 （-XX:ErrorFile=./hs_err_<pid>.log）可以配置这个日志文件的保存目录，但这个参数是JDK1.6才引入 的，而我们系统杯催的还停留在JDK1.5上，没办法想到另外一个参数（-XX:OnError="<cmd args>;<cmd args>"），里面配置的命令是kill -3 <pid>，这样JVM在crash的时候可以将线程堆栈dump出来，想法是好的，可这个命令一直没配上去，只能作罢。

拿不到hs_err_<pid>日志，唯一的线索就是上面仅有的一行错误日志，于是google“段错误”“segmentation fault”，发现可以通过core dump日志进行分析，解决思路也就自然而然有了。

1.core dump介绍

程序异常退出（crash）时会自动生成一个core文件，包含了程序运行时的内存，寄存器状态，堆栈指针，内存管理等信息，也就是把程序当时工作的状态存储成一个文件。不仅仅是在出错的时候会生成core dump文件，在系统卡住或者cpu使用率很高的时候也可以手动触发生成core dump文件（当然这种情况也可以直接通过jmap和jstack dump出内存和线程堆栈，但JDK1.6以前，这2个命令经常执行不成功），这样就可以很好的分析了。

2.生成core dump文件

core dump文件生成开关其实是通过对生成的文件大小进行控制达到的，默认大小是0，也就是说默认是不生成core dump文件的，可以通过命令ulimit -c进行查看。将此参数修改成unlimited就可以生成core dump文件了，但值得注意的一点是，每个应用进程都会读取自己的一套系统参数，可以查看进程对应的内存文件/proc/<pid> /limits中的信息来判断修改后的参数值是否对此应用进程生效了，limits文件中的信息如下：

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            10485760             unlimited            bytes     
Max core file size        unlimited           unlimited            bytes    
Max resident set          unlimited            unlimited            bytes     
Max processes             20480                20480                processes 
Max open files            204800               204800               files     
Max locked memory         32768                32768                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       1024                 1024                 signals   
Max msgqueue size         819200               819200               bytes

上述信息中的对应的参数值为unlimited，代表此应用进程的core dump开关是开着的。ulimit -c unlimited这个命令可以在很多地方修改，比如用root在命令行执行，在/etc/profile中增加（/etc/profile文件中已经有 defaultulimit -S -c 0 > /dev/null 2>&1，可以直接修改0为unlimited），在用户的.bash_profile中增加..这些方式执行后的影响范围还是挺复杂的， 到现在也没弄清楚。当时通过root用户命令行修改后，在shell里查询ulimit -c是生效了，以为应用程序也生效了，觉得不用应用都不需要重启就生效了挺好，等到下一次crash的时候发现还是没有生成core dump文件，于是到文件/proc/<pid>/limits中检查此参数值才发现应用程序所读取的值还是0。后来采用一种比较简单直接的 方式，用root用户修改/etc/profile文件中的ulimit -c的值，然后重新登录，重启应用，再检查/proc/<pid>/limits中的值，确保参数已经生效，后来应用再crash时core dump文件也如期而至，心里暗爽，终于可以开始分析堆栈了。

core dump文件生成的默认路径在用户的工作目录（启动脚本目录），可以通过设置参数/proc/sys/kernel/core_pattern的值改变 core dump文件的最终生成路径及文件名格式。core dump文件成功后，在jboss控制台错误日志中的日志也多了core dumped关键字，如下：

/opt/.../jboss/bin/run.sh: line 181:  9176 段错误                  (core dumped) "$JAVA" $JAVA_OPTS -Djava.endorsed.dirs="$JBOSS_ENDORSED_DIRS" -classpath "$JBOSS_CLASSPATH" org.jboss.Main "$@"