性能测试——记XX银行电票系统上线后宕机问题诊断优化

四月份我们公司负责的电票系统上线了，这个系统上线比客户方其他系统上线还特殊，是二期改造项目，旧系统数据还要整合抽取到新系统中继续使用，而且该系统不是增量型方式开发上线的，而且全部开发完后全国上线的，这样开发压力大，测试人员压力也很大，由于环境问题以及在接近上线前客户方还在做需求变更，导致上线后出现了不少缺陷问题，两周后大部分问题还好都得以解决。而在上线前由于多种原因，我们性能测试人员根据项目调研提供的典型交易进行测试发现了不少问题，但是由于开发人员还在忙于需求变更等开发工作，对我们发现的性能问题都没时间加以解决，因此上线不到一周服务器几乎每天都要重启，不是应用服务器宕机就是数据库服务器宕机客户方着急了，在项目组客户方以及项目经理的要求下，我跟他们去客户机房现场查看分析问题。因为生产环境不能像测试环境那边乱DUMP日志也不能开启其他诊断分析工具，重启、修改参数、加监控参数等都是要他们客户方总行领导审批才行，确实对诊断带来很大的不便。没办法数据库问题只能自己写查询性能试图方式和GLANCE等监控方式发现数据库死锁问题是因为全表扫描引起的有些字段索引走法有问题引起的，建议他们对一些表重建索引解决了部分数据库问题，但是很多都是多表链接查询而且都是左链接方式来实现的，这种在生产线确实不能随意乱改，只能建议他们对查询语法进行SQL 改造，项目组接纳了我部分意见解决了部分问题，对于SQL改造只能等后期上版本才能解决，解决了部分数据库问题燃眉之急就行。

而weblogic应用服务器也是频繁宕机，而且差不多到中午就宕机了，根本没办法支持客户方业务人员一天正常上班8个小时之内工作，最多支持4个小时估计就不行了，经日志分析发现频繁报出java.lang.OutOfMemoryError: GC overhead limit exceeded、java.lang.OutOfMemoryError: Java heap space问题。，看了他们的服务器是4C8G两台，4个实例，JVM 配置-Xms1200m -Xmx1200m  -XX:MaxPermSize=256m，感觉配置不合理，因为这些是根据客户方提供的参数配置说明给我们公司人员配置的，而这种配置算是公共性的保守配置方法，对不同的应用系统实际状况不同应该加以调整，而且他们项目很多查询一个查询功能点查询的字段很多都是超过40个查询字段有些上八十个很不合理，但是是客户方要求的没办法，而且有些查询数据量很大确是使用前台分页查询，但是这些设计问题一下子没办法解决，客户方要求我能最快想出解决当前问题方法，没办法我只能跟客户方领导说可以通过参数调整解决临时问题，但是只能算是治标不能治本最终问题还是程序设计等问题。在客户方的要求下，给他们提供了最新的参数配置方案“-Xms1024m -Xmx1024m -XX:NewSize=384m -XX:MaxNewSize=384m -XX:PermSize=256m -XX:MaxPermSize=256m “，结果被客户方的总行管理领导否决，原因是年轻代设置太大了，不接受，我就给他们解决了他们项目的特殊情况，他们也请了对SUN JVM和对WEBLOGIC比较熟悉的专家来好像也是不接受我的意见，没办法，不接受我也提供不了其他优化方案了，但是那些高手也没提供出什么好的方案，我还是坚持我的方法因为他们项目很多特殊原因不得不这样调整，而且这也是合理接收参数配置范围，搞不明白他们为什么不采纳。

但是后期问题还是出现，我也跟客户方领导解释了下，我为什么这样配置的想法，可能是没有其他方案了，死马当活马医了，最终采纳我的方案，问题还真到现在都没出现过。但是时间久了肯定还是有问题，我于是推荐他们在没解决程序问题之前，可以写个SHELL脚本定期重启下各个实例，这样可以清除内存回收问题，这种也算是下下之策了。但是起码能保证客户方能上班时间正常使用该系统。