WebSphere的性能優(yōu)化

1、五、隔離CMS系統(tǒng)，服務(wù)器優(yōu)化從前面的介紹，大家應(yīng)該記得，我們開始是固定CMS分離其它應(yīng)用，但遭遇失敗?，F(xiàn)在是反過(guò)來(lái)，干脆把CMS系統(tǒng)趕出WAS平臺(tái)。說(shuō)實(shí)話，項(xiàng)目經(jīng)理做這個(gè)決定，我認(rèn)為已經(jīng)是鼓出很大勇氣了。當(dāng)時(shí)我們想在一個(gè)備用 AIX機(jī)上安裝CMS產(chǎn)品測(cè)試，但最后還是沒有做成：CMS這類文章發(fā)布系統(tǒng)很難安裝，也不好測(cè)試，又沒有l(wèi)iscence，而且還有一堆準(zhǔn)備工作。絕對(duì)沒有著名的openCMS安裝那么簡(jiǎn)單，當(dāng)然功能遠(yuǎn)遠(yuǎn)比它復(fù)雜。而且，我們當(dāng)時(shí)也低估了后來(lái)的工作，總覺得問題好 解決。在很遙遠(yuǎn)的06年中期，CMS廠商在客戶那邊一臺(tái) AIX的Tomcat上部署了一套CM滬品。但當(dāng)時(shí)客戶執(zhí)意 要求將其

2、跑在 WAS!,也就是現(xiàn)在的情況。最開始，客戶還要求我們必須用WAS勺集群（我們買的就是 WAS的ND版），無(wú)奈該CMS不支持。要是集群，又是死傷一遍。其實(shí)，現(xiàn)在想想，我們當(dāng)時(shí)太被動(dòng)，CMS這種東西，就供公司的幾十個(gè)編輯用，一個(gè)普通 Tomcat 就完全夠用。而且，把它和面向公網(wǎng)的 Internet 應(yīng)用 混在一起，完全沒有必要。也許，被動(dòng)是因?yàn)槲业膶?shí)力造成的。我們決定背水一戰(zhàn)時(shí)，已經(jīng)做過(guò)周密的計(jì)劃：某年某月某日晚上 8:00CM滬品負(fù)責(zé)人現(xiàn)場(chǎng)切換xx （我）負(fù)責(zé) WAS相關(guān)參數(shù)調(diào)整yy 負(fù)責(zé) AIX 參數(shù)。zz 負(fù)責(zé)應(yīng)用的測(cè)試總之，該行動(dòng)涉及到客戶方、產(chǎn)品提供商、公司高層、項(xiàng)目組。每個(gè)人都密

3、切關(guān)注，不下20人。每個(gè)人都守在電腦前，隨時(shí)聽候調(diào)遣，當(dāng)天晚上，我們都沒有準(zhǔn)備回家睡覺，大家齊心協(xié)力。真沒想到，整個(gè)式切換工作，一個(gè)小時(shí)就順利完成！第二天，客戶編輯打開瀏覽器，她們一定想不到昨晚大家準(zhǔn)備經(jīng)歷一場(chǎng)廝殺 系統(tǒng)持續(xù)平穩(wěn)地運(yùn)行了一周，然后是漫長(zhǎng)的五一，我回湖北黃岡老家休息了八天?；貋?lái)時(shí)，一切依舊。當(dāng)天晚上，我們這邊主要做了兩項(xiàng)工作：1、JVM的Heap參數(shù)，共五個(gè)。2、AIX 的 IO、 Paging Space 等共六個(gè)。當(dāng)然還有其他人的工作，譬如測(cè)試、監(jiān)控。還有一個(gè)非常重要的方面：JDBC連接池。我們?cè)瓉?lái)是在每個(gè) Web應(yīng)用里面獨(dú)立設(shè)置，這樣 20來(lái)個(gè)應(yīng)用就有幾百個(gè)DB連接，一不小

4、心DB就給撐死?，F(xiàn)在統(tǒng)一交由 WAS內(nèi)置DataSource處理，總共連接不到30個(gè)。 其實(shí)，我們項(xiàng)目開始部署時(shí)，就是這樣做的，但當(dāng)時(shí)WAS內(nèi)置的DataSource對(duì)JTA（XA）支持有bug （這個(gè)和 IBM 技術(shù)支持確認(rèn)過(guò)，但他們沒有給予很好的解決方案），不過(guò)Datasource 還是配好的。 但是這個(gè)工作已經(jīng)屬于 WAS生能優(yōu)化的主題了，而且優(yōu)化值必須持續(xù)觀察一段時(shí)間，通過(guò)專門的分析工具 來(lái)計(jì)算。優(yōu)化本身，是一項(xiàng)很考驗(yàn)人的工作，我就簡(jiǎn)單說(shuō)一下最實(shí)用方法吧，也許是專門針對(duì)IBM的產(chǎn)品。1、清理歸零 WAS日志。然后啟動(dòng) WAS生成日志（-verbose:gc 默認(rèn)是開的）2、 讓W(xué)AS持

