WebSphere的性能優(yōu)化

1、五、隔離 CMSK 統(tǒng)，服務(wù)器優(yōu)化 從前面的介紹，大家應(yīng)該記得，我們開始是固定 CMS 分離其它應(yīng)用，但遭遇失敗。現(xiàn)在是反過來，干脆 把 CM 繇統(tǒng)趕出 WASF 臺 說實話，項目經(jīng)理做這個決定，我認為已經(jīng)是鼓出很大勇氣了 。 當時我們想在一個備用 AIX 機上安裝 CMST 品測試，但最后還是沒有做成： CM 驅(qū)類文章發(fā)布系統(tǒng)很難安裝，也不好測試，又沒有 liscence ,而且還有一堆準備工作。絕對沒有著名 的 openCMSe裝那么簡單，當然功能遠遠比它復(fù)雜。而且，我們當時也低估了后來的工作，總覺得問題好 解決。 在很遙遠的 06 年中期，CMST 商在客戶那邊一臺 AIX 的 Tomc

2、at 部署了一套 CMST 品。但當時客戶執(zhí)意 要求將其跑在 WA且，也就是現(xiàn)在的情況。最開始，客戶還要求我們必須用 WAS 勺集群（我們買的就是 WAS 的 ND 版），無奈該 CM%支持。要是集群，又是死傷一遍。其實，現(xiàn)在想想，我們當時太被動， CMS種 東西，就供公司的幾十個編輯用，一個普通 Tomcat 就完全夠用。而且，把它和面向公網(wǎng)的 Internet 應(yīng)用 混在一起，完全沒有必要。也許，被動是因為我的實力造成的。 我們決定背水一戰(zhàn)時，已經(jīng)做過周密的計劃：某年某月某日晚上 8:00. CMST 品負責人現(xiàn)場切換 xx （我）負責 WA 手目關(guān)參數(shù)調(diào)整 yy 負責 AIX 參數(shù)。 z

3、z 負責應(yīng)用的測試 總之，該行動涉及到客戶方、產(chǎn)品提供商、公司高層、項目組。每個人都密切關(guān)注，不下 20 人。每個人都 守在電腦前，隨時聽候調(diào)遣，當天晚上，我們都沒有準備回家睡覺，大家齊心協(xié)力。 真沒想到，整個式切換工作，一個小時就順利完成 ！第二天，客戶編輯打開瀏覽器，她們一定想不 到昨晚大家準備經(jīng)歷一場廝殺,. 系統(tǒng)持續(xù)平穩(wěn)地運行了一周，然后是漫長的五一，我回湖北黃岡老家休息了八天。回來時，一切依舊。 當天晚上，我們這邊主要做了兩項工作： 1、 JVM 的 Heap 參數(shù)，共五個。 2、 AIX 的 IO、Paging Space 等共六個。 當然還有其他人的工作，譬如測試、監(jiān)控。 還有一

4、個非常重要的方面： JDBC 連接池。我們原來是在每個 Web 應(yīng)用里面獨立設(shè)置，這樣 20 來個應(yīng)用就 有幾百個 DB 連接，一不小心 DB 就給撐死?，F(xiàn)在統(tǒng)一交由 WAS置DataSource 處理，總共連接不到 30 個。 其實，我們項目開始部署時，就是這樣做的，但當時 WAS置的 DataSource 對 JTA（XA）支持有 bug （這個 和舊M 技術(shù)支持確認過，但他們沒有給予很好的解決方案），不過 Datasource 還是配好的。 但是這個工作已經(jīng)屬于 WAS性能優(yōu)化的主題了，而且優(yōu)化值必須持續(xù)觀察一段時間，通過專門的分析工具 來計算。 優(yōu)化本身，是一項很考驗人的工作，我就簡單

5、說一下最實用方法吧，也許是專門針對 舊M 的產(chǎn)品。 1、 清理歸零 WA 咱志。然后啟動 WAS 生成日志（-verbose:gc 默認是開的） 2、 讓 WA 箱續(xù)運行約兩周，讓 JVM Heap 占用曲線平穩(wěn)一段時間即可（用 舊M 的 Garbage Collector 分析 觀察）。 3、 在 AIX 的 shell 里，產(chǎn)生 heapdump.phd 文件，也就是 heap 快照。命令：kill -3 pid （pid 是 WAS 勺 PID，通過 ps ef 查看），觀察 heap 當時的碎片情況，是否需要單獨分大對象區(qū)（一般不需要設(shè)置），特 別是那個方法區(qū) Class 對象大?。╬

