五、隔离CMS系统，服务器优化
    从前面的介绍，大家应该记得，我们开始是固定CMS，分离其它应用，但遭遇失败。现在是反过来，干脆把CMS系统赶出WAS平台 。

说实话，项目经理做这个决定，我认为已经是鼓出很大勇气了 。

    当时我们想在一个备用AIX机上安装CMS产品测试，但最后还是没有做成：
CMS这类文章发布系统很难安装，也不好测试，又没有liscence，而且还有一堆准备工作。绝对没有著名的openCMS安装那么简单，当然功能远远比它复杂。而且，我们当时也低估了后来的工作，总觉得问题好解决。

    在很遥远的06年中期，CMS厂商在客户那边一台AIX的Tomcat上部署了一套CMS产品。但当时客户执意要求将其跑在WAS上，也就是现在的情况。最开始，客户还要求我们必须用WAS的集群(我们买的就是WAS的ND版)，无奈该CMS不支持。要是集群，又是死伤一遍。其实，现在想想，我们当时太被动，CMS这种东西，就供公司的几十个编辑用，一个普通Tomcat就完全够用。而且，把它和面向公网的Internet应用混在一起，完全没有必要。也许，被动是因为我的实力造成的。

我们决定背水一战时，已经做过周密的计划：某年某月某日晚上8:00......
CMS产品负责人现场切换
xx（我）负责WAS相关参数调整
yy负责AIX参数。
zz负责应用的测试
…..

总之，该行动涉及到客户方、产品提供商、公司高层、项目组。每个人都密切关注，不下20人。每个人都守在电脑前，随时听候调遣，当天晚上，我们都没有准备回家睡觉，大家齐心协力。

真没想到，整个式切换工作，一个小时就顺利完成 ！第二天，客户编辑打开浏览器，她们一定想不到昨晚大家准备经历一场厮杀….

系统持续平稳地运行了一周，然后是漫长的五一，我回湖北黄冈老家休息了八天。回来时，一切依旧。

当天晚上，我们这边主要做了两项工作：
1、JVM的Heap参数，共五个。
2、AIX的IO、Paging Space等共六个。
当然还有其他人的工作，譬如测试、监控。

    还有一个非常重要的方面：JDBC连接池。我们原来是在每个Web应用里面独立设置，这样20来个应用就有几百个DB连接，一不小心DB就给撑死。现在统一交由WAS内置DataSource处理，总共连接不到30个。其实，我们项目开始部署时，就是这样做的，但当时WAS内置的DataSource对JTA(XA)支持有bug （这个和IBM技术支持确认过，但他们没有给予很好的解决方案），不过Datasource还是配好的。

    但是这个工作已经属于WAS性能优化的主题了，而且优化值必须持续观察一段时间，通过专门的分析工具来计算。
优化本身，是一项很考验人的工作，我就简单说一下最实用方法吧，也许是专门针对IBM的产品。
1、清理归零WAS日志。然后启动WAS，生成日志（-verbose:gc默认是开的）
2、让WAS持续运行约两周，让JVM Heap占用曲线平稳一段时间即可（用IBM的Garbage Collector分析观察）。
3、在AIX的shell里，产生heapdump.phd文件，也就是heap快照。命令：kill -3 pid (pid是WAS的PID，通过ps –ef查看)，观察heap当时的碎片情况，是否需要单独分大对象区（一般不需要设置），特别是那个方法区Class对象大小（p-cluster参数）。
4、通过GC工具，观察GC平均时间、Heap实际占用情况。Note: GC是一个Stop The World过程，也就是说GC时系统对外不响应，多CPU也不例外。看你的应用实际需求了，GC持续时间和频率是矛盾的，另外还有性能考虑。一般Web应用，我想让GC持续时间（Pause time）调节到合理值就ok了，譬如0.2到0.4s。
5、根据3可以算出k-cluster值，它是工具推荐值的110%。
6、Heap的最小值是程序刚启动不久的占用值，譬如320M。切记：IBM JVM初始值太大非常不好。
7、Heap的最大值是系统平稳后的100/70。也就是说如果最大值是1000M，那么应该平稳时是700M，还有30%的空余。IBM的JVM默认情下的碎片问题，WAS控制台下操作Heap猛增这种bug，你不得不堤防。Heap最大值不设，AIX下的WAS肯定OOM。

当然啦，我没有考虑到大对象区的计算（虽然我们的应用设置了专门的大对象区），包括IBM JVM支持的分代GC、并行GC，Heap每次expand百分比等。那些情况我们一般不常用，譬如，你的AIX平台一般不是16CPU吧？

一口气写到现在，我忽然觉得该收尾了。下面就说说我对这类工作的整体看法吧。
1、尽量在项目测试和试运行的时候就进行压力、性能测试，当正式投入使用后，如果发现类似问题，代价非常大。躲过算你运气好，一般来说，可能你们系统没多少人用，也不是核心业务系统，譬如一般的电子政务。
2、千万不要低估了技术风险，用IBM的系列产品尤其要慎重，出问题一定不要忘了技术支持。而且，查资料时，建议用google English，因为象WebSphere这类问题，很少有中文资料。
3、程序部署环境建立时，就要考虑到日后的正式环境，譬如AIX的Paging Space、IO、分区大小，默认值往往是不行的，而且在产品环境下改这些值，往往非常难。
4、在项目开发初期，就考虑到日志的问题，因为它分散到每个方法内，必须慎重定义好debug、info、warn、error级别，不要随便忽视异常（catch里面不记录），到真正程序出问题时，它就是我们的最重要的依据之一。当然这主要是功能性问题诊断。另外对于高负载网站，日志文件往往非常大，各级别日志千万不要混在一起，否则找问题就很困难了。
5、怎么说呢，别死扣技术，以为什么都可以通过技术解决。你看我们最大的问题就是把CMS给移到Tomcat下。你要是问我，为什么CMS产品会导致系统这么多的问题，我也不知道，到那时候，我确实也不想深入。我只要知道，赶出你这个应用，我的系统就好控制多了。而且，那个CMS系统，在Tomcat下，就是跑得服服帖帖的，非常稳定。难度是可恶的WAS？不过那CMS，据IBM工程师，包括我们二次开发，都觉得够烂了，每个jsp页面都打开、关闭DB connection（7年前的jsp开发模式），还有那么严重的大对象问题。

    好了，以上总结的几点可能也不充分、深入，但如果你仔细读我这篇文章，应该有自己的想法。毕竟，只有经过思考的东西，才会属于自己。