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

会员名
密码
自动登录   注册 忘记密码

您还没有登录 !  登录 ·页面登录 .注册 .企业注册 |搜索 ·帮助

   首页     |   论坛   Java  Ruby  AJAX  Agile   |  文集  专栏  博客  圈子   |  招聘  服务  搜索 
论坛 ->Java ->IBM WebSphere Application Server 诊断和调优(二)
全部    Hibernate    Spring    Struts    Webwork    iBATIS    企业应用    设计模式    DAO    领域模型    OO    Tomcat    SOA    JBoss    J2ME

精华:   主题:   IBM WebSphere Application Server 诊断和调优(二)
该帖已经被评为精华帖
作者 正文
zwchen
等级:

性别:
文章: 119
积分: 575
来自: 大连
圈子:大连JAVAeyer群

时间: 1 星期前    关键字:    WebSphere 内存泄漏 Java虚拟机 引用  推荐  收藏
上篇：http://www.javaeye.com/topic/74737
续写这篇文章，已经过去一个半月了。直到现在，系统一直运行平稳。
先说说我接手这项工作的经历吧：该项目大部分是06年10月就部署在客户那边了，到07年3月份，WAS宕机问题实在无法忍受，我才加入进来，前 半年有另外一位同事断断续续处理，但对问题一直都无可奈何，而且项目负责人也没有引起足够的重视。可想而知，最后付出的代价是非常惨重的。在这近半年的时 间内，服务器宕机63次。每次宕机时，WAS的JVM会dump出一个heapdump.phd文件(heap快照)，然后JVM就死掉了，当然，此时 WAS也停止了响应。一般我们的做法是重启，最后是干脆AIX每天晚上定时重启。有时候一天还死多次。大家见附件的截图（all-GC.png）。这是我 接手后，用IBM的分析工具得到的截图。对截图的分析，留给后面对应的部分吧。
服务器不稳定、宕机问题，拖延到最后，客户愤怒了，公司高层也害怕了，部门还专门成立了八人攻关组。当然了，我当时的压力也非常大，因为我是技术负责人，也就是实实在在干活、想主意的。
服务器诊断那段时间，从前到后，我们也是沿着一条线走下来，虽然最后发现很多路都走不通。现在就按这个思路，也就是时间先后一步步叙述吧。我想，大家如果也碰到类似应用服务器诊断，应该思路差不多。
术语说明：
IBM Websphere Application Server：WAS，WebSphere本身是一个平台，产品家族
OutOfMemoryError：OOM，内存泄漏，内存溢出
Gabage Collection：GC，自动垃圾回收
Content Management System：CMS，就是给新闻类门户网站编辑们用的系统
我们诊断大体上经历了以下几个阶段：
1、按Job调度线程池引起内存泄漏诊断：因为很多次OOM是发生在某个特定时候，譬如14：30、22：40左右。
2、按应用程序引起内存泄漏诊断：用JProfiler等工具探测：因为总是发生OOM。
3、分离WAS怀疑有OOM的应用：因为每个WAS应用太多，20来个，混一起没法定位。
4、用IBM官方heap、GC分析工具。以及和IBM技术支持联系。WAS、AIX参数优化。
5、隔离出WAS超级恶魔程序：一个CMS产品。
6、WAS、AIX参数优化、设置。
我们走到第5步时，才出现效果。计算一下，那时已经过去一个月了。服务器宕机、系统不稳定，在这个验收的时候，客户已经忍无可忍，以致后来的每一次行动都得胆战心惊得去做。
一、按Job调度线程池导致内存泄漏诊断
因为从我们WAS的日志(默认是native_stderr.log)来看，最近半年的宕机时间都有一个明显时间规律。见附件截图Job1-1.png。
我想，做过Java服务器性能调优的朋友，都知道在Web容器里面启线程池是个不太好的做法，因为Web容器本身有一个线程池，譬如 Servlet线程池（Tomcat默认起25个），而自启的线程池很容易导致Servlet线程管理混乱，最终导致GC问题。我们的现象似乎和那很符 合。如果我们沿着这个思路做下去，具体怎样实施呢？
我们的WAS上部署了20个左右的Web应用，譬如Lucene全文检索、B2B行业数据同步等，都是通过Quartz的Job调度做的，当然还有 很多其它调度。当时，由我负责，通知相关负责人，将定时调度暂时去掉。观察了几天，后来发现问题依然存在，不过时间有点随机了。
不过，最后还是发现OOM不是由Job调度引起的。
也就是说，我们这个方案是失败的。而且，我们的很多想法都是臆测的，没有可靠的根据，也没有方向，再加上我是第一次处理这种问题，这导致后来查找问题的艰 难。但是，仔细想想，我们又能拿什么做依据呢？出现OOM错误，我想大多数人想到的，除了JVM参数设置，就是内存泄漏。其实，OOM发生有很多种情况， 在IBM、Sun、BEA等不同虚拟机上，因为GC机制不一样，所以原因一般都不同，容易定位难度也不一样。下文会谈到。
于是，我们干脆釜底抽薪分析问题吧：用JProfiler检测。
二、按应用程序导致内存泄漏诊断，JProfiler检测
如果遇到OOM问题，我想大家都会想到内存检测工具，现在最可靠的还是下面三种分析工具：Borland 的Optimizeit Suite，Quest的JProbe，ej-technologies的JProfiler。但面临三个问题：
1、三个都是商业产品，公司暂时没有买，必须自己下载，而且要找序列号。
2、工具必须支持AIX5.3＋JDK1.42＋WAS6.0，不是Windows平台。
3、工具必须在客户真实环境下部署，对客户的业务不能有冲击，也就是说部署测试工具前，必须做个大量测试，对工具非常熟练，遇到意外可以立即恢复现场。
Note:项目上线后，而不是测试或试运行阶段遇到此类问题，非常考验人；另外一个，就是性能和可伸缩性问题，很可能把整个项目给毁了。
当我决定要这么做后，就立即动手查阅这些工具的官方文档，用emule下载，最终都下载到了。试用后，最终选择了JProfiler4.03，比起 其它工具，它界面美观、清晰、功能强大、集成度高(Heap,Memory,CPU,Thread都统一了)。另外，JProbe没有AIX版本，这也是 放弃它的一个原因。
JVM的Profiler原理，都是通过JVM内置的的标准C语言Profiler 接口收集数据，然后通过Profiler工具的客户端展现。也就是说各厂商的Profiler工具，都有两个部分，一个部分是Profiler Agent，和JVM绑定，负责收集JVM内部数据，譬如方法调用次数、耗费时间等；另外一个部分就是Profiler front-end。通过Profiler工具的自定义local或remote协议传输到front-end，其实，我们最常用的JavaIDE的 debug功能就是在此基础上的（JPDA）。（JProfiler的截图http://www.ej-technologies.com/products/jprofiler/screenshots.html ）。
下面是Sun官方文档：
JDK1.42及以前是JVM PI：http://java.sun.com/j2se/1.4.2/docs/guide/jvmpi/jvmpi.html
JDK1.5是JVM TI：http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html
具体到JProfiler的配置上，专门针对JDK1.4和1.5的JVM配置差别很大。
我用的JProfiler是4.31版本，透露给大家一个万能序列号吧(这东西不太好找)，对各版本应该都支持。深入了解Java，这类工具是不可少的：
Name: License for You
Lincese Code: A-G667#42616F-10kg1r134fq9m#2217
为了保证真实环境的检测成功，我做了大量的试验，譬如：
1、Windows系列的本地、远程测试。
2、AIX的远程测试。
3、Tomcat5.0、WebLogic8.14、WebSphere6.02，以及上述两种方式的组合测试，排列组合，场景不下10个。
当时也参阅了大量JVM文档，JProfiler官方几百页英文文档，辅助的JProbe对照。而且也制造过内存泄漏造成的OOM场景。
当然，要是在几个月前，在客户那边部署的测试环境时，就进行测试该多好啊。
在公司内部，我用JProfiler测试了我们当时部署的几个应用，没有发现内存泄漏，所以，我们最怀疑的是就是CMS系统。因为出问题的那个 WAS上它占去了90％的负荷（我们有多台AIX、WAS服务器）。该CMS超级庞大，感觉著名的赛迪网就用它，当时该CMS厂商给我们部署都花了快一个 月。所以再重新部署一套测试环境也挺困难。另外，CMS提供商不给lisence。现在测试，客户早就对我们恼火了，当然不怎么配合，这对我们工作的开展 就有很大的挑战。
在大致可以确定万无一失的情况下，我们最终决定在客户的真实环境下测试。也就是让JProfiler的agent端直接在WAS的JVM里面启动（北京IDC），然后远程（大连）监控。
本来该模式在另外几个应用的测试都通过了（因为北京IDC那边好几台AIX服务器）。但一部署上，客户的一些编辑用CMS时就感觉超级慢，尽管我 们用了JProfiler的最小负载模式。半个小时后，客户实在无法忍受，打电话过来，又把我们部长和经理训了一顿，还要写书面报告。我们被迫马山中止测 试，恢复现场。
虽然JProfiler也支持客户那边的环境，但还是有bug，至少负载一高就有严重的性能问题，几乎导致系统挂起，这是我当时没有料到的。 JProfiler一启动，WAS的启动时间就由原来的3分钟降到10分钟，而且系统响应明显变慢，我们具体的环境如下（排列组合恐怕不下20种）：
1、AIX5.3，Power PC64位（不是32位）
2、WebSphere6.0
3、IBM JVM1.42
4、Remote 模式
我后来仔细读了一下JProfiler的changeLog，发现对上面的环境支持不够也很正常，因为官方在最近的4.3.x版本下陆续有对IBM JVM和Websphere6.0的features和bug fix：http://www.ej-technologies.com/download/jprofiler/changelog.html
进行到这一步，我忽然觉得无计可施了，此时已经过了三周。
上面的策略，我认为是很正统的处理方法。谁怪我们当初项目上线时没有进行充分的测试呢？其实，这类测试没做也正常，OOM这类问题谁都无法预测。
到这个时候，我想肯定有人会问我？你知道导致JVM的OOM有几种情况吗？在当时，我想到了以下五种：
1、JVM的heap最小、最大值没有设，或不合理。
2、JVM的maxPermSize没有设置（这个IBM的JVM没有，一设置JVM就起不来）。
对于Sun和BEA的JVM，以上两种参数设置，可以排除90％以上的非程序内存溢出导致的OOM。
3、程序内存泄漏
4、有的JVM，当在80%的CPU时间内，不能GC出2%的heap时，也发生OOM（IBM的JVM就是，但我没有验证）
5、JVM本身内存泄漏（JVM有bug不是不可能）
现在的难题是，如果是那个可怕的CMS程序本身有内存溢出，在产品环境下，我们怎么去验证？我们自己开发的10来个web应用，测试并不是很难，在 公司测试都可以。但是，我现在最想解决的，就是CMS测试的问题。而且，在我们那种环境下，该CMS产品供应商并没有透露成功案例。
其实，最后发现，并不是内存泄漏造成的，因为我们的heap走势都很平稳。纳闷的是，有1000M的heap，每次在heap只被占用400来M时就发生OOM，没有任何预兆。大家猜猜，会是什么原因？这个问题我到后面相关章节再说吧。
既然我们所有的矛头都指向那个可怕的CMS系统，现在就是考虑隔离的问题。如果我们验证这个问题是CMS造成的，那么大部分责任就应该由CMS厂商承担。
既然CMS我们不敢移（费劲，而且客户在正式用），那我就移我们开发的10来个web系统吧。
三、移出除CMS系统以外的所有应用
说起来容易啊，做呢？ 隔离（移动）工作由我负责，具体涉及到10来个相关负责人。
转移工作，必须处理好很多问题，就说几个印象最深的吧：
1、某些应用，如Blog和BBS，都涉及到文件、图片上传目录和产品本身的环境，如 JDBC连接池、Cache位置。
2、目标服务器本身的环境，WAS安装环境、网络等。
3、移植时的先后顺序、调度，各应用内部本身的约束关系。
4、移植后的测试。
当然，还有一个最严峻的问题，客户允许我们这么做吗？对它们目前运行的系统有多大影响？风险如何评估？
这个工作持续了一天，已经完成了80％的工作，到第二天，客户又恼火了：WAS又宕机了。
为什么？这确实是WAS的一个bug：WAS的后台随便一操作，heap就会突然上升几百M，导致JVM内存不够。不过WAS撑住的话，过半小时 后就会降下来，我估计是WAS后台对用户操作状态、文件都缓存到Session里面。你们可以检查类似这样的一个文件夹：d:\IBM WebSphere\AppServer\profiles\AppSrv01\wstemp，我不知道为什么WAS不主动去清除它，它偷偷的就上升到几 个G，系统硬盘可能不久就后就会空间不足，WAS莫名迟缓、最后死掉。听过WAS6.0以前这个目录更夸张。大家见我附件的截图 WAS_Console.png那个尖峰。
咋办？经理也已经不敢让我们继续铤而走险了。这个方案最终又以失败告终。
不过，最后我们还是发现问题出在CMS上。我们以前把这个问题向CMS技术支持反映，有大量依据和现象，并且把相关日志都给它们。过了两天，他们最后竟然只回了一句话“从给我的两个日志来看，没有找到任何与XXX有关的东西....”。TMD！我真的很生气，它们的产品都折磨我们半年之久了。不过，看他们对IBM的WAS和JVM也不懂，我也就不想再说什么了。下面是我的邮件，公司机密部分都隐去了：
 