6、-cluster 參數(shù)）。 4、 通過 GC 工具，觀察 GC 平均時間、Heap 實際占用情況。Note: GC 是一個 Stop The World 過程，也就是 說 GC 時系統(tǒng)對外不響應(yīng)，多 CPU 也不例外?？茨愕膽?yīng)用實際需求了， GC 持續(xù)時間和頻率是矛盾的，另外 還有性能考慮。一般 Web 應(yīng)用，我想讓 GC#續(xù)時間（Pause time ）調(diào)節(jié)到合理值就 ok 了，譬如 0.2 到 0.4s。 5、 根據(jù) 3 可以算出 k-cluster 值，它是工具推薦值的 110% 6、 Heap 的最小值是程序剛啟動不久的占用值，譬如 320M切記：舊M JVM 初始值太大非常不好。 7

7、、 Heap 的最大值是系統(tǒng)平穩(wěn)后的 100/70。也就是說如果最大值是 1000M 那么應(yīng)該平穩(wěn)時是 700M,還有 30%勺空余。舊 M 的 JVM 默認情下的碎片問題， WAS 空制臺下操作 Heap 猛增這種 bug,你不得不堤防。Heap 最大值不設(shè)，AIX 下的 WASW 定 OOM 當然啦，我沒有考慮到大對象區(qū)的計算（雖然我們的應(yīng)用設(shè)置了專門的大對象區(qū)），包括 舊M JVM 支持的 分代 GC 并行 GC Heap 每次 expand 百分比等。那些情況我們一般不常用，譬如，你的 AIX 平臺一般不是 16CPU 吧？ 一口氣寫到現(xiàn)在，我忽然覺得該收尾了。下面就說說我對這類工作的

8、整體看法吧。 1、 盡量在項目測試和試運行的時候就進行壓力、性能測試，當正式投入使用后，如果發(fā)現(xiàn)類似問題，代價 非常大。躲過算你運氣好，一般來說，可能你們系統(tǒng)沒多少人用，也不是核心業(yè)務(wù)系統(tǒng)，譬如一般的電子 政務(wù)。 2、 千萬不要低估了技術(shù)風險，用 舊M 的系列產(chǎn)品尤其要慎重，出問題一定不要忘了技術(shù)支持。而且，查資 料時，建議用 google English ，因為象 WebSphere 這類問題，很少有中文資料。 3、 程序部署環(huán)境建立時，就要考慮到日后的正式環(huán)境，譬如 AIX 的 Paging Space、IO、分區(qū)大小，默認 值往往是不行的，而且在產(chǎn)品環(huán)境下改這些值，往往非常難。 4、 在

9、項目開發(fā)初期，就考慮到日志的問題，因為它分散到每個方法內(nèi)， 必須慎重定義好 debug、info、warn、 error級別，不要隨便忽視異常（catch 里面不記錄），到真正程序出問題時，它就是我們的最重要的依據(jù) 之一。當然這主要是功能性問題診斷。另外對于高負載網(wǎng)站，日志文件往往非常大，各級別日志千萬不要 混在一起，否則找問題就很困難了。 5、 怎么說呢，別死扣技術(shù)，以為什么都可以通過技術(shù)解決。 你看我們最大的問題就是把 CMS 合移到 Tomcat 下。你要是問我，為什么 CMST 品會導(dǎo)致系統(tǒng)這么多的問題，我也不知道，到那時候，我確實也不想深入。 我只要知道，趕出你這個應(yīng)用，我的系統(tǒng)就好

10、控制多了。而且，那個 CM 繇統(tǒng)，在 Tomcat 下，就是跑得服 服帖帖的，非常穩(wěn)定。難度是可惡的 WAS 不過那 CMS 據(jù)舊 M 工程師，包括我們二次開發(fā)，都覺得夠爛了， 每個 jsp 頁面都打開、關(guān)閉 DB connection （7 年前的 jsp 開發(fā)模式），還有那么嚴重的大對象問題。 好了，以上總結(jié)的幾點可能也不充分、深入，但如果你仔細讀我這篇文章，應(yīng)該有自己的想法。畢竟，只 有經(jīng)過思考的東西，才會屬于自己。 先說說我接手這項工作的經(jīng)歷吧：該項目大部分是 06 年 10 月就部署在客戶那邊了，到 07 年 3 月份，WAS 宕機問題實在無法忍受， 我才加入進來，前半年有另外一位同

