开发学院操作系统 Linux/Unix IBM WebSphere Application Server诊断和调优（二... 阅读

IBM WebSphere Application Server诊断和调优（二）

　2010-09-27 08:17:54　来源：WEB开发网　闂傚倸鍊搁崐鎼佸磹閹间礁纾瑰瀣椤愯姤鎱ㄥ鍡楀幊缂傚倹姘ㄩ幉绋款吋閸澀缃曢梻鍌欑濠€閬嶆惞鎼淬劌绐楅柡宥庡亞娑撳秵銇勯弽顐沪闁绘挶鍎甸弻锝夊即閻愭祴鍋撻崷顓涘亾濮樼偓瀚�

闂傚倸鍊搁崐鎼佸磹閹间礁纾瑰瀣捣閻棗銆掑锝呬壕濡ょ姷鍋涢ˇ鐢稿极閹剧粯鍋愰柟缁樺笧閳ь剦鍙冨鍝勑ч崶褏浠奸梺璇茬箲閼归箖鎮鹃悜钘夎摕闁靛濡囬崢鐢告⒑鐟欏嫷鍟忛柛鐘崇墵閵嗗倹绺介崨濠勫幈闁硅壈鎻槐鏇熺墡闂備線娼уú銈団偓姘嵆閻涱噣骞掑Δ鈧粻锝嗙節闂堟稑鏆欏ù婊堢畺閺岋綁濮€閳惰泛婀辨竟鏇熺節濮橆厾鍘甸梺缁樺姦閸撴岸鎮樻潏銊ょ箚闁圭粯甯炴晶娑氱磼缂佹ḿ娲寸€规洖宕灃闁告劕鍟犻崜婵堟崲濞戞ḿ鏆嗗┑鐘辫兌閺佹牜绱撴担浠嬪摵闁圭懓娲ら悾鐑藉箳閹搭厽鍍甸梺鐟板悁閻掞箓鎮楅幖浣光拻濞达絿鍎ら崵鈧梺鎼炲€栭悧鐘荤嵁韫囨稒鏅搁柨鐕傛嫹

婵犵數濮烽弫鍛婃叏閻戣棄鏋侀柛娑橈攻閸欏繑銇勯幘鍗炵仼缂佺媭鍨堕弻娑㈠箛闂堟稒鐏堥悗鐟版啞缁诲啴濡甸崟顖氱閻庨潧鎽滈悾濂告⒑绾拋娼愭繛鑼枎椤繒绱掑Ο鑲╂嚌闂侀€炲苯澧畝锝堝劵椤︽煡鎮￠妶澶嬬厪闁割偅绻冮崑顏呯箾瀹割喕绨婚幆鐔兼⒑鐎圭姵銆冮柤鍐茬埣瀹曟繈鏁冮埀顒勨€旈崘顔嘉ч柛鈩冾殘閻熸劙姊洪悡搴℃毐闁绘牕銈稿畷鐑樼節閸パ冨祮闂侀潧楠忕槐鏇㈠储椤忓牊鈷戦柟鑲╁仜閸旀鏌￠崨顔锯姇缂佸倹甯熼ˇ瀵哥磼鏉堛劌绗氭繛鐓庣箻閸┾剝鎷呴柨瀣垫綗闂傚倷娴囧銊╂倿閿曞倸绠查柛銉墮閺嬩線鏌熼崜褏甯涢柡鍛倐閺屻劑鎮ら崒娑橆伓闂傚倸鍊搁崐鎼佸磹閹间礁纾瑰瀣椤愯姤鎱ㄥ鍡楀幊缂傚倹姘ㄩ幉绋款吋閸澀缃曢梻鍌欑濠€閬嶆惞鎼淬劌绐楅柡宥庡亞娑撳秵銇勯弽顐沪闁绘挶鍎甸弻锝夊即閻愭祴鍋撻崷顓涘亾濮樼偓瀚�　　闂傚倸鍊搁崐鎼佸磹閹间礁纾归柣鎴ｅГ閸ゅ嫰鏌ら崫銉︽毄濞寸姵姘ㄧ槐鎾诲磼濞嗘帒鍘＄紓渚囧櫘閸ㄥ爼濡撮崘顔煎窛闁哄鍨归崢娲倵楠炲灝鍔氭い锔诲灦瀹曪繝骞庨懞銉у帾闂婎偄娲﹀ú鏍ㄧ墡闂備浇顕х€垫帡宕滈悢濂夋綎闁惧繐婀辩壕鍏间繆椤栨碍鎯堟い顐㈢Т椤啴濡堕崱妤€顫庨梺鍛婎焼閸パ呭弨婵犮垼娉涜癌闁绘柨鍚嬮悡銉╂倵閿濆骸鍘撮柛瀣尰缁绘繂顫濋娑欏闁荤喐绮庢晶妤冩暜閹烘挾顩插ù鐓庣摠閻撴洟鏌熼幆褜鍤熼柍钘夘樀閺屽秶绱掑Ο鑽ゅ弳濡炪値鍋呯换鍫ュ箠濠婂懎鏋堟俊顖濐嚙椤忓綊姊婚崒娆戭槮闁硅绱曠划娆撳箣閿斿搫浜奸梺鍝勵槹閸ㄧ喖寮搁弮鍫熺厸闁告劧绲芥禍鍓х磽娴ｈ櫣甯涚紒瀣尰缁傛帡鏁冮崒姘憋紲濠殿喗锕╅崜锕傛倵閹惰姤鈷掑ù锝呮憸閿涘秶绱掗鍛仸妤犵偞鍨垮畷鍫曨敆閸屾氨銈﹂梺璇插嚱缂嶅棙绂嶉弽顓炵哗濞寸姴顑嗛悡娆撴⒑椤撱劎鐣卞褜鍨遍妵鍕棘閸喒鍋撶憴鍕攳濠电姴娲﹂崐閿嬨亜韫囨挸顏ら柛瀣崌瀵€燁檨婵炲吋鐗曢埞鎴︽偐鐎圭姴顥濋梺绋胯閸斿酣骞夊宀€鐤€婵炴垶岣块悿鍛存⒑閸︻叀妾搁柛鐘愁殜瀵煡骞栨担鍦弳闂佺粯娲栭崐鍦偓姘炬嫹

核心提示： 5、JVM本身内存泄漏（JVM有bug不是不可能）现在的难题是，如果是那个可怕的CMS程序本身有内存溢出，IBM WebSphere Application Server诊断和调优（二）(6)，在产品环境下，我们怎么去验证？我们自己开发的10来个web应用，WAS莫名迟缓、最后死掉，听过WAS6

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:IBMWebSphereAppServerprofilesAppSrv01wstemp，我不知道为什么WAS不主动去清除它，它偷偷的就上升到几个G，系统硬盘可能不久就后就会空间不足，WAS莫名迟缓、最后死掉。听过WAS6.0以前这个目录更夸张。大家见我附件的截图WAS_Console.png那个尖峰。

编缉推荐阅读以下文章