引用
附件是我们这段时间服务器宕机的日志。我们用IBM Pattern Modeling and Analysis Tool for Java Garbage Collector Version 1.3.2分析了一下虚拟机日志，没有发现是内存泄漏导致；用IBM HeapAnalyzer Version 1.4.4 分析heap文件，也没有发现很可疑的内存泄漏。
我想以前你们也这样做过，现在我们分析错误日志，发现有一个现象，在宕机时，总是找不到文件，我看就是Websphere或是AIX IO资源不够，不知道是什么导致的。但是，我们自己的应用，基本上没有什么IO，除了一次load几个配置文件。不过，我觉得你们WCM的IO操作挺多 的，不知道你对日志有什么新的发现。
客观的说，这几个月来，宕机那台服务器，除了你们的XXX，就以论坛和blog为主，而且他们都是开源的。在频繁宕机的06年11月份，我们的论坛和blog还没有上线。现在我们不得不每天晚上11点定时重启，但这也不是长久之计。
现在，我们进行分离遇到很大阻力，原来想把你们的XXX单独分离出来，在当前的环境下，不是很现实，如安装、测试（负载、定时服务），所以现在分离我们自己的应用，但当前在产品环境下，客户方阻力也很大。
希望尽快能够得到你们的问题建议和方案。
文中说到了IBM的两个分析工具，这也是我们后来的救星：我们就是需要这种离线分析工具，因为实时检测已经证明不现实。但我始终对该分析出来的结果抱怀疑态度，直到我去深入IBM的JVM以及和IBM的技术支持交流......
柳暗花明啊，至少看到了一点希望，不过最后我们还是失望而返。
四、用IBM的HeapAnalyzer和GarbageCollector检测
找到这两个工具，已经是够费劲了，因为以前找的IBM HeapRoot工具，让我对这类工具很失望。而且，这两个工具，只有在IBM的Techinical Support网站能够搜索到，但很不容易，因为那两个工具，并不是象IBM的Websphere产品那样宣传，它只在IBM Techinical Support文章的某些角落里出现。要知道，Techinical Support是IBM很重要的收入来源，这类文档，他们并不会让你很轻易就拿到，比起BEA WLS的支持网站dev2dev差远了。
具体诊断细节我就不详述了。我认为，IBM的WAS或JVM出了性能和OOM问题，这两个工具是最有效的，而且是离线分析工具，比起那些实时Profiler工具，某些场合有绝对的优势：譬如我们目前的产品环境，你只能分析宕机后的日志，实时分析前面已经验证是不可行的。
从日志分析，我们最终得出结论，我们购买的CMS系统有严重的碎片（大对象）问题，而该问题是OOM的罪魁祸首，而且IBM工程师也得出了同一结论。不过，在起先我们得出这一结论一周后，我还始终不相信heap碎片会导致OOM，直到IBM工程师总是向我强调。
我想很多人也是不太相信，因为大多数人用的都是Sun的JVM，譬如Windows、Solaris上的hotspot。而且，Sun JVM出问题，如果是配置的问题，一般通过配置heap最大最小值，以及maxPermSize都可以解决。Heap碎片导致的OOM，只有BEA的 JRockit和IBM JVM上发生，不过JRockit有专门文档说明，而且很容易找到（就在jdk的文档里面）。
配置heap最小最大值，我想大多数人都有经验。对于Sun的JVM来说，一般可以设置heap最大最小值一致，也是推荐的做法。因 为它的GC策略默认是复制、分代算法。也就是说，它会将heap分成不同的几个区，譬如Solaris JVM中最上面有两个大小相等的区。GC时刻，将一个区的存活对象复制到另外一个对等区，垃圾对象就算遗弃了。这样在heap里面，就不存在碎片问题。另 外，根据Java对象的存活期不同，将之转移到不同的区（Tenured区），存活最长的在最底部（火车算法），这也就是分代模型。具体请参考官方文档：http://java.sun.com/docs/hotspot/gc1.4.2/
对于maxPermSize（Permanent Generation），主要和那些加载到JVM里面的Java Class对象相关，它的空间不是在Java Heap里面分配。如果你当前的heap有1000M，permSize是200M，那么JVM至少占用1200M。
在这个空间内的对象的生存期和JVM是一样的，譬如JDK的核心类库，它们被System Classloader加载到JVM的Method Area（方法区）后，就不会被GC掉的，这些对象一般是Class对象，而不是普通的实例对象，也就是JVM的元数据。我们在用反射时经常用到它们。所 以，对于现在象Spring、Hibernate这些框架经常通过反射创建实例，可能对maxPermSize要求就大了，缺省的64M很多时候是不够 的，特别是对于应用服务器里的应用，象JSP就会产生和加载很多classes。不过，如果是它导致的OOM，一般会有类似 perm size提示。
但是，对于IBM的JVM，情况就完全不一样。它的默认GC策略并没有采取复制、分代。这个可以从GC日志分析出来。它不像Sun的JVM那样，有 个单独的方法区，它的方法区就放在Java Heap里面。JVM规范里面并没有要求方法区的必须存放的位置，因为它只是一个JVM实现问题。
在IBM的JVM里面，这些对象一般分配在称为k-cluster和p-cluster里（cluster又是属于Heap），而后者一般是临时在 heap里面申请。并且，这些cluster是不能GC，或是被移动重排的（Compact过程）。这就导致Java Heap里面就如同马蜂窝，但不同的蜂孔又不能合并，于是，当我们程序里面产生一个大对象，譬如2M的数组(数组必须分配在连续的内存区)时，就没有可分 配空间了，于是就报告OOM。这些不能被移动的cluster就称为所谓的碎片。此时，JVM的Heap利用率可能不到50%。
当然，通过一定时期的GC日志，可以计算出cluster的合理大小（专门在Java Heap的底部），另外，还可以为这些大对象专门分配大对象区的（超过64k的对象）。
通过上面的理论介绍，我想大家一定知道了为什么IBM的JVM里面不推荐heap的最大最小值相同，因为这样碎片问题会非常严重：如果我们每次大对 象申请内存时，heap都扩展5%，譬如50M，碎片问题很大程度上可以避开，程序性能也高些（寻找可用空隙和分配耗时，以及每次GC时间拉长）。
以上的具体阐述，请参考我在上文推荐的几个URL，另外再推荐三个宝贵的链接：
http://www-1.ibm.com/support/docview.wss?rs=180&context=SSEQTP&q1=fragmentation&uid=swg21176363&loc=en_US&cs=utf-8〈=en
http://www-900.ibm.com/cn/support/viewdoc/detail?DocId=2447476A10000（IBM 技术支持告诉我的，太重要了！）
http://www-900.ibm.com/cn/support/viewdoc/detail?DocId=2847476B08000
我想大家应该会问：我怎么能够肯定我的OOM问题是heap碎片造成的呢？下面的方法可以验证。
在OOM发生时，JVM会产生一个heapdump文件。然后用GarbageCollector分析出该OOM发生时刻，JVM去申请的空间， 譬如约235k。此时，你再用HeapAnalyzer去分析此时的heap快照里面的gap size大小（空隙大小）和各自的可用数目。你会发现，大于235k的空隙个数为0。这就是碎片导致OOM的证据。
另外，有人会问：我怀疑我的OOM是因为程序内存泄漏造成的，怎么去验证？
你可以用HeapAnalyzer分析发生OOM时刻的heap快照，工具会罗列出哪些对象怀疑有内存泄漏，譬如Cache对象都非常大（但你可以 确定它不是内存泄漏）。另外，分析这次宕机（从这次虚拟机启动到宕机这段时间）的heap走势，如果曲线明显是向上倾斜，也就是那种典型的内存泄漏图，就 有可能是内存泄漏。当然，还必须结合heap快照。
内存持续上升在JVM开始一段时间很正常，因为JVM对第一次访问到的Class 对象，譬如一个典型的Web应用，就有jdk的class、Spring或Hibernate的class对象，它们都会被缓存下来 (ClassLoader原理)，一般均不会被GC。当大多数class对象缓存差不多（当然还可能有一些Singleton对象，不过不怎么占分量）， JVM的Heap就平稳了，呈一水平波浪或锯齿线。
如果可以用JProfiler这类工具实时监控，就更容易确诊了。
经过一番周折，我们终于看到了一线希望了。
在一定的准备后，我们决定对WAS进行性能调优了。WAS的调优参数，可以分为两个部分：JVM级别和WAS级别：
JVM：主要是GC和Heap。
WAS：Thread Pool，JDBC DataSource。
当然要调节，你需要明白你的目标是什么，调节依据是什么，怎么计算，绝对不是凭空想象的，譬如heap最小值1024M，日志证明，该参数非常不适合我们的环境。具体细节，留给后文吧。
战战兢兢地，中午12:00，我们给产品环境下的WAS调节参数、重启，同时优化了AIX的IO相关参数。
我试着设置了一下JVM的k-cluster和p-cluster。下午15:00左右，WAS挂了，AIX也挂了。这下麻烦可大了。我们都慌了， 马山客户的老总就来电话了，一阵哗哗啦啦。实在无奈，让客户那边工作人员通知机房（服务器托管处）工作人员重启AIX。我也不得不强行更改刚才的参数，立 即设为另外一个值。
其实，我把那个两个cluster值确实设置太大了，我把它们设置为推荐值的5倍，譬如p-cluster是65k×110%×5。另外一个愚蠢的设置就是把最小heap设置为2048M(AIX有4G内存)。
后来我恢复到约正常的值，也就是去掉那个cluster的5，另外分配了一个30%的大对象区（如果1000M的heap，就是700M＋300M）。
就这样，系统持续正常运行了三天，以前可是一天一down。当在三天后再次宕机时，我们都没有自信了。不得不通过AIX的cron，继续每天深夜11点的WAS定时重启。
不过，那次宕机，包括以后的几次宕机，再也没有出现OOM错误了，但系统依然不稳定。虽然我可以说OOM问题解决了，但领导和客户需要的并不是这种结果。
其实，在这个时候，我们已经发现我们系统的四大问题：
1、WAS和JVM参数：OOM问题
2、AIX的IO和Paging Spacing不足：AIX日志后来显示错误
3、AIX的WAS分区空间不够：WAS的日志膨胀一周就把那个opt分区塞满了。
4、应用程序的JDBC连接池：我们20来个应用，一个20 connections，DB2数据库有时被撑死。
也就是说，我们最初在客户那儿部署时，用的默认值根本不行。而且，部署涉及多人，人员之间出现断层。如果我们只是按OOM，无疑是走入死胡同，必须全局考虑！
但是，项目组实力薄弱，公司范围内就没有对AIX精通的。不过项目组原来有一个搞银行系统，在AIX下开发，就他熟悉些。我当时对AIX也比较陌 生，你们从Linux转到AIX，你就知道它有多别扭了。命令都自定一套（也许因为是Unix元老吧），那个shell也超级别扭，而且参考书特少。不是 自诩，我两年前负责一个高负载的Linux服务器管理一年多，也是玩得很转的。
就这样，他负责AIX的相关问题，我负责WAS相关的。
但是，现实环境，已经不允许我们再试验下去了。我们必须找到一条绝对可靠的对策！
这就是下文的CMS系统大迁移，服务器再次优化。
文章太长（上万字），我把剩下部分发表在回复贴里面吧。
Job1-1.png
描述:
文件大小:  14 KB
看过的:  文件被下载或查看 39 次