5、續(xù)運(yùn)行約兩周，讓 JVM Heap占用曲線平穩(wěn)一段時(shí)間即可（用 IBM的Garbage Collector 分析 觀察）。3、 在 AIX的shell里，產(chǎn)生heapdump.phd文件，也就是 heap快照。命令：kill -3 pid （pid是 WAS勺PID，通過(guò)ps - ef查看），觀察heap當(dāng)時(shí)的碎片情況，是否需要單獨(dú)分大對(duì)象區(qū)（一般不需要設(shè)置），特 別是那個(gè)方法區(qū) Class 對(duì)象大?。?p-cluster 參數(shù)）。4、通過(guò)GC工具，觀察 GC平均時(shí)間、Heap實(shí)際占用情況。Note: GC是一個(gè)Stop The World過(guò)程，也就是說(shuō)GC時(shí)系統(tǒng)對(duì)外不響應(yīng)，多 CPU也不例外

6、?？茨愕膽?yīng)用實(shí)際需求了，GC持續(xù)時(shí)間和頻率是矛盾的，另外還有性能考慮。一般 Web應(yīng)用，我想讓GC持續(xù)時(shí)間（Pause time ）調(diào)節(jié)到合理值就ok 了，譬如0.2到0.4s。5、根據(jù) 3 可以算出 k-cluster 值，它是工具推薦值的 110%。6、 Heap的最小值是程序剛啟動(dòng)不久的占用值，譬如320M切記：IBM JVM初始值太大非常不好。7、 Heap的最大值是系統(tǒng)平穩(wěn)后的100/70。也就是說(shuō)如果最大值是 1000M那么應(yīng)該平穩(wěn)時(shí)是 700M,還有 30%的空余。IBM的JVM默認(rèn)情下的碎片問題， WAS空制臺(tái)下操作Heap猛增這種bug，你不得不堤防。Heap 最大值不設(shè)，A

7、IX下的WAS肯定00M當(dāng)然啦，我沒有考慮到大對(duì)象區(qū)的計(jì)算（雖然我們的應(yīng)用設(shè)置了專門的大對(duì)象區(qū)），包括IBM JVM支持的分代GC并行GC，Heap每次expand百分比等。那些情況我們一般不常用，譬如，你的AIX平臺(tái)一般不是16CPL吧吧？一口氣寫到現(xiàn)在，我忽然覺得該收尾了。下面就說(shuō)說(shuō)我對(duì)這類工作的整體看法吧。1、盡量在項(xiàng)目測(cè)試和試運(yùn)行的時(shí)候就進(jìn)行壓力、性能測(cè)試，當(dāng)正式投入使用后，如果發(fā)現(xiàn)類似問題，代價(jià) 非常大。躲過(guò)算你運(yùn)氣好，一般來(lái)說(shuō)，可能你們系統(tǒng)沒多少人用，也不是核心業(yè)務(wù)系統(tǒng)，譬如一般的電子 政務(wù)。2、 千萬(wàn)不要低估了技術(shù)風(fēng)險(xiǎn)，用IBM的系列產(chǎn)品尤其要慎重，出問題一定不要忘了技術(shù)支持。而

8、且，查資 料時(shí)，建議用google English ，因?yàn)橄?WebSphere這類問題，很少有中文資料。3、 程序部署環(huán)境建立時(shí)，就要考慮到日后的正式環(huán)境，譬如AIX的Paging Space、10、分區(qū)大小，默認(rèn) 值往往是不行的，而且在產(chǎn)品環(huán)境下改這些值，往往非常難。4、在項(xiàng)目開發(fā)初期， 就考慮到日志的問題， 因?yàn)樗稚⒌矫總€(gè)方法內(nèi)， 必須慎重定義好 debug、 info 、 warn、 error 級(jí)別，不要隨便忽視異常（ catch 里面不記錄），到真正程序出問題時(shí)，它就是我們的最重要的依據(jù) 之一。當(dāng)然這主要是功能性問題診斷。另外對(duì)于高負(fù)載網(wǎng)站，日志文件往往非常大，各級(jí)別日志千萬(wàn)不要

9、 混在一起，否則找問題就很困難了。5、 怎么說(shuō)呢，別死扣技術(shù)，以為什么都可以通過(guò)技術(shù)解決。你看我們最大的問題就是把CMS合移到Tomcat下。你要是問我，為什么 CM滬品會(huì)導(dǎo)致系統(tǒng)這么多的問題，我也不知道，到那時(shí)候，我確實(shí)也不想深入。我只要知道，趕出你這個(gè)應(yīng)用，我的系統(tǒng)就好控制多了。而且，那個(gè)CMS系統(tǒng)，在Tomcat下，就是跑得服服帖帖的，非常穩(wěn)定。難度是可惡的 WAS不過(guò)那CMS據(jù)IBM工程師，包括我們二次開發(fā)，都覺得夠爛了， 每個(gè) jsp 頁(yè)面都打開、關(guān)閉 DB connection （ 7 年前的 jsp 開發(fā)模式），還有那么嚴(yán)重的大對(duì)象問題。好了，以上總結(jié)的幾點(diǎn)可能也不充分、深入，但

