WebSphere Dump文件分析
各位大侠好：
最近我们的系统频率出现WebSphere JVM宕死的情况，其实就是几天死一次，正常运行的情况下看不出任何异常，一但问题发生，DB Connection Pool在一分钟就能满，Web Container中的Thread Pool也会满。
附件是websphere 的 dump 文件，希望对这个熟悉的人能帮忙分析看问题出在哪。
在此多谢！
简单描述：
1.正常运行时，什么都正常，就是说DB Pool,Thread Pool都很正常
2.几天一次JVM死，DB Pool,Thread Pool全满，不能再响应其它请求
3.有个应用程序使用Hibernate，不知道并发多时这个会不会有问题？
4.其它JVM中的DB DataSource连接相同Oracle数据库，没有出现问题。应该说DB Server那边没问题。
5.为什么DB Connection挂起，在等待什么？是不是资源锁定？还是有程序使用DB连接没释放掉。其实很难解释，因为问题只是偶尔发生。并发越多，发生的几率越高。
最近我们的系统频率出现WebSphere JVM宕死的情况，其实就是几天死一次，正常运行的情况下看不出任何异常，一但问题发生，DB Connection Pool在一分钟就能满，Web Container中的Thread Pool也会满。
附件是websphere 的 dump 文件，希望对这个熟悉的人能帮忙分析看问题出在哪。
在此多谢！
简单描述：
1.正常运行时，什么都正常，就是说DB Pool,Thread Pool都很正常
2.几天一次JVM死，DB Pool,Thread Pool全满，不能再响应其它请求
3.有个应用程序使用Hibernate，不知道并发多时这个会不会有问题？
4.其它JVM中的DB DataSource连接相同Oracle数据库，没有出现问题。应该说DB Server那边没问题。
5.为什么DB Connection挂起，在等待什么？是不是资源锁定？还是有程序使用DB连接没释放掉。其实很难解释，因为问题只是偶尔发生。并发越多，发生的几率越高。
附件：
dump.rar (290.85 KB)
9同行回答
Operating System : AIX 5.3.0.0
Processor Architecture : POWER_PC (impl: unknown, ver: unknown)
Number of Processors : 16
Java version : J2RE 1.4.2 IBM AIX 5L for PowerPC (64 bit JVM) build caix64142-20080515 (SR11)
Java Heap Information
Maximum Java heap size : 1536m
Initial Java heap size : 256m
将GC与System*.log及ffdc打包放上来看看。收起
Processor Architecture : POWER_PC (impl: unknown, ver: unknown)
Number of Processors : 16
Java version : J2RE 1.4.2 IBM AIX 5L for PowerPC (64 bit JVM) build caix64142-20080515 (SR11)
Java Heap Information
Maximum Java heap size : 1536m
Initial Java heap size : 256m
将GC与System*.log及ffdc打包放上来看看。收起
浏览1297
看看是啥！收起
浏览1281
webcontain15这个线程堵塞了大量的webcontain线程，导致程序跑不下去，重点关注下这里浏览1295
楼主太财迷了，2分的问题，附件还要1分。
你是不是在国税局干过呀收起
你是不是在国税局干过呀收起
浏览1311
select
sqlarea.*,sesion.sid,
sesion.serial#,
sesion.username
from v$session sesion JOIN v$sqlarea sqlarea ON sesion.prev_SQL_ID = sqlarea.sql_id;
如果sql_text字段返回大量相同的SQL语句，则能说明程序里没有关闭连接。收起
sqlarea.*,sesion.sid,
sesion.serial#,
sesion.username
from v$session sesion JOIN v$sqlarea sqlarea ON sesion.prev_SQL_ID = sqlarea.sql_id;
如果sql_text字段返回大量相同的SQL语句，则能说明程序里没有关闭连接。收起
浏览1331
很可能是应用程序造成的。
可能是数据表锁定造成－－某个功能点的程序实现不严谨。
我曾经碰到过一次系统不定期的数据源满池，折腾了两个月，最后聘用专家人天解决定位的。
你可以从三个方向着手分析可能点：
1.每次故障时查看数据库，是否有运行很久了的或者死锁的session、sql
2.分析core文件，看看跑得最多最久的事务
3.根据systemout日志输出的日志，“可能有*个数据源处于挂起状态，时间为*ms”，算出当时问题页面的访问时间
然后在IHS日志里查看用户访问日志，那个时间是什么页面（一般在common中打开%T，可以看到页面请求的处理时间，其问题页面处理时间会很长），然后让应用管理员分析其功能程序，是否有漏洞。
这样方便定位到是哪块程序造成的。收起
可能是数据表锁定造成－－某个功能点的程序实现不严谨。
我曾经碰到过一次系统不定期的数据源满池，折腾了两个月，最后聘用专家人天解决定位的。
你可以从三个方向着手分析可能点：
1.每次故障时查看数据库，是否有运行很久了的或者死锁的session、sql
2.分析core文件，看看跑得最多最久的事务
3.根据systemout日志输出的日志，“可能有*个数据源处于挂起状态，时间为*ms”，算出当时问题页面的访问时间
然后在IHS日志里查看用户访问日志，那个时间是什么页面（一般在common中打开%T，可以看到页面请求的处理时间，其问题页面处理时间会很长），然后让应用管理员分析其功能程序，是否有漏洞。
这样方便定位到是哪块程序造成的。收起
浏览1320