这里先说下分析前的准备工作:
1, 如果你的linux机器是没有界面操作的,那么你得在操作终端这边安装xmanager,否则可以跳过以下2-5。测试方法可以直接拍入oclock测试。
2, 以下2-5演示的是实现操作终端机器通过xmanager来获取界面操作支持的。
3, 你需要在服务端配置环境变量DISPLAY,本人客户端的ip地址是(10.192.33.200),所以在服务端的配置环境变量如以下示例:
[was6@ ~]$ echo $DISPLAY
10.192.33.200:0.0
4,你需要在终端操作机器上面安装xmanager,安装好了以后你可以看到如下启动快捷键,点击Xmanager –Passive,打开客户端监听:
服务端运行oclock测试是否可以支持界面操作,如果正常可以看到如下:
5, 至此xmanager图形界面操作部分完成。
6, 首先把运行工具上传至服务器的目录。
6.1,下面列举的是分析javacore的必要jar包和配置文件,可以通过下载获取。
[was6@tools]$ ls jca*
jca396.jar jca.properties.xml
6.2,下面列举的是分析heapdump的必要jar包,可以通过下载获取。
[was6@tools]$ ls ha404*
ha404.jar
7, 上传需要分析的javacore和heapdump文件到指定的分析目录,可以通过命令生成获取(http://blog.csdn.net/w5222949/article/details/8362990),或者是宕机的生产服务器上拿到。
[was6@tools]$ ls javacore*
javacore.20130115.150913.21636.0003.txt javacore.20130115.150913.21636.0005.txt javacore.20130115.150913.21636.0011.txt javacore.20130115.150913.21636.0012.txt
[was6@tools]$ ls heap*
heapdump.20130115.150913.21636.0004.phd
7, 对应的分析服务器上面最后有对应于生产环境的was环境,尤其是jdk版本,这个很重要,IBM自身带的jdk才能加载足够大的内存来打开heapdump文件,如果用的是sun的jdk的话估计就有问题了。
8, 这里先运行下jca工具分析javacore。
[was6@tools]$ ~/IBM/WebSphere/AppServer/java/bin/java -Xmx10000M -jar jca396.jar
9, 可以看到终端机画面,然后打开需要分析的javacore文件。
10, 点击小红框圈住的明细比对:
这里上面的最主要查看的是里面带褐色小方框的线程,这个标识表示的是block的状态,线程阻塞,如果几个javacore里面显示的都是同一个线程bolck,那表示这个线程就存在阻塞情况,需要对右边对应的堆栈信息好好分析,结合java代码看看问题出现在那。
另一个就是分析绿色标识的,表示的是运行状态,如果某个通讯或者连接的运行状态过多,一旦有超时,也有可能导致线程池相关的一些问题,如下图:
11, 下面分析下heapdump文件
[was6@tools]$ ~/IBM/WebSphere/AppServer/java/bin/java -Xmx10000M -jar ha404.jar
12, 这里由于文件比较大打开会比较费时,需要耐心等待,这里也许会报错:
这个需要设置下服务器的字符集为GBK,重新打开dump文件。
如下操作:
[was6@tools]$ set|grep UTF-8
LANG=en_US.UTF-8
[was6@tools]$ LANG=en_ZH.GBK
[was6@tools]$ set|grep GBK
LANG=en_ZH.GBK
13, 字符集设置完成以后,再按上面的运行方式打开dump文件:
得到最后导致内存使用过高的都是hashmap的线程导致的。