10、如果你仔細(xì)讀我這篇文章，應(yīng)該有自己的想法。畢竟，只 有經(jīng)過(guò)思考的東西，才會(huì)屬于自己。先說(shuō)說(shuō)我接手這項(xiàng)工作的經(jīng)歷吧：該項(xiàng)目大部分是 06年 10月就部署在客戶那邊了，到 07年3月份， WAS 宕機(jī)問題實(shí)在無(wú)法忍受， 我才加入進(jìn)來(lái)， 前半年有另外一位同事斷斷續(xù)續(xù)處理， 但對(duì)問題一直都無(wú)可奈何， 而且項(xiàng)目負(fù)責(zé)人也沒有引起足夠的重視。 可想而知， 最后付出的代價(jià)是非常慘重的。 在這近半年的時(shí)間內(nèi)， 服務(wù)器宕機(jī)63次。每次宕機(jī)時(shí)，WAS勺JVM會(huì)dump出一個(gè)heapdump.phd文件（heap快照）,然后JVM就死 掉了，當(dāng)然，此時(shí) WAS也停止了響應(yīng)。一般我們的做法是重啟，最后是干脆AIX每天晚

11、上定時(shí)重啟。有時(shí)候一天還死多次。大家見附件的截圖（all-GC.png ）。這是我接手后，用IBM的分析工具得到的截圖。對(duì)截圖的分析，留給后面對(duì)應(yīng)的部分吧。服務(wù)器不穩(wěn)定、宕機(jī)問題，拖延到最后，客戶憤怒了，公司高層也害怕了，部門還專門成立了八人攻關(guān)組。 當(dāng)然了，我當(dāng)時(shí)的壓力也非常大，因?yàn)槲沂羌夹g(shù)負(fù)責(zé)人，也就是實(shí)實(shí)在在干活、想主意的。服務(wù)器診斷那段時(shí)間，從前到后，我們也是沿著一條線走下來(lái)，雖然最后發(fā)現(xiàn)很多路都走不通?，F(xiàn)在就按 這個(gè)思路，也就是時(shí)間先后一步步敘述吧。我想，大家如果也碰到類似應(yīng)用服務(wù)器診斷，應(yīng)該思路差不多。術(shù)語(yǔ)說(shuō)明：IBM Websphere Application Server :

12、WAS WebSphere本身是一個(gè)平臺(tái)，產(chǎn)品家族 OutOfMemoryError : 00M內(nèi)存泄漏，內(nèi)存溢出 Gabage Collection : GC 自動(dòng)垃圾回收Content Management System : CMS就是給新聞?lì)愰T戶網(wǎng)站編輯們用的系統(tǒng)我們?cè)\斷大體上經(jīng)歷了以下幾個(gè)階段：1、 按Job調(diào)度線程池引起內(nèi)存泄漏診斷：因?yàn)楹芏啻蜲OM!發(fā)生在某個(gè)特定時(shí)候，譬如14： 30、22 : 40左右。2、 按應(yīng)用程序引起內(nèi)存泄漏診斷：用JProfiler 等工具探測(cè)：因?yàn)榭偸前l(fā)生 OOM。3、 分離 WAS懷疑有OOM勺應(yīng)用：因?yàn)槊總€(gè) WA磁用太多，20來(lái)個(gè)，混一起沒法定位。

13、4、 用IBM官方heap、GC分析工具。以及和IBM技術(shù)支持聯(lián)系。 WAS AIX參數(shù)優(yōu)化。5、隔離出WAS超級(jí)惡魔程序：一個(gè) CMS產(chǎn)品。6、WAS AIX參數(shù)優(yōu)化、設(shè)置。我們走到第 5 步時(shí)，才出現(xiàn)效果。計(jì)算一下，那時(shí)已經(jīng)過(guò)去一個(gè)月了。服務(wù)器宕機(jī)、系統(tǒng)不穩(wěn)定，在這個(gè) 驗(yàn)收的時(shí)候，客戶已經(jīng)忍無(wú)可忍，以致后來(lái)的每一次行動(dòng)都得膽戰(zhàn)心驚得去做。一、按 Job 調(diào)度線程池導(dǎo)致內(nèi)存泄漏診斷因?yàn)閺奈覀?WAS勺日志（默認(rèn)是native_stderr.log）來(lái)看，最近半年的宕機(jī)時(shí)間都有一個(gè)明顯時(shí)間規(guī)律。見附件截圖 Job1-1.png 。我想，做過(guò)Java服務(wù)器性能調(diào)優(yōu)的朋友，都知道在 Web容器里面

14、啟線程池是個(gè)不太好的做法，因?yàn)閃eb容器本身有一個(gè)線程池，譬如 Servlet線程池（Tomcat默認(rèn)起25個(gè)），而自啟的線程池很容易導(dǎo)致Servlet線程管理混亂，最終導(dǎo)致 GC問題。我們的現(xiàn)象似乎和那很符合。如果我們沿著這個(gè)思路做下去，具體怎樣 實(shí)施呢？我們的WAS!部署了 20個(gè)左右的 Web應(yīng)用，譬如Lucene全文檢索、B2B行業(yè)數(shù)據(jù)同步等，都是通過(guò)Quartz 的 Job 調(diào)度做的，當(dāng)然還有很多其它調(diào)度。當(dāng)時(shí)，由我負(fù)責(zé)，通知相關(guān)負(fù)責(zé)人，將定時(shí)調(diào)度暫時(shí)去掉。觀 察了幾天，后來(lái)發(fā)現(xiàn)問題依然存在，不過(guò)時(shí)間有點(diǎn)隨機(jī)了。不過(guò)，最后還是發(fā)現(xiàn) OOM不是由Job調(diào)度引起的。 也就是說(shuō)，我們這個(gè)方