下载
all-GC.png
描述:
文件大小:  78 KB
看过的:  文件被下载或查看 34 次

下载
HeapAnaylizer_gap.png
描述:
文件大小:  18 KB
看过的:  文件被下载或查看 19 次

下载
声明：JavaEye文章版权属于作者，受法律保护。没有作者书面许可不得转载。若作者同意转载，必须以超链接形式标明文章原始出处和作者。
相关文章：   JAVA MD5 Encrypt   filter（二） filter中的匹配规则(转)
推荐职位：   上海：高薪诚聘Lucene搜索工程师   优秀公司宏迅：招聘软件开发工程师，工作地点（上海，北京）
返回顶端  1楼   最后更新：2007-06-15 18:18       发布在大连JAVAeyer群 圈子

zwchen
等级:

性别:
文章: 119
积分: 575
来自: 大连
圈子:大连JAVAeyer群

时间: 1 星期前    评级:   (0位会员评分) 引用  推荐  收藏
继续上文，文章太长，很难发布成功。
五、隔离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开发模式），还有那么严重的大对象问题。
好了，以上总结的几点可能也不充分、深入，但如果你仔细读我这篇文章，应该有自己的想法。毕竟，只有经过思考的东西，才会属于自己。
 
WAS.PNG
描述:  WAS控制台的部分状态参数
文件大小:  20 KB
看过的:  文件被下载或查看 23 次

