最近做的项目系统即将上线，一直在搞性能压力测试。由于WAS7 也是第一次在项目上使用，发现了不少问题，也积累了一些经验。下面就发现的一些问题做一些总结。
首先环境描述：
操作系统： RHEL 5.5
应用服务器： WAS 7ND + IHS7
数据库：Orcale 11g RAC
应用服务器 3台机器，一台运行IHS，并当文件服务器运行。 另外2台 WAS7 集群，每台机器3个Server 。2台数据库服务器集群。
先说一下压力测试的几个测试重点和其中发现的问题：
1、用户并发登录测试
用户并发登录测试，项目要求达到的最低要求是200的并发登录。 我们自己的预想的要求是每个单节点最少并发50，集群环境并发300左右。并能够持续承受压力8小时。
这个地方的压力测试出了非常低级、搞笑的错误，导致压力测试结果非常不理想。现象就是单节点压力测试，50并发，基本上半个小时后就内存溢出，然后宕机。 LoudRunner 显示的成功完成事务数量是12000次左右。 这个问题查了很久，也找了IBM的服务，花了1个多星期的时间，最后分析了内存溢出的dump文件，才发现导致内存溢出的是因为session对象太多，占用了系统大量内存。
后来问测试人员，压力测试的脚本是怎么录的，才发现原来压力测试的时候，只录入了登录，没有录入退出。这种测试脚本一运行，就会不断的在WAS服务器上产生session以及应用系统中缓存在session中的对象，不点退出session 释放不了，内存无法回收，结果导致怎么压都是死。修改测试脚本，加上退出的动作之后，重新测试，结果就比较理想了，没再出过内存溢出的问题。
呜呼哀哉。。。 希望压力测试的时候，测试人员以后别犯这种低级错误了。真是浪费人力。不过话说回来，我们的平台框架在设计的时候应该也是有点问题的。因为在session中存入了大量的对象，这肯定会限制单个节点的最大用户在线数量。就目前的压力测试情况来看，如果系统有12000个用户在线的话，系统就死翘翘了。
这个就是属于登录平台的问题，不是简单可以解决的。
2、工作流业务提交并发测试
工作流的测试也分为2块，单节点的流程提交和集群环境下的流程数据提交。单点测试50并发，基本上通过测试。
但是集群环境下就出现了问题。压力测试到一定时间之后，在后台就会出现线程挂起的异常。从而导致WAS的某个节点宕机，最终也会导致IHS也死掉。
下面是出错日志摘要：
IHS error.log ：
[Thu Oct 20 10:58:24 2011] [notice] mpmstats: reached MaxClients (4000/4000)
[Thu Oct 20 10:58:24 2011] [notice] mpmstats: rdy 0 bsy 4000 rd 0 wr 4000 ka 0 log 0 dns 0 cls 0
[Thu Oct 20 10:59:54 2011] [notice] mpmstats: reached MaxClients (4000/4000)
[Thu Oct 20 10:59:54 2011] [notice] mpmstats: rdy 0 bsy 4000 rd 0 wr 4000 ka 0 log 0 dns 0 cls 0
[Thu Oct 20 11:01:24 2011] [notice] mpmstats: reached MaxClients (4000/4000)
[Thu Oct 20 11:01:24 2011] [notice] mpmstats: rdy 0 bsy 4000 rd 0 wr 4000 ka 0 log 0 dns 0 cls 0
[Thu Oct 20 11:02:54 2011] [notice] mpmstats: reached MaxClients (4000/4000)
[Thu Oct 20 11:02:54 2011] [notice] mpmstats: rdy 0 bsy 4000 rd 0 wr 4000 ka 0 log 0 dns 0 cls 0
其中最明显的错误就是： mpmstats: reached MaxClients 这段了。 表示IHS的已经达到最大连接数，无法接受新的请求。 而且即使停掉压力测试，连接也无法释放。最后只能重启IHS。
对应WAS后台，一般只有一个节点出现线程挂起的异常。SystemOut.log 日志如下：
[11-10-21 3:28:12:760 CST] 000001f1 ThreadMonitor W WSVR0605W: 线程”WebContainer : 662″（000002f4）已保持活动状态 621688 毫秒，此线程可能已挂起。在服务器中共有 177 个线程可能处于挂起状态。
at java.util.Collections$SynchronizedSet.hashCode(Collections.java:835)
at com.ibm.ejs.j2c.PoolManager$SubjectHashCode.run(PoolManager.java:4948)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)
at com.ibm.ejs.j2c.PoolManager.computeHashCode(PoolManager.java:4623)
at com.ibm.ejs.j2c.PoolManager.reserve(PoolManager.java:2190)
at com.ibm.ejs.j2c.ConnectionManager.allocateMCWrapper(ConnectionManager.java:1063)
at com.ibm.ejs.j2c.ConnectionManager.allocateConnection(ConnectionManager.java:700)
at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:668)
at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:635)
从日志看，线程挂起在获取数据源连接的地方。问题可能是由于集群环境下获取数据源出现死锁，从而导致资源无法释放，最终线程池被耗尽，线程挂起。 最后只能重启WAS服务。
这个问题的解决办法是：在数据源里面增加一个参数 useRRASetEquals 设置为 true
添加路径：
资源 -> JDBC -> XXX数据源->定制属性 -> 新建
增加参数： useRRASetEquals ，值为 true , 类型为 java.lang.Boolean
加上这个参数之后，再做测试，则上述问题解决。 集群环境下能够支撑200并发提交工作流请求，持续运行2天。
这个参数应该是WAS7新加的，因为加这个参数有版本要求，必须是 7.0.0.13 之后的版本，否则会报错。
3、附件上传数据流量测试
这个模块目前正在测试，如有问题再说。
WAS7集群上传下载问题分析及动静分离
继续去年没写完的文档，由于时间比较忙一直没来得及总结。虽然系统已经上线运行快4个月了。中间出了一些大大小小的问题，下面就一一说明。
上次是写到第3点：附件上传数据流量测试
文件上传的测试，通过测试工具进行测试基本上没发现太大的问题，不过由于测试环境的网络比较好，所以也很难发现问题。正式上线之后文件的上传这块也没太大的问题，因为有问题也最多是上传不了数据。J
但是对于附件的下载这块却没有进行比较好的测试，导致上线的2个星期都出现了一个大问题。
问题主要出现在网站这块， 由于网站上有提供不少帮助文档、安装包程序的下载，同时网站的访问量也非常大，导致网站频繁死机。 最多的一天死8次机，最短时间是在启动之后5分钟就down 机了。
先说网站服务环境：
操作系统： RHEL 5.5
应用服务器： WAS 7 单节点 。部署了3个应用分别是： cms 是网站， fileStorage_war 是附件目录及下载应用，qyww 是数据查询应用
数据库：Orcale 11g
从环境的配置上来说，也可以看出比较大的问题，网站这种面向公众的服务，其压力可能比内网的业务系统的服务压力还要大，这点由于我们设计上的疏忽导致了频繁死机的重要原因之一。
其实一开始为什么会这种设计，是因为我们做过网站的压力测试，可以支持到4000的并发访问，而且这个测试结果是由专门的测试公司做的，有了这个数据，我们项目组上对于网站这块才没太多的关注，在服务器配置上也没做集群。而且这个网站又是一个政府事业部门的网站，按照惯例我们认为访问的人不会太多。谁知道结果真是出人意料，内网的业务系统没怎么死机，反而外网的网站却是频繁死机。客户因为这个，都打电话投诉到北京总部去了。
真是血的教训啊。。。废话不说了，直接说怎么解决问题吧。
解决方案一：
由于时间比较紧，为了增加网站的稳定性和访问量支持，就需要对网站的部署架构进行调整，增加服务器配置，同时采用集群的方式来支持网站应用。目前的单节点一旦出现问题，就会导致整个服务都停掉，如果采用集群的话再加上IHS做动静分离，起码从稳定性上能够得到很大的保证。
这种方式应该是比较好的解决办法，但是我们一提出来就遭到客户痛骂。为啥呢？服务器的设备采购早就做完了，没有服务器用了。因为客户的预算也是要审批的，而且客户也不会为了这个再去采购新的服务器，客户对于我们以增加设备来解决问题的办法也很反感，骂完一顿之后，连旧设备都不给一台，要求我们在现有设备基础上解决问题，。
没办法这个方案就此无疾而终了，谁要我们一开始没设计好呢，事后要再追加设备是没这么简单的事情了。
解决方案二：
以下文章点击率最高
Loading…