15、案是失敗的。而且，我們的很多想法都是臆測(cè)的，沒有可靠的根據(jù)，也沒有方向， 再加上我是第一次處理這種問題，這導(dǎo)致后來(lái)查找問題的艱難。但是，仔細(xì)想想，我們又能拿什么做依據(jù)呢？出現(xiàn)00M昔誤，我想大多數(shù)人想到的，除了JVM參數(shù)設(shè)置，就是內(nèi)存泄漏。其實(shí)，OOh發(fā)生有很多種情況，在IBM、Sun BEA等不同虛擬機(jī)上，因?yàn)?GC機(jī)制不一樣，所以原因一般都不同，容易定位難度也不 一樣。下文會(huì)談到。于是，我們干脆釜底抽薪分析問題吧：用JProfiler 檢測(cè)。二、按應(yīng)用程序?qū)е聝?nèi)存泄漏診斷，JProfiler 檢測(cè)如果遇到OOM可題，我想大家都會(huì)想到內(nèi)存檢測(cè)工具，現(xiàn)在最可靠的還是下面三種分析工具：Borla

16、nd的Optimized Suite ，Quest 的 JProbe，ej-technologies 的 JProfiler 。但面臨三個(gè)問題：1、三個(gè)都是商業(yè)產(chǎn)品，公司暫時(shí)沒有買，必須自己下載，而且要找序列號(hào)。2、工具必須支持 AIX5.3 + JDK1.42 + WAS6.0 不是 Windows 平臺(tái)。3、工具必須在客戶真實(shí)環(huán)境下部署，對(duì)客戶的業(yè)務(wù)不能有沖擊，也就是說(shuō)部署測(cè)試工具前，必須做個(gè)大量 測(cè)試，對(duì)工具非常熟練，遇到意外可以立即恢復(fù)現(xiàn)場(chǎng)。Note:項(xiàng)目上線后，而不是測(cè)試或試運(yùn)行階段遇到此類問題，非?？简?yàn)人；另外一個(gè)，就是性能和可伸縮性 問題，很可能把整個(gè)項(xiàng)目給毀了。當(dāng)我決定要這么做

17、后，就立即動(dòng)手查閱這些工具的官方文檔，用emule下載，最終都下載到了。試用后，最終選擇了 JProfiler4.03，比起其它工具，它界面美觀、清晰、功能強(qiáng)大、集成度高（Heap,Memory,CPU,Thread都統(tǒng)一了）。另外，JProbe沒有AIX版本，這也是放棄它的一個(gè)原因。JVM的Profiler 原理，都是通過(guò)JVM內(nèi)置的的標(biāo)準(zhǔn) C語(yǔ)言Profiler 接口收集數(shù)據(jù)，然后通過(guò)Profiler 工 具的客戶端展現(xiàn)。也就是說(shuō)各廠商的 Profiler 工具，都有兩個(gè)部分，一個(gè)部分是 Profiler Agent，和JVM 綁定，負(fù)責(zé)收集JVM內(nèi)部數(shù)據(jù)，譬如方法調(diào)用次數(shù)、耗費(fèi)時(shí)間等；另

18、外一個(gè)部分就是 Profiler front-end 。 通過(guò)Profiler 工具的自定義local或remote協(xié)議傳輸?shù)絝ront-end ，其實(shí)，我們最常用的 JavaIDE的debug 功能就是在此基礎(chǔ)上的（JPDA o （ JProfiler 的截圖http:/www.ej-）。下面是Sun官方文檔：JDK1.42 及以前是 JVM PI: JDK1.5 是 JVM TI : http:/java.sun.eom/j2se/1.5.0/docs/guide/jvmti/jvmti.html具體到JProfiler 的配置上，專門針對(duì) JDK1.4和1.5的JVM配置差別很大。我用的

19、JProfiler 是4.31版本，透露給大家一個(gè)萬(wàn)能序列號(hào)吧（這東西不太好找），對(duì)各版本應(yīng)該都支持。深入了解Java，這類工具是不可少的：Name: License for YouLincese Code: A-G667#42616F-10kg1r134fq9m#2217為了保證真實(shí)環(huán)境的檢測(cè)成功，我做了大量的試驗(yàn)，譬如：1、Windows系列的本地、遠(yuǎn)程測(cè)試。2、AIX的遠(yuǎn)程測(cè)試。3、 Tomcat5.0、WebLogic8.14、WebSphere6.02，以及上述兩種方式的組合測(cè)試，排列組合，場(chǎng)景不下10 個(gè)。當(dāng)時(shí)也參閱了大量JVM文檔，JProfiler官方幾百頁(yè)英文文檔，輔助的JP