11、事斷斷續(xù)續(xù)處理， 但對問題一直都無可奈何， 而且項目負責人也沒有引起足夠的重視。 可想而知，最后付出的代價是非常慘重的。 在這近半年的時間內(nèi)， 服務(wù)器宕機 63 次。每次宕機時，WAS 勺 JVM 會 dump 出一個 heapdump.phd 文件（heap 快照），然后 JVM 就死 掉了，當然，此時 WA 弛停止了響應(yīng)。一般我們的做法是重啟，最后是干脆 AIX 每天晚上定時重啟。有時 候一天還死多次。大家見附件的截圖（ all-GC.png ）。這是我接手后，用 舊 M 的分析工具得到的截圖。對 截圖的分析，留給后面對應(yīng)的部分吧。 服務(wù)器不穩(wěn)定、宕機問題，拖延到最后，客戶憤怒了，公司高層

12、也害怕了，部門還專門成立了八人攻關(guān)組。 當然了，我當時的壓力也非常大，因為我是技術(shù)負責人，也就是實實在在干活、想主意的。 服務(wù)器診斷那段時間，從前到后，我們也是沿著一條線走下來，雖然最后發(fā)現(xiàn)很多路都走不通?，F(xiàn)在就按 這個思路，也就是時間先后一步步敘述吧。我想，大家如果也碰到類似應(yīng)用服務(wù)器診斷，應(yīng)該思路差不多。 術(shù)語說明： 舊 M Websphere Application Server : WAS WebSphere 本身是一個平臺，產(chǎn)品家族 OutOfMemoryError : OOM 內(nèi)存泄漏，內(nèi)存溢出 Gabage Collection : GC 自動垃圾回收 Content Manag

13、ement System : CMS 就是給新聞類門戶網(wǎng)站編輯們用的系統(tǒng) 我們診斷大體上經(jīng)歷了以下幾個階段： 1、 按 Job 調(diào)度線程池引起內(nèi)存泄漏診斷：因為很多次 OO 曜發(fā)生在某個特定時候，譬如 14: 30、22 : 40 左右。 2、 按應(yīng)用程序引起內(nèi)存泄漏診斷：用 JProfiler 等工具探測：因為總是發(fā)生 OOM 3、 分離 WA 郭疑有 OOM 勺應(yīng)用：因為每個 WA 匙用太多，20 來個，混一起沒法定位。 4、 用舊 M 官方 heap、GC 分析工具。以及和 舊 M 技術(shù)支持聯(lián)系。 WAS AIX 參數(shù)優(yōu)化。 5、 隔離出 WA 湄級惡魔程序：一個 CMST 品。 6、

14、WAS AIX 參數(shù)優(yōu)化、設(shè)置。 我們走到第 5 步時，才出現(xiàn)效果。計算一下，那時已經(jīng)過去一個月了。服務(wù)器宕機、系統(tǒng)不穩(wěn)定，在這個 驗收的時候，客戶已經(jīng)忍無可忍，以致后來的每一次行動都得膽戰(zhàn)心驚得去做。 一、按 Job 調(diào)度線程池導(dǎo)致內(nèi)存泄漏診斷 因為從我們 WAS 勺日志（默認是 native_stderr.log） 來看，最近半年的宕機時間都有一個明顯時間規(guī)律。 見附件截圖 Job1-1.png。 我想，做過 Java 服務(wù)器性能調(diào)優(yōu)的朋友， 都知道在 We 裕器里面啟線程池是個不太好的做法， 因為 Web 器本身有一個線程池，譬如 Servlet 線程池（Tomcat 默認起 25 個）

