WebSphere Application Server诊断和调优
(最近才发现原文在javaeye: http://www.iteye.com/topic/74737)
近段时间,我们项目中用到的WebSphere应用服务器(WAS),但在客户的production环境下极不稳定,经常宕机。给客户造成非常不好的影响,同时,也给项目组很大压力。为此,我们花了近一个月时间对其诊断,现在基本上稳定了,需要继续观察一段时间。现在我主要将工作做一个阶段性的总结。
我们的产品环境是:WAS6.0+DB2 8.1+AIX5.3+RS/6000。在该产品环境下,出现的问题非常多,现象如下:
WAS经常不稳定、宕机几乎一天一次,经常报告OutOfMemory(内存泄漏吗?NO)。
DB2连接数过大,有时把DB2撑死,有时也把AIX撑死。
AIX虚拟内存报错、分页报错、IO也报错、还有很多其它莫名奇妙的错。
总是,每次问题发生的现象和理论上的总是不一致,导致我们不知道从何入手,也无从检测自己的优化参数。咨询过多次IBM技术支持,只解决了某些局部问题。
虽然问题依然存在,但我想,解决问题的思路、特别是理论基础,还是有一些规律和原则。
对于WAS这块,我近段时间的主要时间集中在以下几个方面(时间顺序):
1、Java性能监测工具:Jprofiler,也用到Jprobe。后来发现Jprofiler在AIX下几乎不可用。
2、IBM Java虚拟机和WAS技术细节,特别是IBM JVM的GC原理,我发现它和sun、bea的差别很大。
3、IBM的heap分析器Heap Analyzer、GCCollector。这两个事后监测工具非常实用,特别是我们的产品运行环境,非测试环境。
4、某些Application的怀疑和诊断。
5、AIX诊断,我几乎没有这个能力,只能常规监测一下,需另请高人。
我打算将本文分成以下几个部分总结:
JVM原理、IBM JVM的GC策略和调优。
Jprofiler和IBM工具的实际体会
WAS的诊断体会和AIX调优
下面开始主题吧,可能比较零碎,另外,开始的理论篇基本上看书都可以,我只是总结一下,再添加一些自己的理解。
以下是我参考的最重要的两本电子书和一些网站:
《Inside Java Vrtual Machine》:半部分有约四章我认为非常棒,其它章节可能意义不大。
《The Java Virtual Machine Specification, 2nd》:前半部分有两三章很不错,不过可以对照上一本书看。
sun的hotspot虚拟机技术:http://java.sun.com/javase/technologies/hotspot/
BEA的JRockit虚拟机技术:http://edocs.bea.com/jrockit/geninfo/genintro/index.html JVM技术文档入口,虚拟机理论,内存泄漏诊断等的索引页。
IBM诊断资料:http://www-128.ibm.com/developerworks/java/jdk/diagnosis/ 上面有一个500多页的pdf文档,对IBM JVM技术和诊断讲解很深入。
我不得不提的是,在查资料这块,BEA和Sun都有很好的官方文档和论坛支持,并且官方文档导航非常好。虽然IBM的诊断资料也不少,但需要搜索,其搜索是很痛苦的。而且,IBM官方论坛很差。如果用IBM的产品出问题,切记:找IBM技术支持,千万不要蒙着头搞!反正它们的产品很少免费。说实话,它们的技术支持还是挺负责的,一般会为你推荐很多support资料,而该资料往往都在developerworks网站上,属于support那个频道,但你就是搜不着。
Java虚拟机规范概要
研究Java虚拟机,首先要了解Sun的Java虚拟机规范。现在,该实现版本很多,如比较有名的Sun、IBM、BEA、Apple、HP、MS、Apache Harmony。它们都实现了JVM规范,但有各自扩展。譬如,针对IBM虚拟机的堆碎片导致OutOfMemory(OOM),在Sun的虚拟机上就不会发生。Sun的JVM有maxPermSize的概念,IBM就没有,如果你设置这个参数,虚拟机根本就启动不了。
比较有意思的是,学Java,就一定要了解各种规范,这和MS的风格很不一样。Sun总是在定义一些规范,实现都留给各厂商。我们除了理解规范本身外,一定要理解规范和实现之间的关系,譬如JDBC规范和JDBC驱动的关系,它们是怎么组合到一起的。要是你用过php的xml解析库,或db函数,就会体会深刻,它们可没有什么规范可言,所以每个数据库厂商的db函数用法都不一样。我推荐大家研读一下HSQLDB的jdbc和Tomcat的servlet相关实现,因为我认为它们还是比较好懂的。
JVM规范只是定义一个虚拟机该做什么,但它并没有要求你该怎么做。例如我们最常见的Servlet规范,在该规范中,有HttpServletRequest、HttpServletResponse,HttpSession等接口,但它们的实现都留给了各个容器厂商。遗憾的是,规范留下的空白,会把我们这些开发人员给整惨了:容器间移植有时候就是恶梦。譬如J2EE并没有SSO规范,但它很重要,我以前专门针对它做过WebSphere AppServer和Weblogic AppServer的SSO项目,差别还是不小,不过还是有点共通,那就是都遵循JAAS规范。
JVM的结构
从功能上分,Java虚拟机主要由六个部分组成,可以分成三类:
第一类:JVM API:就是我们最常用的Java API,它是开发人员和Java交互的入口,它主要是JAVA_HOME/jre/lib下的运行时类库rt.jar和编译相关的tools.jar
第二类:JVM内部组件
类装载器(ClassLoader):将Byte Array的 .class文件装载、链接和初始化。
内存管理(Memory Managent):为对象分配内存,以及释放内存。后者就是垃圾回收Garbage Collector(GC)。由于JVM最复杂的、最影响性能的就是GC,所以内存管理一般就指垃圾回收。
诊断接口(Diagostics Interface):这主要体现在JVMTI(jdk1.4下的JVMPI和JVMDI),它主要用来诊断程序的问题和性能,一般提供给工具厂商实现。如eclispe IDE下的debug功能,Jprofiler性能调优工具。
类解释器(Interpreter):解释装载进虚拟机的class对象,包括JIT等特性相关。
第三类:平台相关接口(Platform Interface):主要为了跨操作系统平台重用JVM代码,不过,它和我们开发人员关系不大。
在以上六个组件中,我们开发人员最关心的是ClassLoader和GC,用Java做系统框架、容器和它们密切相关。做业务系统时一些基础代码也和它们打交道,譬如最常用的Class.forName(),Thread.currentThread.getContextClassLoader()。我们仔细想想,为什么是上面两个问题?因为,它和我们class的整个生命周期最为相关:怎么将一个class和相关class加载进来,class实例什么时候创建,什么时候被销毁?
所以,下面的部分我们要专门讨论这些问题。
ClassLoader
JVM主要有三类ClassLoader:Bootstrap、Extention、Application,该三类ClassLoader从上到下是分级(hierarchy)结构,遵循代理模型(Delegation Model)。
Tip:大家可以看看sun.misc.Launcher的源码,Bootstrap和Extention就在该文件里。该src可以在sun的网站上下载该压缩包,约60M(jdk-1_5_0-src-scsl.zip),它不在jdk自带的那个src.zip里。
Bootstrap ClassLoader:也称为primordial(root) class loader。主要是负责装载jre/lib下的jar文件,当然,你也可以通过-Xbootclasspath参数定义。该ClassLoader不能被Java代码实例化,因为它是JVM本身的一部分。
Extention ClassLoader:该ClassLoader是Bootstrap classLoader的子class loader。它主要负责加载jre/lib/ext/下的所有jar文件。只要jar包放置这个位置,就会被虚拟机加载。一个常见的、类似的问题是,你将mysql的低版本驱动不小心放置在这儿,但你的Web应用程序的lib下有一个新的jdbc驱动,但怎么都报错,譬如不支持JDBC2.0的DataSource,这时你就要当心你的新jdbc可能并没有被加载。这就是ClassLoader的delegate现象。常见的有log4j、common-log、dbcp会出现问题,因为它们很容易被人塞到这个ext目录,或是Tomcat下的common/lib目录。
Application ClassLoader:也称为System ClassLoaer。它负责加载CLASSPATH环境变量下的classes。缺省情况下,它是用户创建的任何ClassLoader的父ClassLoader,我们创建的standalone应用的main class缺省情况下也是由它加载(通过Thread.currentThread().getContextClassLoader()查看)。
我们实际开发中,用ClassLoader更多时候是用其加载classpath下的资源,特别是配置文件,如ClassLoader.getResource(),比FileInputStream直接。
ClassLoader是一种分级(hierarchy)的代理(delegation)模型。
Delegation:其实是Parent Delegation,当需要加载一个class时,当前线程的ClassLoader首先会将请求代理到其父classLoader,递归向上,如果该class已经被父classLoader加载,那么直接拿来用,譬如典型的ArrayList,它最终由Bootstrap ClassLoader加载。并且,每个ClassLoader只有一个父ClassLoader。
Class查找的位置和顺序依次是:Cache、parent、self。
Hierarchy:上面的delegation已经暗示了一种分级结构,同时它也说明:一个ClassLoader只能看到被它自己加载的classes,或是看到其父(parent) ClassLoader或祖先(ancestor) ClassLoader加载的Classes。
在一个单虚拟机环境下,标识一个类有两个因素:class的全路径名、该类的ClassLoader。
我碰到的一个典型的例子是:在做WAS的SSO开发时,由于我们的类是由WAS在启动时加载,该ClassLoader比下面的部署的Applicaton的ClassLoader的级别高。所以,在我们自己的类中没法用到应用程序的连接池,必须自建。
代理模型是Java安全模型的保证。譬如,我们自己写一个String.java,并且编译、package到自己的java.lang包下。按照代理模型,当前线程的ClassLoader会将其代理到父ClassLoader,父ClassLoader(最终会是Bootstrap)会找到rt.jar下的String.class,也就是说我们的String.class不会捣乱。
自定义ClassLoader
我们前面说过,自定义ClassLoader的缺省父ClassLoader是Application ClassLoader。一般的应用开发用不到它,但我们最好理解。因为在内存泄漏查找、应用程序部署出问题时,很多都和它有关。
譬如,内存泄漏是怎么产生的?这就涉及到ClassLoader和Class的生命周期。我曾经碰到这样一个问题:我们的程序用到了Webwork和Spring框架,当部署到Tomcat下时没有任何问题,但部署到WAS下,报告找不到Webwork的xml的DTD文件,而且Spring的日志也总是失效。Why?因为解析xml dtd时,用的是IBM的Xerces,不是我们的。而Spring日志问题是因为应用程序用的是WAS的Common-log.jar,而不是我们的。将应用的ClassLoader从默认的Parent-First,改成Parent-Last就可以解决,不过我们项目中用到其它库,又发生了其它问题。
一般来说,用到自定义ClassLoader有三种情况:
1、应用框架可以自己控制Classes的目录,并且自动部署。
我读过Jive公司的Wildfire(著名的即时通讯服务器),它自己有一套应用框架,非常灵活,遵循该框架插件规范的的第三方的plug-in放置在指定目录可以自动部署,实现某些扩展功能,如文件传输、语音聊天。
2、区分用户代码
这被广泛应用在Servlet容器和类似容器,譬如EJB Container设计中,大家看到Tomcat下有common、server、share三个目录吧(ClassLoader顺序从左到有),另外也有用户应用的WEB-INF目录,它是我们自己开发的。
3、允许Classes卸载
如果没有自定义的ClassLoader,那么我们自己应用中的classes永远都不能被卸载,因为这些类被Application ClassLoader加载后cache起来了,我们的classes一直对该ClassLoader有引用,而该系统级的ClassLoader永远都不会被卸载,除非JVM shutdown了。JSP和Servlet的动态部署就用到这个特性。
Note: 还有JVM运行时(Runtime)架构,ClassLoader加载class过程没有总结,这两部分我觉得太重要了,但内容太多,写不完啊。
这部分内容,《Inside Java Virtual Machine》讲解非常清楚,BEA的官方网站这部分也非常不错,要理解深刻,我建议结合JProfiler工具,非常直观。
续写这篇文章,已经过去一个半月了。直到现在,系统一直运行平稳。
先说说我接手这项工作的经历吧:该项目大部分是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 红皮书 WAS WebSphere Application Server Liberty Profile Guide for Developers》是针对开发者的一份详细指南,旨在帮助他们理解并有效地使用WebSphere Application Server (WAS) 的Liberty Profile。...
**WA361-IBM WebSphere Application Server V6.1 Administration** 课程是一个全面深入的培训计划,旨在为学员提供必要的知识和技能,以成功管理和维护WebSphere Application Server V6.1环境。通过系统的学习和实践...
总的来说,WebSphere Application Server v6.1的系统管理涵盖了广泛的知识点,包括安装配置、安全管理、数据源管理、集群配置、监控诊断和维护优化。熟悉这些内容将帮助管理员确保企业级应用服务的高效、安全和稳定...
《WebSphere Application Server V7 管理与配置指南》是IBM公司为WebSphere Application Server V7用户提供的专业管理与配置手册,旨在帮助系统...专业人员全面掌握和有效利用WebSphere Application Server V7的各项功能...
正确配置相关参数 –日志文件。确保产品发生问题时相应的日志文件不会被覆盖。 –转储文件。确保发生问题时生成完整的专储文件。 日常数据收集 –WAS –操作系统 ...Must Gather 和IBM Support Assistant)
同时,了解Websphere Application Server的内存配置和调优策略也是必不可少的。在实际操作中,可能还需要结合其他工具,如JVisualVM或MAT (Memory Analyzer Tool),进行综合分析。 总的来说,Websphere Application...
综上所述,《IBM WebSphere Application Server 8.0 Administration Guide》是一本全面介绍WebSphere Application Server 8.0管理和维护的专业书籍,涵盖了从基础概念到高级技术的所有方面。无论是初学者还是经验...
IBM WebSphere Application Server(WAS...通过《IBM WebSphere Application Server实用大全》,开发者和管理员能够全面掌握WAS的使用和管理,从而在企业环境中有效地部署和维护Java应用程序,提升系统的稳定性和效率。
《WebSphere Application Server V6可扩展性和性能手册》是一本深度探讨IBM的WebSphere Application Server V6在大规模应用环境下的性能优化与可扩展性构建的专业书籍。这本书旨在帮助IT专业人员理解和解决在企业级...
WebSphere Application Server(WAS)6版本提供了丰富的调优工具和技术,帮助管理员优化应用服务器性能,确保应用程序高效运行。该版本引入了多项改进,旨在简化性能调优过程,并提升系统整体响应速度。 1. **调优...
IBM WebSphere Application Server (WAS) 是一个基于 Java 的应用程序服务器平台,旨在提供一个健壮且灵活的环境来部署和运行 Java 应用程序。WAS 实现了 Java 2 Enterprise Edition (J2EE) 规范,并在此基础上提供...
在System p和AIX上运行IBM WebSphere应用服务器:优化与最佳实践》是一本由IBM国际技术支持组织出版的专业书籍,主要聚焦于如何在IBM的System p平台上,利用AIX操作系统来高效、稳定地运行WebSphere Application ...
综上所述,WebSphere Application Server Performance Tuning Toolkit(PTT)是一款非常实用且功能强大的工具,旨在帮助开发者和运维人员更有效地监控、管理和优化WebSphere应用服务器的性能。通过利用其丰富的功能...
综上所述,IBM WebSphere Application Server 中的 JVM 性能调优与诊断是一项复杂但至关重要的任务。通过对 JVM 的深入了解以及合理运用调优技巧和诊断工具,可以显著提升应用程序的性能和稳定性。这对于任何使用 ...
在Websphere的数据源属性中,通过“WebSphere Application Server数据源属性”链接,可以配置高速语句缓存,优化SQL执行性能。 #### 七、事务日志调整 事务日志的合理配置对事务处理性能至关重要。在Websphere...
1. **访问管理界面**:在“资源 > JDBC > 数据源”中找到并选择相应的数据源,进入该数据源属性界面后,点击“WebSphere Application Server数据源属性”进行调整。 #### 八、事务日志调整 事务日志的正确配置对于...
这份内部培训材料以PPT格式呈现,旨在帮助用户快速理解和掌握WebSphere Application Server 7.0的使用和管理。由于是内部培训资料,内容通常会非常详细且实用,不仅包含理论知识,还会有大量的实践实验室指导,使...
WebSphere Application Server(WAS)是IBM提供的一款强大的企业级应用服务器,它在Java EE(Java Platform, Enterprise Edition)平台上运行,为开发和部署分布式应用程序提供了全面的支持。本指南将深入探讨WAS的...
通过这些实验,你可以了解如何配置和管理WebSphere Application Server,包括服务器启动、停止、部署应用程序、设置集群、安全管理以及性能调优等核心功能。实验可能还会涵盖故障排查技巧,帮助你理解WebSphere在...
1. **WebSphere Application Server基础**:理解WebSphere Application Server的基本架构,包括它的组件(如Node Agent、Server、Deployment Manager等),以及它们之间的交互方式。 2. **部署与管理**:学习如何...