WAS7一直吃虚拟内存到机器宕机，有啥好的解决思路
环境：
网站，前端f5,ihs
PowerVM虚拟AIX6.1
was7.0.0.11集群两节点
oracle 10G RAC
故障：
WAS7集群的两个节点AIX6.1系统宕机
分析结果：
1、宕机前was没有留下任何有用日志，因之前实施人员未调整was的日志文件大小和个数。
2、AIX的PS（虚拟内存）不停占用不释放，一直占满到宕机（直接原因），但是物理内存使用正常。
3、目前临时的解决办法3-5天交换重启一次was节点，可释放虚拟内存，保证系统正常运行。
4、现生成日志全部正常，基本是I，O级别日志，几条W，E级别日志属于正常情况。
5、外网网站，正常在线用户量预估20-30。现没有排除访问量激增和攻击的可能，前方工程师没有拿到故障时的IHS的log文件对访问量进行分析。
怀疑：
1、was7的BUG，未发现有此类BUG的相关信息（不确定）
2、web池设置太小，50-50（目前没有发现报不够使用的错误，暂时排除。）
3、应用连接数据库采用XML配置方式直连，没有使用was的数据池（目前没有发现连接数据库的相关错误，暂时排除。）
4、操作系统层面问题，排查无问题。（重启was解决问题，暂时排除。）
5、访问量激增和攻击（未确认，但是访问量正常时虚拟内存也在一直占用不释放，可能性比较小）
6、代码问题，系统上线运行一年以上，并为出现过类似问题。（暂时排除）
谁有过类似的故障解决办法，分享一下。
网站，前端f5,ihs
PowerVM虚拟AIX6.1
was7.0.0.11集群两节点
oracle 10G RAC
故障：
WAS7集群的两个节点AIX6.1系统宕机
分析结果：
1、宕机前was没有留下任何有用日志，因之前实施人员未调整was的日志文件大小和个数。
2、AIX的PS（虚拟内存）不停占用不释放，一直占满到宕机（直接原因），但是物理内存使用正常。
3、目前临时的解决办法3-5天交换重启一次was节点，可释放虚拟内存，保证系统正常运行。
4、现生成日志全部正常，基本是I，O级别日志，几条W，E级别日志属于正常情况。
5、外网网站，正常在线用户量预估20-30。现没有排除访问量激增和攻击的可能，前方工程师没有拿到故障时的IHS的log文件对访问量进行分析。
怀疑：
1、was7的BUG，未发现有此类BUG的相关信息（不确定）
2、web池设置太小，50-50（目前没有发现报不够使用的错误，暂时排除。）
3、应用连接数据库采用XML配置方式直连，没有使用was的数据池（目前没有发现连接数据库的相关错误，暂时排除。）
4、操作系统层面问题，排查无问题。（重启was解决问题，暂时排除。）
5、访问量激增和攻击（未确认，但是访问量正常时虚拟内存也在一直占用不释放，可能性比较小）
6、代码问题，系统上线运行一年以上，并为出现过类似问题。（暂时排除）
谁有过类似的故障解决办法，分享一下。
17同行回答
期待最终结果啊，究竟是什么原因？收起
浏览1815
关于此问题通过IBM的实验室给出已知BUG如下，进行测试
1、IV46157: NATIVE OOM ON AIX 64BIT PLATFORM WHEN COMPRESSED REFERENCES ENAB LED
JVM参数：-Xgc:preferredHeapBase=0x100000000
http://www-01.ibm.com/support/docview.wss?uid=swg1IV46157
2、使用反射代理类加载器的潜在内存使用问题
http://www-01.ibm.com/support/docview.wss?uid=swg21636746
JVM参数：-Dsun.reflect.inflationThreshold=0
等待测试结果收起
1、IV46157: NATIVE OOM ON AIX 64BIT PLATFORM WHEN COMPRESSED REFERENCES ENAB LED
JVM参数：-Xgc:preferredHeapBase=0x100000000
http://www-01.ibm.com/support/docview.wss?uid=swg1IV46157
2、使用反射代理类加载器的潜在内存使用问题
http://www-01.ibm.com/support/docview.wss?uid=swg21636746
JVM参数：-Dsun.reflect.inflationThreshold=0
等待测试结果收起
浏览1896
浏览1864
烩总：从was层面也可以分析，具体分析办法如下(仅个人意见，非权威)：
1、 JVM日志的目录
WASHOME/profiles/yourprofile/logs/yourserver/native_stderr.log 和 native_stdout.log
2、 日志收集方式方法，在用系统的日志收集
进入DM控制台
选中
系统管理->Deployment Manager->Java和进程管理->进程定义->Java虚拟机->详细垃圾回收(保存配置后重新启动服务生效)
系统管理->Deployment Manager->Java和进程管理->进程定义->Java虚拟机->运行时->详细垃圾回收(确认后立即生效)
3、如何手动的生成javacore、heapdump文件
系统管理->Deployment Manager->Java和进程管理->进程定义->Java虚拟机->通用 JVM 实参
写入-Xdump:java+heap:events=user
重启服务后生效。
kill -3 pid后就可以直接生成javacore和heapdump文件 后可在
/wps/WebSphere/AppServer/profiles/Dmgr01下生成
javacore.20130607.202533.2629.0002.txt
heapdump.20130607.202831.2629.0003.phd
文件
4、
步骤: STEP1:下载PMAT, ga441.zip
Step2:解压,打开终端,cd到解压的目录
Step3:java –Xmx1000m –jar ga441.jar
Step4:ga窗口中,打开native_stderr.log
可以看到内存的大体消耗图。收起
1、 JVM日志的目录
WASHOME/profiles/yourprofile/logs/yourserver/native_stderr.log 和 native_stdout.log
2、 日志收集方式方法，在用系统的日志收集
进入DM控制台
选中
系统管理->Deployment Manager->Java和进程管理->进程定义->Java虚拟机->详细垃圾回收(保存配置后重新启动服务生效)
系统管理->Deployment Manager->Java和进程管理->进程定义->Java虚拟机->运行时->详细垃圾回收(确认后立即生效)
3、如何手动的生成javacore、heapdump文件
系统管理->Deployment Manager->Java和进程管理->进程定义->Java虚拟机->通用 JVM 实参
写入-Xdump:java+heap:events=user
重启服务后生效。
kill -3 pid后就可以直接生成javacore和heapdump文件 后可在
/wps/WebSphere/AppServer/profiles/Dmgr01下生成
javacore.20130607.202533.2629.0002.txt
heapdump.20130607.202831.2629.0003.phd
文件
4、
步骤: STEP1:下载PMAT, ga441.zip
Step2:解压,打开终端,cd到解压的目录
Step3:java –Xmx1000m –jar ga441.jar
Step4:ga窗口中,打开native_stderr.log
可以看到内存的大体消耗图。收起
浏览2134
浏览2041