20、robe對(duì)照。而且也制造過(guò)內(nèi)存泄漏造成的OOM場(chǎng)景。當(dāng)然，要是在幾個(gè)月前，在客戶那邊部署的測(cè)試環(huán)境時(shí)，就進(jìn)行測(cè)試該多好啊。在公司內(nèi)部，我用JProfiler測(cè)試了我們當(dāng)時(shí)部署的幾個(gè)應(yīng)用，沒有發(fā)現(xiàn)內(nèi)存泄漏，所以，我們最懷疑的是就是CMS系統(tǒng)。因?yàn)槌鰡栴}的那個(gè) WASk它占去了 90%的負(fù)荷（我們有多臺(tái)AIX、WA&艮務(wù)器）。該CMS超級(jí)龐大，感覺著名的賽迪網(wǎng)就用它，當(dāng)時(shí)該CMST商給我們部署都花了快一個(gè)月。所以再重新部署一套測(cè)試環(huán)境也挺困難。另外，CMS提供商不給lisence?，F(xiàn)在測(cè)試，客戶早就對(duì)我們惱火了，當(dāng)然不怎么配合，這對(duì)我們工作的開展就有很大的挑戰(zhàn)。在大致可以確定萬(wàn)無(wú)一失的情況

21、下，我們最終決定在客戶的真實(shí)環(huán)境下測(cè)試。也就是讓JProfiler 的agent端直接在 WAS的 JVM里面啟動(dòng)（北京IDC），然后遠(yuǎn)程（大連）監(jiān)控。本來(lái)該模式在另外幾個(gè)應(yīng)用的測(cè)試都通過(guò)了（因?yàn)楸本㊣DC那邊好幾臺(tái)AIX服務(wù)器）。但一部署上，客戶的一些編輯用CMS時(shí)就感覺超級(jí)慢，盡管我們用了JProfiler的最小負(fù)載模式。半個(gè)小時(shí)后，客戶實(shí)在無(wú)法忍受，打電話過(guò)來(lái)，又把我們部長(zhǎng)和經(jīng)理訓(xùn)了一頓，還要寫書面報(bào)告。我們被迫馬山中止測(cè)試，恢復(fù)現(xiàn) 場(chǎng)。雖然JProfiler 也支持客戶那邊的環(huán)境，但還是有bug,至少負(fù)載一高就有嚴(yán)重的性能問題，幾乎導(dǎo)致系統(tǒng)掛起，這是我當(dāng)時(shí)沒有料到的。JProfiler

22、 一啟動(dòng)，WAS勺啟動(dòng)時(shí)間就由原來(lái)的 3分鐘降到10分鐘，而且系統(tǒng)響應(yīng)明顯變慢，我們具體的環(huán)境如下（排列組合恐怕不下20種）：1、AIX5.3，Power PC64 位（不是 32 位）2、WebSphere6.03、IBM JVM1.424、Remote 模式我后來(lái)仔細(xì)讀了一下 JProfiler 的changeLog，發(fā)現(xiàn)對(duì)上面的環(huán)境支持不夠也很正常，因?yàn)楣俜皆谧罱?.3.x 版本下陸續(xù)有對(duì) IBM JVM和 Websphere6.0 的 features 和 bug fix : http:/www.ej-進(jìn)行到這一步，我忽然覺得無(wú)計(jì)可施了，此時(shí)已經(jīng)過(guò)了三周。上面的策略，我認(rèn)為是很正統(tǒng)的

23、處理方法。誰(shuí)怪我們當(dāng)初項(xiàng)目上線時(shí)沒有進(jìn)行充分的測(cè)試呢？其實(shí)，這類測(cè)試沒做也正常，00M這類問題誰(shuí)都無(wú)法預(yù)測(cè)。到這個(gè)時(shí)候，我想肯定有人會(huì)問我？你知道導(dǎo)致JVM的OOMT幾種情況嗎？在當(dāng)時(shí)，我想到了以下五種：1、JVM的heap最小、最大值沒有設(shè)，或不合理。2、 JVM的maxPermSize沒有設(shè)置（這個(gè)IBM的JVM沒有，一設(shè)置 JVM就起不來(lái)）。對(duì)于Sun和BEA的JVM以上兩種參數(shù)設(shè)置，可以排除90%以上的非程序內(nèi)存溢出導(dǎo)致的00M3、程序內(nèi)存泄漏4、有的JVM，當(dāng)在80%勺CPU時(shí)間內(nèi)，不能 GC出2%勺heap時(shí)，也發(fā)生 00（ IBM的JVM就是，但我沒有 驗(yàn)證）5、JVM本身內(nèi)存泄

24、漏（JVM有bug不是不可能）現(xiàn)在的難題是，如果是那個(gè)可怕的CMS程序本身有內(nèi)存溢岀，在產(chǎn)品環(huán)境下，我們?cè)趺慈ヲ?yàn)證？我們自己開發(fā)的10來(lái)個(gè)web應(yīng)用，測(cè)試并不是很難，在公司測(cè)試都可以。但是，我現(xiàn)在最想解決的，就是CMS測(cè)試的問題。而且，在我們那種環(huán)境下，該CMS產(chǎn)品供應(yīng)商并沒有透露成功案例。其實(shí)，最后發(fā)現(xiàn)，并不是內(nèi)存泄漏造成的，因?yàn)槲覀兊膆eap走勢(shì)都很平穩(wěn)。納悶的是，有1000M的heap,每次在heap只被占用400來(lái)M時(shí)就發(fā)生OOM沒有任何預(yù)兆。大家猜猜，會(huì)是什么原因？這個(gè)問題我到后面相關(guān)章節(jié)再說(shuō)吧。既然我們所有的矛頭都指向那個(gè)可怕的CMS系統(tǒng)，現(xiàn)在就是考慮隔離的問題。如果我們驗(yàn)證這個(gè)問