15、，而自啟的線程池很容易導(dǎo)致 Servlet 線程管理混亂，最終導(dǎo)致 GC 問題。我們的現(xiàn)象似乎和那很符合。如果我們沿著這個思路做下去，具體怎樣 實施呢？ 我們的 WA 且部署了 20 個左右的 Web 應(yīng)用，譬如 Lucene 全文檢索、B2B 行業(yè)數(shù)據(jù)同步等，都是通過 Quartz 的 Job 調(diào)度做的，當然還有很多其它調(diào)度。當時，由我負責，通知相關(guān)負責人，將定時調(diào)度暫時去掉。觀 察了幾天，后來發(fā)現(xiàn)問題依然存在，不過時間有點隨機了。 不過，最后還是發(fā)現(xiàn) OOM是由 Job 調(diào)度引起的。 也就是說，我們這個方案是失敗的。而且，我們的很多想法都是臆測的，沒有可靠的根據(jù)，也沒有方向， 再加上我是第

16、一次處理這種問題，這導(dǎo)致后來查找問題的艱難。但是，仔細想想，我們又能拿什么做依據(jù) 呢？出現(xiàn) OOM 昔誤，我想大多數(shù)人想到的，除了 JVM 參數(shù)設(shè)置，就是內(nèi)存泄漏。其實， OO岐生有很多種 情況，在舊M、Sunn BEA 等不同虛擬機上，因為 GC 機制不一樣，所以原因一般都不同，容易定位難度也不 一樣。下文會談到。 于是，我們干脆釜底抽薪分析問題吧：用 JProfiler 檢測。 二、按應(yīng)用程序?qū)е聝?nèi)存泄漏診斷， JProfiler 檢測 如果遇到 OOM 可題，我想大家都會想到內(nèi)存檢測工具，現(xiàn)在最可靠的還是下面三種分析工具： Borland 的 Optimizeit Suite , Que

17、st 的 JProbe , ej-technologies 的 JProfiler 。但面臨三個問題： 1、 三個都是商業(yè)產(chǎn)品，公司暫時沒有買，必須自己下載，而且要找序列號。 2、 工具必須支持 AIX5.3 + JDK1.42 + WAS6.Q 不是 Windows 平臺。 3、 工具必須在客戶真實環(huán)境下部署，對客戶的業(yè)務(wù)不能有沖擊，也就是說部署測試工具前，必須做個大量 測試，對工具非常熟練，遇到意外可以立即恢復(fù)現(xiàn)場。 Note:項目上線后，而不是測試或試運行階段遇到此類問題，非?？简炄耍涣硗庖粋€，就是性能和可伸縮性 問題，很可能把整個項目給毀了。 當我決定要這么做后，就立即動手查閱這些工具

18、的官方文檔，用 emule 下載，最終都下載到了。試用后， 最終選擇了 JProfiler4.03 ，比起其它工具，它界面美觀、清晰、功能強大、集成度高 （Heap,Memory,CPU,Thread 都統(tǒng)一了）。另外，JProbe 沒有 AIX 版本，這也是放棄它的一個原因。 JVM 的 Profiler 原理，都是通過 JVM 內(nèi)置的的標準 C 語言 Profiler 接口收集數(shù)據(jù)，然后通過 Profiler 工 具的客戶端展現(xiàn)。也就是說各廠商的 Profiler 工具，都有兩個部分，一個部分是 Profiler Agent，和 JVM 綁定，負責收集 JVM 內(nèi)部數(shù)據(jù)，譬如方法調(diào)用次數(shù)、

19、耗費時間等；另外一個部分就是 Profiler front-end 。 通過 Profiler 工具的自定義 local 或 remote 協(xié)議傳輸?shù)?front-end ，其實，我們最常用的 JavaIDE 的 debug 功能就是在此基礎(chǔ)上的（JPDA。（ JProfiler 的截圖 http:/www.ej- ）。 下面是 Sun 官方文檔： JDK1.42 及以前是 JVM PI: http:/ JDK1.5 是 JVM TI : http:/ 具體到 JProfiler 的配置上，專門針對 JDK1.4 和 1.5 的 JVM 配置差別很大。 我用的 JProfiler 是 4.31

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

21、助的 JProbe 對照。而且也制造過內(nèi)存泄 漏造成的 OO崛景。 當然，要是在幾個月前，在客戶那邊部署的測試環(huán)境時，就進行測試該多好啊。 在公司內(nèi)部，我用 JProfiler 測試了我們當時部署的幾個應(yīng)用，沒有發(fā)現(xiàn)內(nèi)存泄漏，所以，我們最懷疑的 是就是 CM 繇統(tǒng)。因為出問題的那個 WA 且它占去了 90%的負荷（我們有多臺 AIX、WASB 務(wù)器）。該 CMS 超級龐大，感覺著名的賽迪網(wǎng)就用它，當時該 CMST 商給我們部署都花了快一個月。所以再重新部署一套 測試環(huán)境也挺困難。另外，CM 眺供商不給 lisence?，F(xiàn)在測試，客戶早就對我們惱火了， 當然不怎么配合， 這對我們工作的開展就有很

