WebSphere宕机问题解决方法总结

Websphere参数调整

涉及性能的参数：

1、数据源连接池连接数

2、线程池：default参数

            ORB.THREAD.POOL参数

            Webcontainer 参数

3、jvm  堆最大最小值 ，线程池调大时3也要调大

建议Jvm堆最大值不要超过内存40%

会话管理中：内存中最大会话量

Was数据源属性：语句高速缓存大小 建议：200-500

但目前调回了30

Java虚拟机jvm 初始-Xms1024m -Xmx4096m

App上的 DCS  30

Web container (即单节点web线程数量) 80

WebSphere参数没有固定的数值，软硬件环境不同有可能参数值不同，所以不能一概而论，需要将以上因素在实际环境中进行反复调整并测试以期获得最优的参数值。另外，可以参考IBM的文档《WebSphere Performance Tuning.ppt》进行调整。

程序错误:

1参数定义中使用了：

select custid,cname from lixiao

select custid,cname from lixiao

lixiao表中有几十万条记录

还有的地方虽然使用了 select custid,cname from lixiaowhere region=? and custid=?

   但是在jsp页面上使用该标签时,condition传了空值，所以仍然按照没有条件的方式处理，将所有客户取出。

2.ecside的查询页面上，每页显示记录数（下拉列表）中，应该去掉【全部】选项，避免一次性查询全部的台账信息或其他记录数巨大的信息。Ecside界面上的打印、导出功能需要重写，道理与【全部】选项一样，就是避免因为客户在界面上的操作而导致查询大量的数据并在内存中生成大量的对象。

3使用findbugs插件（eclipse）查找到很多preparedStatement没有关闭。

正确的写法:

<span style="font-size:18px;">PreparedStatement pstmt=null;
ResultSet rs=null;
JDBCDataSource dataSource = getJDBCDataSource();
try{
StringBuffer sql=new StringBuffer(“select * from cicustbasinfo”);
   pstmt = dataSource.getConnection().preparedStatement(sql.toString());
   rs=pstmt.executeQuery();
   while(rs.next()){
// rs.get
    // 处理数据项
}
}catch(Exception e){
e.printStackTrace();
}finally{
if (rs!=null)
try{
rs.close();
}catch(Exception e){
e.printStackTrace();
}
rs=null;
}
if (pstmt!=null)
try{
pstmt.close();
}catch(Exception e){
e.printStackTrace();
}
pstmt=null;
}
}
而实际中有很多种错误的写法:
错误1：
循环打开，但不关闭，比如：
while([条件]){
pstmt= dataSource.getConnection().preparedStatement(sql.toString());
rs=pstmt.executeQuery();
}</span>

错误2：

为重复使用变量，只打开preparedStatement，但不关闭，比如：

<span style="font-size:18px;">pstmt= dataSource.getConnection().preparedStatement(sql.toString());
rs=pstmt.executeQuery();
while(rs.next){
  // 处理
}
pstmt= dataSource.getConnection().preparedStatement(sql.toString());
rs=pstmt.executeQuery();
while(rs.next){
  // 处理
}
有的情况下虽然写了close但没有放到finally块中，也是存在风险的，比如：
pstmt= dataSource.getConnection().preparedStatement(sql.toString());
rs=pstmt.executeQuery();
while(rs.next){
  // 处理
}
rs.close();
pstmt.close();
pstmt= dataSource.getConnection().preparedStatement(sql.toString());
rs=pstmt.executeQuery();
while(rs.next){
  // 处理
}
rs.close();
pstmt.close();
错误3：
写方法返回resultset，比如：
public ResultSet getResult(){
JDBCDataSource dataSource = getJDBCDataSource();
StringBuffer sql=new StringBuffer(“select * from cicustbasinfo”);
      PreparedStatement pstmt=null;
pstmt = dataSource.getConnection().preparedStatement(sql.toString());
   return pstmt.executeQuery();
}
然后再其他地方调用：
 ResultSet rs=getResult();
   // 处理rs
  此处错误在于：resultset的返回，因为这样不能确保方法的客户端能够关闭resultset，另外，更重要的是，客户端无法关闭preparedstatement。
错误4：
Finally中，关闭了，但是共用一个try，比如：
try{
  // 正常的程序块
}finally{
  try{
if (rs!=null)
rs.close();
rs=null;
}
if (pstmt!=null)
pstmt.close();
pstmt=null;
}
}catch(Exception e){
e.printStackTrace();
}
}</span>

此处错误在于：rs如果关闭时抛出异常，那么无法保证pstmt是被关闭的，事实上当rs异常时，会掠过pstmt的关闭。

4自动生成的DAO类中没有使用针对oracle的物理分页，oracle物理分页不仅可以解决sql效率问题，还可能使statement结果集占用的内存资源较少。

Oracle使用ResultSet.roll_insensitive时，有可能会带来资源问题，特别是结果集较大时，可能导致outofmemory异常。

注：所谓oracle物理分页即是：

select *

from ( select rownum rn,othercolumns

from 【table】

where rownum<=【page*pageSize】 )

  where rn>【(page-1)*pageSize】

page是当前页页号

pageSize是每页的记录数

此点是专门针对oracle DBMS而言的。

5规则引擎，在使用数据库中的自定义规则模式时，需要从Rules_drlruleset表中加载相应的规则，通过在RuleSetGetterFilter中加载这些自定义规则，加载方式就是按照规则类型和当前日期将所有规则都一次性读入，但是由于河北农信社现有的规则记录用于授信的（类型为cclmt）总共有9500多条，因此会造成大量的对象驻留内存，并且并发用户数有2000-3000人，其中走授信流程的用户数量较多，更造成了单位时间内的jvm heap迅速、大量被占用的问题。

解决方法：新实现RuleSetGetterFilter，以替代原来的RuleSetGetterFilter，在新的RuleSetGetterFilter中按照规则类型、当前日期、机构来加载规则。一个机构内的规则数量应该较小，最多不过40条。所以可以大大缓解授信流程传递时，jvm的压力。

程序问题的定位及分析：

定位导致websphere宕机的程序问题的关键在于：要使用ha.jar程序打开并分析websphere产生的heapdump文件。

但是要打开heapdump文件，ha.jar程序本身就要占用大量jvm堆内存，例如：1个1G多的heapdump文件，如果要打开，需要占用10G多的jvm堆内存，如此以来，此项分析工作只能在高性能的服务器上进行，但在一般项目中，如此条件难以达到。

在没有这样条件的情况下，还可以求助IBM的服务人员，但是效果不如自己分析的好。

另外javacore文件也可以用于分析web线程阻塞的情况，从而可以分析出程序对资源的释放是否存在问题。