【IT168 专稿】

    本文是WebSphere软件技术征文大赛（http://tech.it168.com/focus/200904/webspheregame/index.html）一等奖获奖作品。

    菜鸟+噩梦

    谈起WebSphere，我确实有段噩梦与之相随！

    初识WebSphere是在2006年6月，我作为项目组的技术人员参与，某电信运营商的营帐集中系统研发，并负责整个环境的搭建和调优。从项目初期搭建环境就是WebSphere的Web Application Server，同时使用了F5进行16台机器的负载均衡，请各位读者注意细节：我们使用的是Web Application Server（WAS），因为我和我的研发团队的噩梦也是从此开始的！

    项目经过半年左右的研发、测试、压力测试、割接实施等系列的过程，我们终于在2007年初的某个周五夜间上线了，系统运行第一天平稳；第二天平稳；第三天，我的噩梦开始了：

    16台Web服务器里的10台相继hang住了，其中有3台出现了core文件和dmp文件我们是个7*24小时的运营系统，所以我的第一反应就是重启WebSphere的WAS服务，保证对外服务的正常运行，重启后服务可以正常运行！

    第四天，12台服务器无法使用；第五天，8台；第六天......，我们的噩梦持续了一周。期间我们对所有的core文件进行分析，但是触发错误的都不是一个程序和功能，而最终的日志都是告诉我们结果是一样的Out Of Memory ，也就是说压倒骆驼的最后一根稻草不一定是哪一颗！

    从项目上线的第三天开始，我有半个月左右的时间，每天都有一个雷打不变的工作就是接到我们维护工程师的电话后去重启WAS的服务，有时是白天，有时甚至是半夜、凌晨。

    无奈之下，我在16台服务器上布置了监控的shell，尝试去登陆页面，超过我的最低限额时间了就重启，无奈之下想出来的临时的方案持续了3个月之久。07年4月开始，项目研发工作和数据库的设计改造工作结束（我是DBA，所以侧重数据库多一点），我开始疯狂的寻找WAS方面的资料，仔细研究我们配置的WAS参数是否存在问题，同时对系统进行改造。

    基于当时Web服务器（HPDL380 4C/8G、Linux AS4.6），通过多次试验评估，最终我的解决办法如下：

    Java虚拟机的配置修改：

    1.禁用详细类

    2.启动垃圾回收

    3.禁用详细的ini

    4.配置初始堆大小=最大堆大小=1.2G

    线程池和数据连接池的配置修改：

    我抛弃了以前IBM专家建议的漏斗形配置，因为我们的系统相对比较独立，单个server对应单个的数据连接池，漏斗会造成瓶颈，产生不必要的资源浪费，我的配置方式是  线程池=连接池。

    单节点开多个AppServer:

    我要在每台服务器上创建3个appserver，方案开始推的过程，受到了我们项目组人维护人员强烈反对，因为系统不是一成不变的，是要升级的，而我们的集群是通过硬件的方式实现的，升级的过程目前有16个节点了， 16*3对于他们来说压力着实很大，再次我也深表歉意，但是非常感谢，我坑害弟兄方案最终还是实施了！

    5月份我解决办法上线，尽管用LoadRunner无数次的压力测试，最终的结果证明了我的方案是无效的。我只是减少了Web服务hang住的频率，但是平均每天都会有5-10个WAS重启。这里不是故意要提及LoadRunner，我知道可能是我用的方法不当，但是我确实比较恨我在调试过程中使用的所有的工具，我当时差点砸了自己的笔记本！

    因为我的噩梦还在延续......