22、大的挑戰(zhàn)。 在大致可以確定萬無一失的情況下，我們最終決定在客戶的真實環(huán)境下測試。 也就是讓 JProfiler 的 agent 端直接在 WAS 勺 JVM 里面啟動（北京 IDC）,然后遠程（大連）監(jiān)控。 本來該模式在另外幾個應(yīng)用的測試都通過了（因為北京 IDC 那邊好幾臺 AIX 服務(wù)器）。但一部署上，客戶 的一些編輯用 CMS 寸就感覺超級慢，盡管我們用了 JProfiler 的最小負載模式。半個小時后，客戶實在無 法忍受，打電話過來，又把我們部長和經(jīng)理訓了一頓，還要寫書面報告。我們被迫馬山中止測試，恢復(fù)現(xiàn) 場。 雖然 JProfiler 也支持客戶那邊的環(huán)境，但還是有 bug,至少負載

23、一高就有嚴重的性能問題，幾乎導(dǎo)致系 統(tǒng)掛起，這是我當時沒有料到的。 JProfiler 一啟動，WAS 勺啟動時間就由原來的 3 分鐘降到 10 分鐘，而 且系統(tǒng)響應(yīng)明顯變慢，我們具體的環(huán)境如下（排列組合恐怕不下 20 種）： 1、 AIX5.3 , Power PC64 位（不是 32 位） 2、 WebSphere6.0 3、 RM JVM1.42 4、 Remote 模式 我后來仔細讀了一下 JProfiler 的 changeLog ,發(fā)現(xiàn)對上面的環(huán)境支持不夠也很正常，因為官方在最近的 4.3.x 版本下陸續(xù)有對 舊 M JVM 和 Websphere6.0 的 features 和

24、bug fix : http:/www.ej- 進行到這一步，我忽然覺得無計可施了 ，此時已經(jīng)過了三周。 上面的策略，我認為是很正統(tǒng)的處理方法。誰怪我們當初項目上線時沒有進行充分的測試呢？其實，這類 測試沒做也正常，OO 暗類問題誰都無法預(yù)測。 到這個時候，我想肯定有人會問我？你知道導(dǎo)致 JVM 的 OOMT 幾種情況嗎？在當時，我想到了以下五種： 1、 JVM 的 heap 最小、最大值沒有設(shè)，或不合理。 2、 JVM 的 maxPermSize 沒有設(shè)置（這個 舊 M 的 JVM 沒有，一設(shè)置 JVM 就起不來）。 對于 Sun 和 BEA 的 JVM 以上兩種參數(shù)設(shè)置，可以排除 90%以

25、上的非程序內(nèi)存溢出導(dǎo)致的 OOM 3、 程序內(nèi)存泄漏 4、 有的 JVM 當在 80 知勺 CPU 時間內(nèi)，不能 GC 出 2%勺 heap 時，也發(fā)生 OOM（舊M 的 JVM 就是，但我沒有 驗證） 5、 JVM 本身內(nèi)存泄漏（JVM 有 bug 不是不可能） 現(xiàn)在的難題是，如果是那個可怕的 CMS!序本身有內(nèi)存溢出，在產(chǎn)品環(huán)境下，我們怎么去驗證？我們自己 開發(fā)的 10 來個 web 應(yīng)用，測試并不是很難，在公司測試都可以。但是，我現(xiàn)在最想解決的，就是 CMSW 試 的問題。而且，在我們那種環(huán)境下，該 CMST 品供應(yīng)商并沒有透露成功案例。 其實，最后發(fā)現(xiàn)，并不是內(nèi)存泄漏造成的，因為我們的