下载
66GC_070614.png
描述:  最近三周系统的GC曲线图。 红线是heap已经占用占用值。 黄线是整个heap大小。
文件大小:  34 KB
看过的:  文件被下载或查看 14 次

下载
WAS_Console.png
描述:
文件大小:  23 KB
看过的:  文件被下载或查看 13 次

下载
返回顶端  2楼   最后更新：2007-06-15 18:51   我来评分:  请先 登录

zwchen
等级:

性别:
文章: 119
积分: 575
来自: 大连
圈子:大连JAVAeyer群

时间: 1 星期前    评级:   (0位会员评分) 引用  推荐  收藏
也 许有人会说，我看完全文，发现你们遇到的问题还是很基础啊。现在想想，也确实如此。不过，当时确实没有方向。另外，一个人不太可能有这么全面的知识。其 实，最难的，还是那个IBM JVM的heap碎片问题，关键是你想不到，网上又很难搜到资料。大家要是用它后，出现OOM问题，一定要前车之鉴啊！
返回顶端  3楼   最后更新：2007-06-15 18:56   我来评分:  请先 登录

dennis_zane
等级:

性别:
文章: 413
积分: 728
来自: 福建
圈子:翔云社

时间: 1 星期前    评级:   (0位会员评分) 引用  推荐  收藏
非常有价值的实践经验分享，非常感谢，我们也是用websphere，这东西真是太麻烦了。
返回顶端  4楼   最后更新：2007-06-15 19:41   我来评分:  请先 登录