25、題是 CMS造成的，那么大部分責(zé)任就應(yīng)該由CMST商承擔(dān)。既然CMS我們不敢移（費(fèi)勁，而且客戶在正式用），那我就移我們開發(fā)的10來(lái)個(gè)web系統(tǒng)吧。三、移出除CMS系統(tǒng)以外的所有應(yīng)用說(shuō)起來(lái)容易啊，做呢？ 隔離（移動(dòng)）工作由我負(fù)責(zé)，具體涉及到 10來(lái)個(gè)相關(guān)負(fù)責(zé)人。 轉(zhuǎn)移工作，必須處理好很多問題，就說(shuō)幾個(gè)印象最深的吧：1、 某些應(yīng)用，如Blog和BBS,都涉及到文件、圖片上傳目錄和產(chǎn)品本身的環(huán)境，女口JDBC連接池、Cache 位置。2、 目標(biāo)服務(wù)器本身的環(huán)境，WAS安裝環(huán)境、網(wǎng)絡(luò)等。3、移植時(shí)的先后順序、調(diào)度，各應(yīng)用內(nèi)部本身的約束關(guān)系。4、移植后的測(cè)試。 當(dāng)然，還有一個(gè)最嚴(yán)峻的問題，客戶允許我們這

26、么做嗎？對(duì)它們目前運(yùn)行的系統(tǒng)有多大影響？風(fēng)險(xiǎn)如何評(píng) 估？這個(gè)工作持續(xù)了一天，已經(jīng)完成了80%的工作，到第二天，客戶又惱火了：WA取宕機(jī)了。為什么？這確實(shí)是 WAS勺一個(gè)bug : WAS勺后臺(tái)隨便一操作，heap就會(huì)突然上升幾百 M導(dǎo)致JVM內(nèi)存不夠。 不過(guò)WAS撐住的話，過(guò)半小時(shí)后就會(huì)降下來(lái)，我估計(jì)是WAS后臺(tái)對(duì)用戶操作狀態(tài)、文件都緩存到Session里面。你們可以檢查類似這樣的一個(gè)文件夾： d:IBMWebSphereAppServerprofilesAppSrv01wstemp ， 我不知道為什么 WAS不主動(dòng)去清除它，它偷偷的就上升到幾個(gè)G系統(tǒng)硬盤可能不久就后就會(huì)空間不足，WAS莫名遲

27、緩、最后死掉。聽過(guò) WAS6.0以前這個(gè)目錄更夸張。大家見我附件的截圖WAS_Console.png那個(gè)尖峰。咋辦？經(jīng)理也已經(jīng)不敢讓我們繼續(xù)鋌而走險(xiǎn)了。這個(gè)方案最終又以失敗告終。不過(guò)，最后我們還是發(fā)現(xiàn)問題出在CMS±。我們以前把這個(gè)問題向 CMS技術(shù)支持反映，有大量依據(jù)和現(xiàn)象，并且把相關(guān)日志都給它們。過(guò)了兩天，他們最后竟然只回了一句話“從給我的兩個(gè)日志來(lái)看，沒有找到任何與XXX有關(guān)的東西.”。TMD我真的很生氣，它們的產(chǎn)品都折磨我們半年之久了。不過(guò)，看他們對(duì)IBM的WAS和 JVM也不懂，我也就不想再說(shuō)什么了。下面是我的郵件，公司機(jī)密部分都隱去了： 引用附件是我們這段時(shí)間服務(wù)器宕機(jī)的

28、日志。 我們用 IBM Pattern Modeling and Analysis Tool for Java Garbage Collector Version 1.3.2 分析了一下虛擬機(jī)日志， 沒有發(fā)現(xiàn)是內(nèi)存泄漏導(dǎo)致； 用 IBM HeapAnalyzer Version 1.4.4 分析 heap 文件，也沒有發(fā)現(xiàn)很可疑的內(nèi)存泄漏。我想以前你們也這樣做過(guò)，現(xiàn)在我們分析錯(cuò)誤日志，發(fā)現(xiàn)有一個(gè)現(xiàn)象，在宕機(jī)時(shí)，總是找不到文件，我看 就是Websphere或是AIX IO資源不夠，不知道是什么導(dǎo)致的。但是，我們自己的應(yīng)用，基本上沒有什么10,除了一次load幾個(gè)配置文件。不過(guò)，我覺得你們WC啲1