26、 heap 走勢都很平穩(wěn)。納悶的是，有 1000M 的 heap, 每次在 heap 只被占用 400 來 M 時就發(fā)生 OOM 沒有任何預(yù)兆。大家猜猜，會是什么原因 ？這個問題 我到后面相關(guān)章節(jié)再說吧。 既然我們所有的矛頭都指向那個可怕的 CM繇統(tǒng)，現(xiàn)在就是考慮隔離的問題。如果我們驗證這個問題是 CMS 造成的，那么大部分責任就應(yīng)該由 CMSF 商承擔 。 既然 CM 眥們不敢移（費勁，而且客戶在正式用），那我就移我們開發(fā)的 10 來個 web 系統(tǒng)吧。 三、移出除 CMSK 統(tǒng)以外的所有應(yīng)用 說起來容易啊，做呢？ 隔離（移動）工作由我負責，具體涉及到 10 來個相關(guān)負責人。 轉(zhuǎn)移工作，必須

27、處理好很多問題，就說幾個印象最深的吧： 1、 某些應(yīng)用，如 Blog 和 BBS,都涉及到文件、圖片上傳目錄和產(chǎn)品本身的環(huán)境，如 JDBC連接池、Cache 位置。 2、 目標服務(wù)器本身的環(huán)境，WA 宏裝環(huán)境、網(wǎng)絡(luò)等。 3、 移植時的先后順序、調(diào)度，各應(yīng)用內(nèi)部本身的約束關(guān)系。 4、 移植后的測試。 當然，還有一個最嚴峻的問題，客戶允許我們這么做嗎？對它們目前運行的系統(tǒng)有多大影響？風險如何評 估？ 這個工作持續(xù)了一天，已經(jīng)完成了 80%的工作，到第二天，客戶又惱火了： WA 釵宕機了。 為什么？這確實是 WAS 勺一個 bug : WAS 勺后臺隨便一操作，heap 就會突然上升幾百 M 導(dǎo)致

28、JVM 內(nèi)存不夠。 不過 WA#住的話，過半小時后就會降下來，我估計是 WA 硝臺對用戶操作狀態(tài)、文件都緩存到 Session 里面。你們可以檢查類似這樣的一個文件夾： d:IBMWebSphereAppServerprofilesAppSrv01wstemp , 我不知道為什么 WA%主動去清除它，它偷偷的就上升到幾個 G,系統(tǒng)硬盤可能不久就后就會空間不足， WA 維名遲緩、最后死掉。聽過 WAS6.0 以前這個目錄更夸張。大家見我附件的截圖 WAS_Console.png 那個 尖峰。 咋辦？經(jīng)理也已經(jīng)不敢讓我們繼續(xù)鋌而走險了。這個方案最終又以失敗告終 。 不過，最后我們還是發(fā)現(xiàn)問題出在

29、CMS。我們以前把這個問題向 CM 眼術(shù)支持反映，有大量依據(jù)和現(xiàn)象， 并且把相關(guān)日志都給它們。過了兩天，他們最后竟然只回了一句話“從給我的兩個日志來看，沒有找到任 何與 XXX 有關(guān)的東西.”。TMD 我真的很生氣 ，它們的產(chǎn)品都折磨我們半年之久了。不過，看 他們對 舊 M 的 WA+口 JVM 也不懂，我也就不想再說什么了。下面是我的郵件，公司機密部分都隱去了： 引用 附件是我們這段時間服務(wù)器宕機的日志。 我們用 舊 M Pattern Modeling and Analysis Tool for Java Garbage Collector Version 1.3.2 分析了一下虛擬機日志

30、，沒有發(fā)現(xiàn)是內(nèi)存泄漏導(dǎo)致；用舊 M HeapAnalyzer Version 1.4.4 分析 heap 文件，也沒有發(fā)現(xiàn)很可疑的內(nèi)存泄漏。 我想以前你們也這樣做過，現(xiàn)在我們分析錯誤日志，發(fā)現(xiàn)有一個現(xiàn)象，在宕機時，總是找不到文件，我看 就是Websphere 或是 AIX IO 資源不夠，不知道是什么導(dǎo)致的。但是，我們自己的應(yīng)用，基本上沒有什么 IO,除了一次 load幾個配置文件。不過，我覺得你們 WCI IO 操作挺多的，不知道你對日志有什么新的 發(fā)現(xiàn)。 客觀的說，這幾個月來，宕機那臺服務(wù)器，除了你們的 XXX 就以論壇和 blog 為主，而且他們都是開源的。 在頻繁宕機的 06 年 11