zwchen
等级:

性别:
文章: 119
积分: 575
来自: 大连
圈子:大连JAVAeyer群

时间: 3 天前    评级:   (0位会员评分) 引用  推荐  收藏
 
dennis_zane 写道
非常有价值的实践经验分享，非常感谢，我们也是用websphere，这东西真是太麻烦了。
这篇文章只适合以后遇到这类WAS问题时做参考，现在也不建议大家花几个小时读，留意一下就行了，上面两个帖子里面的链接非常有价值。
总之就是希望像我一样的朋友，少走点弯路。
上面几位朋友的回复只是留个标记（譬如“非常感谢。”），虽然是对我工作的肯定，但小心别人把你们评论打成隐藏哦，还是很感谢你们！
返回顶端  5楼   最后更新：2007-06-17 11:10   我来评分:  请先 登录

kevinming
等级: 初级会员

文章: 14
积分: 58

时间: 1 天前    评级:   (0位会员评分) 引用  推荐  收藏
文章真好呀
我们公司也是大多数用websphere的
文章给了我一个很好的引子,有启蒙的作用,谢谢你的共享了
返回顶端  6楼   最后更新：2007-06-17 23:13   我来评分:  请先 登录

kingofs
等级: 新手上路

性别:
文章: 1
积分: 0
来自: 成都