29、0操作挺多的，不知道你對(duì)日志有什么新的 發(fā)現(xiàn)。客觀的說(shuō)，這幾個(gè)月來(lái)，宕機(jī)那臺(tái)服務(wù)器，除了你們的 XXX就以論壇和blog為主，而且他們都是開源的。 在頻繁宕機(jī)的06年11月份，我們的論壇和blog還沒有上線?，F(xiàn)在我們不得不每天晚上 11點(diǎn)定時(shí)重啟， 但這也不是長(zhǎng)久之計(jì)。現(xiàn)在，我們進(jìn)行分離遇到很大阻力，原來(lái)想把你們的XXX單獨(dú)分離岀來(lái)，在當(dāng)前的環(huán)境下，不是很現(xiàn)實(shí)，如安裝、測(cè)試（負(fù)載、定時(shí)服務(wù)），所以現(xiàn)在分離我們自己的應(yīng)用，但當(dāng)前在產(chǎn)品環(huán)境下，客戶方阻力也 很大。希望盡快能夠得到你們的問題建議和方案。文中說(shuō)到了 IBM的兩個(gè)分析工具，這也是我們后來(lái)的救星：我們就是需要這種離線分析工具，因?yàn)閷?shí)時(shí)檢測(cè)

30、已經(jīng)證明不現(xiàn)實(shí)。但我始終對(duì)該分析出來(lái)的結(jié)果抱懷疑態(tài)度，直到我去深入IBM的JVM以及和IBM的技術(shù)支持交流柳暗花明啊，至少看到了一點(diǎn)希望，不過(guò)最后我們還是失望而返。四、用 IBM 的 HeapAnalyzer 和 Garbagecollector 檢測(cè)找到這兩個(gè)工具，已經(jīng)是夠費(fèi)勁了，因?yàn)橐郧罢业腎BM HeapRoot工具，讓我對(duì)這類工具很失望。而且，這兩個(gè)工具，只有在IBM的Techinical Support網(wǎng)站能夠搜索到，但很不容易，因?yàn)槟莾蓚€(gè)工具，并不是象IBM的Websphere產(chǎn)品那樣宣傳，它只在 IBM Techinical Support文章的某些角落里出現(xiàn)。要知道，Techi

31、nical Support 是IBM很重要的收入來(lái)源，這類文檔，他們并不會(huì)讓你很輕易就拿到，比起B(yǎng)EA WLS的支持網(wǎng)站dev2dev差遠(yuǎn)了。具體診斷細(xì)節(jié)我就不詳述了。我認(rèn)為，IBM的WAS或 JVM出了性能和00M問題，這兩個(gè)工具是最有效的，而且是離線分析工具，比起那些實(shí)時(shí) Profiler 工具，某些場(chǎng)合有絕對(duì)的優(yōu)勢(shì)：譬如我們目前的產(chǎn)品環(huán)境， 你只能分析宕機(jī)后的日志，實(shí)時(shí)分析前面已經(jīng)驗(yàn)證是不可行的。從日志分析，我們最終得出結(jié)論，我們購(gòu)買的CMS系統(tǒng)有嚴(yán)重的碎片（大對(duì)象）問題，而該問題是00M勺罪魁禍?zhǔn)?，而且IBM工程師也得出了同一結(jié)論。不過(guò)，在起先我們得出這一結(jié)論一周后，我還始終不相信 h

32、eap碎片會(huì)導(dǎo)致00M直到IBM工程師總是向我強(qiáng)調(diào)。我想很多人也是不太相信，因?yàn)榇蠖鄶?shù)人用的都是Sun的JVM，譬如 Windows Solaris 上的hotspot。而且，Sun JVM出問題，如果是配置的問題，一般通過(guò)配置 heap最大最小值，以及 maxPermSize都可以解決。Heap碎片導(dǎo)致的00M只有BEA的JRockit和IBM JVM上發(fā)生，不過(guò)JRockit有專門文檔說(shuō)明，而且很容 易找到（就在jdk的文檔里面）。配置heap最小最大值，我想大多數(shù)人都有經(jīng)驗(yàn)。對(duì)于Sun的JVM來(lái)說(shuō)，一般可以設(shè)置 heap最大最小值一致，也是推薦的做法。因?yàn)樗腉C策略默認(rèn)是復(fù)制、分代算法

33、。也就是說(shuō)，它會(huì)將 heap分成不同的幾個(gè)區(qū)，譬如Solaris JVM中最上面有兩個(gè)大小相等的區(qū)。GC時(shí)刻，將一個(gè)區(qū)的存活對(duì)象復(fù)制到另外一個(gè)對(duì)等區(qū)，垃圾對(duì)象就算遺棄了。這樣在heap里面，就不存在碎片問題。另外，根據(jù)Java對(duì)象的存活期不同，將之轉(zhuǎn)移到不同的區(qū)（Tenured區(qū)），存活最長(zhǎng)的在最底部（火車算法），這也就是分代模型。具體請(qǐng)參 考官方文檔：對(duì)于 maxPermSize （ Permanent Generation ），主要和那些加載到 JVM里面的Java Class對(duì)象相關(guān)，它的 空間不是在Java Heap里面分配。如果你當(dāng)前的heap有1000M,permSize是200M

34、,那么JVM至少占用1200M。 在這個(gè)空間內(nèi)的對(duì)象的生存期和JVM是一樣的，譬如JDK的核心類庫(kù)，它們被 System Classloader加載到JVM的Method Area （方法區(qū)）后，就不會(huì)被 GC掉的，這些對(duì)象一般是 Class對(duì)象，而不是普通的實(shí)例對(duì) 象，也就是JVM的元數(shù)據(jù)。我們?cè)谟梅瓷鋾r(shí)經(jīng)常用到它們。所以，對(duì)于現(xiàn)在象Spring、Hibernate這些框架經(jīng)常通過(guò)反射創(chuàng)建實(shí)例，可能對(duì) maxPermSize要求就大了，缺省的 64M很多時(shí)候是不夠的，特別是對(duì)于 應(yīng)用服務(wù)器里的應(yīng)用，象JSP就會(huì)產(chǎn)生和加載很多 classes。不過(guò)，如果是它導(dǎo)致的 00M一般會(huì)有類似perm