31、 月份，我們的論壇和 blog 還沒有上線。現(xiàn)在我們不得不每天晚上 11 點定時重啟， 但這也不是長久之計。 現(xiàn)在，我們進行分離遇到很大阻力，原來想把你們的 XXX 單獨分離出來，在當前的環(huán)境下，不是很現(xiàn)實， 如安裝、測試（負載、定時服務(wù)），所以現(xiàn)在分離我們自己的應(yīng)用，但當前在產(chǎn)品環(huán)境下，客戶方阻力也 很大。 希望盡快能夠得到你們的問題建議和方案。 文中說到了舊 M 的兩個分析工具，這也是我們后來的救星：我們就是需要這種 離線分析工具，因為實時檢 測已經(jīng)證明不現(xiàn)實。但我始終對該分析出來的結(jié)果抱懷疑態(tài)度，直到我去深入 舊M 的 JVM 以及和 舊M 的技 術(shù)支持交流. 柳暗花明啊 ，至少看到了一

32、點希望，不過最后我們還是失望而返。 四、用 舊 M 的 HeapAnalyzer 和 GarbageCollector 檢測 找到這兩個工具，已經(jīng)是夠費勁了，因為以前找的 舊M HeapRootX 具，讓我對這類工具很失望。而且，這 兩個工具，只有在 舊 M 的 Techinical Support 網(wǎng)站能夠搜索到，但很不容易，因為那兩個工具，并不是象 舊M 的Websphere 產(chǎn)品那樣宣傳，它只在 舊M Techinical Support 文章的某些角落里出現(xiàn)。要知道， Techinical Support 是舊 M 很重要的收入來源，這類文檔，他們并不會讓你很輕易就拿到，比起 BEA

33、WLS 的支持網(wǎng)站 dev2dev 差遠了。 具體診斷細節(jié)我就不詳述了。我認為， 舊M 的 WA戚JVM 出了性能和 OOMR 題，這兩個工具是最有效的， 而且是離線分析工具，比起那些實時 Profiler 工具，某些場合有絕對的優(yōu)勢：譬如我們目前的產(chǎn)品環(huán)境， 你只能分析宕機后的日志，實時分析前面已經(jīng)驗證是不可行的。 從日志分析，我們最終得出結(jié)論，我們購買的 CM 繇統(tǒng)有嚴重的碎片（大對象）問題，而該問題是 OOM 勺 罪魁禍首，而且 舊 M 工程師也得出了同一結(jié)論。不過，在起先我們得出這一結(jié)論一周后，我還始終不相信 heap 碎片會導(dǎo)致 OOM 直到 舊 M 工程師總是向我強調(diào)。 我想很多人

34、也是不太相信，因為大多數(shù)人用的都是 Sun 的 JVM 譬如 Windows Solaris 上的 hotspot。而 且，Sun JVM 出問題，如果是配置的問題，一般通過配置 heap 最大最小值，以及 maxPermSize 都可以解決。 Heap 碎片導(dǎo)致的 OOM 只有 BEA 的 JRockit 和舊 M JVM 上發(fā)生，不過 JRockit 有專門文檔說明，而且很容 易找到（就在jdk 的文檔里面）。 配置 heap 最小最大值，我想大多數(shù)人都有經(jīng)驗。對于 Sun 的 JVM 來說，一般可以設(shè)置 heap 最大最小值一 致，也是推薦的做法。因為它的 GC 策略默認是復(fù)制、分代算法

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

36、heap 有 1000MpermSize 是 200M,那么 JVM 至少占用 1200M 在這個空間內(nèi)的對象的生存期和 JVM 是一樣的，譬如 JDK 的核心類庫，它們被 System Classloader 加載到 JVM 的 Method Area （方法區(qū)）后，就不會被 GC 掉的，這些對象一般是 Class 對象，而不是普通的實例對 象，也就是JVM 的元數(shù)據(jù)。我們在用反射時經(jīng)常用到它們。所以，對于現(xiàn)在象 Spring、Hibernate 這些框 架經(jīng)常通過反射創(chuàng)建實例，可能對 maxPermSize 要求就大了，缺省的 64M 很多時候是不夠的，特別是對于 應(yīng)用服務(wù)器里的應(yīng)用，象