时间: 20 小时前    评级:   (0位会员评分) 引用  推荐  收藏
非常不错的文章，希望楼主能多介绍一下WAS的资源
返回顶端  7楼   最后更新：2007-06-18 17:20   我来评分:  请先 登录

neolf
等级: 初级会员

性别:
文章: 2
积分: 0
来自: 武汉

时间: 17 小时前    评级:   (0位会员评分) 引用  推荐  收藏
谢谢～很少看到这么详细的介绍～
websphere确实很让人头痛:)
返回顶端  8楼   最后更新：2007-06-18 20:15   我来评分:  请先 登录

newold
等级:

文章: 3
积分: 104

时间: 15 小时前    评级:   (0位会员评分) 引用  推荐  收藏
我感觉WAS调优没那么难吧,你们应该在测试系统上做下压力测试,不应该在生产系统上这么折腾.解决这种问题,首先考虑把WAS升级到最新版,然后再考虑是不是程序问题.如果WAS是正版的,IBM应该会帮你们分析日志的,我觉得你解决问题的方式不大对，把事情搞复杂了
返回顶端  9楼   最后更新：2007-06-18 22:30   我来评分:  请先 登录

111111
等级: 初级会员

文章: 4
积分: 4
圈子:EC Side

时间: 14 小时前    评级:   (0位会员评分) 引用  推荐  收藏
我 们的AS不是用的websphere,是用的oracle AS,我们的系统现在也处在性能调优的阶段.出现的问题大致和楼主的相同:客户操作一会我们的系统,系统就会先出现OOM,然后Oracle AS就会重启web实例.我们项目组的人最近都很郁闷.经理让我安装个jprofiler进行监控一下,看看是否是程序本身的原因.我从上周二开始在我们 的开发机上监控一直到今天,也没有发现问题的根源.哎,很无奈.经理又让我把jprofiler移植到IBM AIX小型生产机上进行监控,目前正在进行中...
看了楼主的帖子,我想我是否也应该查一下系统配置啊?不要光找程序的错.呵呵.此帖对我很有启发.明天就开始转移目标,查找JVM和oracle AS的配置问题.thank you,楼主.
注:我们系统运行在三个环境下面:AIX,windows 2003,惠普机。查找问题的时候就有点郁闷类。。。。
楼主，加我MSN：haoxiangni1986@hotmail.com 。咱们聊聊。。。验证：javaeye
返回顶端  10楼   最后更新：2007-06-18 23:11   我来评分:  请先 登录


论坛 ->Java -> IBM WebSphere Application Server 诊断和调优(二)
跳转论坛:   Java Ruby AJAX 软件开发和项目管理 综合技术 招聘求职 海阔天空 入门讨论 行业解决方案 博客论坛 圈子论坛 Microsoft .Net
JavaEye推荐
北京 | 上海 | 杭州 | 深圳 | 成都 | 西安 － Dev2Dev TechDays
上海：高薪诚聘Lucene搜索工程师
优秀公司宏迅：招聘软件开发工程师，工作地点（上海，北京）
快速回复         引用上一条消息 (Alt+s)   提交

广告服务   |  JavaEye黑板报   |  网站地图   |  关于我们   |  服务条款  |  联系我们  |  友情链接
© 2003-2007 JavaEye.com.   All rights reserved.上海炯耐计算机软件有限公司[沪ICP备05023328号 ]