35、size提示。但是，對(duì)于IBM的JVM情況就完全不一樣。它的默認(rèn) GC策略并沒有采取復(fù)制、分代。這個(gè)可以從GC日志分析出來(lái)。它不像 Sun的JVM那樣，有個(gè)單獨(dú)的方法區(qū)，它的方法區(qū)就放在Java Heap里面。JVM規(guī)范里面并沒有要求方法區(qū)的必須存放的位置，因?yàn)樗皇且粋€(gè)JVM實(shí)現(xiàn)問題。在IBM的JVM里面，這些對(duì)象一般分配在稱為 k-cluster 和p-cluster 里（cluster 又是屬于Heap），而 后者一般是臨時(shí)在heap里面申請(qǐng)。并且，這些 cluster是不能GC或是被移動(dòng)重排的（Compact過(guò)程）。這就導(dǎo)致Java Heap里面就如同馬蜂窩，但不同的蜂孔又不能合并，于

36、是，當(dāng)我們程序里面產(chǎn)生一個(gè)大對(duì)象，譬如2M的數(shù)組（數(shù)組必須分配在連續(xù)的內(nèi)存區(qū)）時(shí)，就沒有可分配空間了，于是就報(bào)告00M這些不能被移動(dòng)的cluster就稱為所謂的碎片。此時(shí)，JVM的Heap利用率可能不到50%。當(dāng)然，通過(guò)一定時(shí)期的 GC 日志，可以計(jì)算出cluster的合理大?。▽ｉT在 Java Heap的底部），另外，還 可以為這些大對(duì)象專門分配大對(duì)象區(qū)的（超過(guò)64k的對(duì)象）。通過(guò)上面的理論介紹，我想大家一定知道了為什么IBM的JVM里面不推薦heap的最大最小值相同，因?yàn)檫@樣碎片問題會(huì)非常嚴(yán)重：如果我們每次大對(duì)象申請(qǐng)內(nèi)存時(shí)，heap都擴(kuò)展5%譬如50M,碎片問題很大程度上可以避開，程序性能

37、也高些（尋找可用空隙和分配耗時(shí)，以及每次GC時(shí)間拉長(zhǎng)）。以上的具體闡述，請(qǐng)參考我在上文推薦的幾個(gè)URL另外再推薦三個(gè)寶貴的鏈接： 363&l oc=en US&cs=utf-8&lang=en （ IBM 技術(shù)支持告訴我的，太重要了?。┪蚁氪蠹覒?yīng)該會(huì)問：我怎么能夠肯定我的 00M可題是heap碎片造成的呢？下面的方法可以驗(yàn)證。在00M發(fā)生時(shí)，JVM會(huì)產(chǎn)生一個(gè)heapdump文件。然后用GarbageCollector 分析出該00M發(fā)生時(shí)刻，JVM去 申請(qǐng)的空間，譬如約 235k。此時(shí)，你再用HeapAnalyzer去分析此時(shí)的heap快照里面的gap size大?。?/p>

38、 隙大?。┖透髯缘目捎脭?shù)目。你會(huì)發(fā)現(xiàn)，大于 235k的空隙個(gè)數(shù)為0。這就是碎片導(dǎo)致 00M勺證據(jù)。另外，有人會(huì)問：我懷疑我的00雇因?yàn)槌绦騼?nèi)存泄漏造成的，怎么去驗(yàn)證?你可以用HeapAnalyzer分析發(fā)生00M時(shí)刻的heap快照，工具會(huì)羅列出哪些對(duì)象懷疑有內(nèi)存泄漏， 譬如Cache 對(duì)象都非常大（但你可以確定它不是內(nèi)存泄漏）。另外，分析這次宕機(jī)（從這次虛擬機(jī)啟動(dòng)到宕機(jī)這段時(shí) 間）的heap走勢(shì)，如果曲線明顯是向上傾斜，也就是那種典型的內(nèi)存泄漏圖，就有可能是內(nèi)存泄漏。當(dāng)然，還必須結(jié)合heap快照。內(nèi)存持續(xù)上升在JVM開始一段時(shí)間很正常，因?yàn)镴VM對(duì)第一次訪問到的 Class對(duì)象，譬如一個(gè)典型的 Web應(yīng)用，就有jdk的class、Spring或Hibernate 的class對(duì)象，它們都會(huì)被緩存下來(lái) （ClassLoader原理）， 一般均不會(huì)被GC當(dāng)大多數(shù)class對(duì)象緩存差不多（當(dāng)然還可能有一些Singleton對(duì)象，不過(guò)不怎么占分量），JVM的Heap就平穩(wěn)了，呈一水平波浪或鋸齒線。如果可以用JProfiler 這類工具實(shí)時(shí)監(jiān)控，就更