IBM WebSphere Application Server 诊断和调优(二)

请留意我文中说到的几种OOM发生场景，如果是单纯的OOM，应该解决不难，但请注意你们具体用的JVM的厂商和版本，因为每个JVM的默认GC策略不一样，差别很大，千万不要以为都是Sun的JVM那样实现。

不知道你留意否：我们系统最大的问题可能不是OOM，而是IO和存储系统（分页空间、磁盘分区）。当然，WAS的难用（总以为自己是老大）也是一个非常重要的原因。

另外说一下：JProfiler这种类似工具对服务器端应用，特别是那种AIX平台或是HP平台，不会象检测Windows下的Tomcat那样易用。所以不要抱太大系统。
你们的OOM，我建议先从JVM参数设置找起，譬如IBM的JVM的heap默认值在不同的OS上是下面这样的：见附件截图。

看完全文，颇有感触。你把整个过程写下来，让我学习到了一些思路上的东西，非常感谢！

上线前没做压力测试？近半年的时间内，服务器宕机63次。你们胆子也真大，客户的脾气不错哦。

1.上线了就没有测试系统，那你们怎么做维护呀?有时候并不一定是CMS的问题,可能和你们的某个LIB冲突了,特别用开源的东西，很容易碰到这样的问题.
2.从6.0.2到6.0.2.5好象有JDK的更新,应该尝试下更新JDK的,会解决很多问题的,听下IBM中的专家的意见还是很好的;
3.你们用户使用WAS难道不买服务吗，就丢给你们解决呀;买IBM这一套就是为关键应用准备的,花了那么多钱就是把30几个乱七八糟的应用发在一起.而且你们很多应用都是后台运行的，为什么都要放在WAS里运行呀,一定需要应用服务器的环境吗，直接用JDK就可以跑了吧

上面说的都很有道理的，不过不要责怪我哦，我当时是开发人员，还不是leader，没有决策权。再说，那宕机的几个月，我有其它很紧的项目。
我们公司这么大，没有若干年的资历，是很难当leader或PM的。

1、我们大多数项目确实没有写什么专门的单元测试（虽然我自己的模块我都写了，但没法要求别人），你交上可用的东西就ok了，leader可不管你是怎么做出来的。不过项目上线前有功能测试（IBM的Funtion Tester），有专门的测试组。但当时也没有做性能测试。但最后我专门用LoadRunner7.8测过部分，经常把DB给崩了。
那个CMS产品就没测了，你说你们在采用用友的ERP财务软件，你会测试吗？你说的和某个Lib冲突，这个应该不太可能，反正日志没有那类错误。

2、JDK更新我们没有做，“权威性”的东西，我们还是动手少，IBM技术支持也建议先不要这方面想。现在想想，在企业应用领域，什么IBM、行业top one，千万别被人忽悠。

3、用WAS，当然买服务了，但当我接手时，一年服务已经到期了，不过后来突然借用到别人的license，所以我才向IBM咨询。不过，对IBM的咨询，也别太指望了。我们原来咨询它们一个WAS里面配置XA数据源时，他们技术员一个月也没有给我们搞定（WAS的XA数据源确实有bug，他们也承认），最后我们放弃用了WAS的分布式事务，用Spring下的JOTM。不过后来解决OOM问题的那位技术支持不错，就是态度不太友好，他希望他的每句话你都一听就明白。
你说的乱七八糟的应用都放在WAS里，少数几个是这样。最后我们把那些作业调度的应用都单独移出来了。

可笑的是，我们把WAS当成Tomcat用，根本没有用到WAS的任何优势，劣势占尽了。有啥办法？项目当初投标，那么多单位竞标，你会不迎合客户吗？即使他们也什么都不懂。他说啥好你都得听着，另外几家投标单位也都这样，方案差不多。这把我们后来都害惨了，不过也确实长见识了，什么OA、CMS、e-Business、IM、CRM、BI、GIS....统统玩过，用得咋样，我就不说了。

所以，从这篇文章，大家未必学到多少WAS方面的知识，但一定能够领会到一点：干软件这行，不踏踏实实，最终你还是会为自己的行为买单的。

也许有人会想，我当时花高价聘请一个part time的WAS、AIX高手，或者一开始问题交给厂商解决不就OK了吗？你等着吧：前者，你找不到这样的人。后者，各厂家都会推脱。
买软件产品，不像买台空调那样简单，不制冷，肯定是你的空调的问题，换吧。软件这东西，譬如哪个CMS混在WAS里面，两个厂商就是相互推脱。

客户脾气，嘿嘿。
不过他们也就认了，换乙方，可能吗？
再说，他们也应该为自己的不成熟和固执付出代价，我就是觉得我们根本用不着WAS，还有......

如果甲方信得过乙方，既然把整个软件从需求开始，都外包了，就应该给乙方充分的自主权（除了业务改造）。

让我想一句话，“出来混，迟早要还的”

另外，从这个案可以看出中国的软件行业是多么的混乱，相信这样的情况不止在你们一家公司出像。在中国这样的现像多了去了。

个人觉得，你们走了太多的弯路。
首先出现OOM问题时，就应该先打开JVM配置中的GC选项，立刻可以判断出有大对象的问题。
当你们有IBM的服务时，可以通过800要到特殊的工具（可能不是所有800的都知道），通过这样的工具，可以判断出造成大对象的是哪个应用的类，这样的话，最多3天时间，就可以排查出来了。
至于数据库连接，和存储的问题，纯属客户的网络规划出现问题。

PS，如果我没有理解错误，WAS服务器上所有应用共用一个datasource，用来减少数据库的连接。这样的方法不可取。还是建议每个应用使用自己的datasource，虽然配置麻烦，但是相对隔离还是比较好的。
另外，JDK的升级，最好还是先考虑考虑。特别对于64位操作系统上，安装64位JDK，对于内存分配会好很多。

1、JVM的GC选择默认就是打开的。

2、判断是否有大对象必须有相关工具，而我们很长一段时间都没有找到这类工具。
从低级的GC日志是不可能的，大对象必须通过Heapdump和GC日志对比才能发现（我文中说到原理）。
而且，我们第一次接触IBM的JVM，根本没有想到大对象的问题，即使最后分析出来了，也开始不敢相信。
IBM那个技术支持，是后来要别的项目组的license才去寻求帮助的（我文中也提到）。

3、数据库连接不算网络的问题，是DB2服务器优化和程序优化的问题。

我们的诊断确实走了很多很多弯路，但开始的现象太迷惑人，所以失去了方向。如果我以前做个这类似的工作，我想这次肯定不会花这么多时间。