WebSphere的性能優(yōu)化

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

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

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

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

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

6、-cluster 參數(shù)）。 4、 通過 GC 工具，觀察 GC 平均時(shí)間、Heap 實(shí)際占用情況。Note: GC 是一個(gè) Stop The World 過程，也就是 說 GC 時(shí)系統(tǒng)對外不響應(yīng)，多 CPU 也不例外。看你的應(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 的最小值是程序剛啟動不久的占用值，譬如 320M切記：舊M JVM 初始值太大非常不好。 7

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

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

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

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

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

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

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

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

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

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

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

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

19、耗費(fèi)時(shí)間等；另外一個(gè)部分就是 Profiler front-end 。 通過 Profiler 工具的自定義 local 或 remote 協(xié)議傳輸?shù)?front-end ，其實(shí)，我們最常用的 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、 版本，透露給大家一個(gè)萬能序列號吧 （這東西不太好找），對各版本應(yīng)該都支持。 深入了解 Java,這類工具是不可少的： Name: License for You Lincese Code: A-G667#42616F-10kg1r134fq9m#2217 為了保證真實(shí)環(huán)境的檢測成功，我做了大量的試驗(yàn)，譬如： 1、 Windows 系列的本地、遠(yuǎn)程測試。 2、 AIX 的遠(yuǎn)程測試。 3、 Tomcat5.0、WebLogic8.14、WebSphere6.02，以及上述兩種方式的組合測試，排列組合，場景不下 10 個(gè)。 當(dāng)時(shí)也參閱了大量 JVM 文檔，JProfiler 官方幾百頁英文文檔，輔

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

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

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

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

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

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

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

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

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

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

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

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

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

34、也是不太相信，因?yàn)榇蠖鄶?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)驗(yàn)。對于 Sun 的 JVM 來說，一般可以設(shè)置 heap 最大最小值一 致，也是推薦的做法。因?yàn)樗?GC 策略默認(rèn)是復(fù)制、分代算法

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

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

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

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

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

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

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