37、JSP就會產(chǎn)生和加載很多 classes。不過，如果是它導(dǎo)致的 OOM一般會有類似 perm size提示。 但是，對于舊 M 的 JVM 情況就完全不一樣。它的默認 GC 策略并沒有采取復(fù)制、分代。這個可以從 GC 日 志分析出來。它不像 Sun 的 JVM 那樣，有個單獨的方法區(qū)，它的方法區(qū)就放在 Java Heap 里面。JVM 規(guī)范 里面并沒有要求方法區(qū)的必須存放的位置，因為它只是一個 JVM 實現(xiàn)問題。 在舊 M 的 JVM 里面，這些對象一般分配在稱為 k-cluster 和 p-cluster 里（cluster 又是屬于 Heap）,而 后者一般是臨時在 heap 里面申請。并

38、且，這些 cluster 是不能 GC 或是被移動重排的（Compact 過程）。 這就導(dǎo)致 Java Heap 里面就如同馬蜂窩，但不同的蜂孔又不能合并，于是，當我們程序里面產(chǎn)生一個大對 象，譬如 2M 的數(shù)組（數(shù)組必須分配在連續(xù)的內(nèi)存區(qū)）時，就沒有可分配空間了，于是就報告 OOM 這些不能 被移動的 cluster 就稱為所謂的碎片。此時，JVM 的 Heap 利用率可能不到 50% 當然，通過一定時期的 GC 日志，可以計算出 cluster 的合理大?。▽ｉT在 Java Heap 的底部），另外，還 可以為這些大對象專門分配大對象區(qū)的（超過 64k 的對象）。 通過上面的理論介紹， 我

39、想大家一定知道了為什么 舊M 的 JVM 里面不推薦 heap 的最大最小值相同，因為這 樣碎片問題會非常嚴重：如果我們每次大對象申請內(nèi)存時， heap 都擴展 5%譬如 50M,碎片問題很大程度 上可以避開，程序性能也高些（尋找可用空隙和分配耗時，以及每次 GC 時間拉長）。 以上的具體闡述，請參考我在上文推薦的幾個 URL 另外再推薦三個寶貴的鏈接： http:/ 363&loc=en US&cs=utf-8&lang=en http:/ （舊M 技術(shù)支持告訴我的， 太重要了 ?。?http:/ 我想大家應(yīng)該會問：我怎么能夠肯定我的 OOM 可題是 heap 碎片造

40、成的呢？下面的方法可以驗證。 在。眥生時，JVM 會產(chǎn)生一個 heapdump 文件。然后用 GarbageCollector 分析出該。眥生時刻,JVM 去 申請的空間，譬如約 235k。此時，你再用 HeapAnalyzer 去分析此時的 heap 快照里面的 gap size 大?。?隙大?。┖透髯缘目捎脭?shù)目。你會發(fā)現(xiàn)，大于 235k 的空隙個數(shù)為 0。這就是碎片導(dǎo)致 OOM 勺證據(jù)。 另外，有人會問： 我懷疑我的。呢因為程序內(nèi)存泄漏造成的，怎么去驗證 ? 你可以用 HeapAnalyzer 分析發(fā)生 OO 附刻的 heap 快照，工具會羅列出哪些對象懷疑有內(nèi)存泄漏， 譬如 Cache

41、 對象都非常大（但你可以確定它不是內(nèi)存泄漏）。另外，分析這次宕機（從這次虛擬機啟動到宕機這段時 間）的 heap走勢，如果曲線明顯是向上傾斜， 也就是那種典型的內(nèi)存泄漏圖， 就有可能是內(nèi)存泄漏。 當然， 還必須結(jié)合 heap 快照。 內(nèi)存持續(xù)上升在 JVM 開始一段時間很正常，因為 JVM 對第一次訪問到的 Class 對象，譬如一個典型的 Web 應(yīng)用，就有jdk 的 class、Spring 或 Hibernate 的 class 對象，它們都會被緩存下來 （ClassLoader 原理）， 一般均不會被 GC 當大多數(shù) class 對象緩存差不多（當然還可能有一些 Singleton 對象，不過不怎么占分 量），JVM 的 Heap 就平穩(wěn)了，呈一水平波浪或鋸齒線。 如果可以用 JProfiler 這類工具實時監(jiān)控，就更容易確診了。 經(jīng)過一番周