Ｌｉｎｕｘ平臺上的ＷＡＳ垃圾回收策略分析

摘要：IBM Websphere Application Server V6.1的Java虛擬機在Linux平臺上使用Optthruput、Optavgpause、Gencon、Subpool四種GC策略來管理內(nèi)存。它們采用不同的算法，適用于不同的應(yīng)用程序，錯誤地選擇GC策略將導(dǎo)致性能瓶頸。文針對四種策略的特點展開討論，并結(jié)合JVM堆參數(shù)調(diào)優(yōu)實驗，探討了默認策略下的性能優(yōu)化方法，實踐證明這種方法對于提高應(yīng)用服務(wù)器性能是行之有效的。

關(guān)鍵詞：Websphere應(yīng)用程序服務(wù)器；Java虛擬機；垃圾回收

中圖分類號: TP302文獻標識碼: B文章編號：1009-3044(2008)22-837-02

WAS Garage Collection Policy Analysis on Linux Platform

MENG Cong-ying

(School of Software Engineering， Tongji University， Shanghai 201804， China)

Abstract: Four Garbage Collection (GC) policies， which are Optthruput， Optavgpause， Gencon， and Subpool， are used to manage memory for Java Virtual Machine (JVM) of IBM Websphere Application Server V6.1 on Linux platform. GC policies designed with different algorithms are suitable for different applications respectively. Taking improper policies will lead to performance bottleneck of applications. The features of the four GC policies are analyzed in this paper. The performance tuning method under default policy are discussed based on the experiment of JVM heap parameter tuning and proved to be effective for improving the performance of application server.

Key words: WAS; JVM; GC

1 引言

如今，大型Java EE 5項目被廣泛開發(fā)并應(yīng)用，針對這樣的應(yīng)用程序部署方案，使用較為廣泛的中間件為IBM Websphere Application Server V6.1（簡稱WAS），作為一套成形的產(chǎn)品，它穩(wěn)定性高，可操作性強，技術(shù)支持到位，相對于同類產(chǎn)品擁有很大優(yōu)勢。對于不同的操作系統(tǒng)WAS使用不同的Java虛擬機[1]（Java Virtual Machine，簡稱JVM），如在AIX， Windows， Linux (x86)， Linux (PPC)， iSeries， zSeries操作系統(tǒng)上使用IBM自己的JVM，而在Solaris或HP-UX操作系統(tǒng)上則使用Sun或HP的JVM。IBM JVM執(zhí)行一種自動的內(nèi)存管理機制，它利用自身的垃圾回收(Garbage Collection ，簡稱GC)策略確保內(nèi)存的可用性，大大減輕了程序員的負擔。考慮到上述差異，本文選擇了一套固定的實驗環(huán)境開始討論WAS的垃圾回收策略對于應(yīng)用程序性能的影響：

1)開發(fā)環(huán)境：IBM Rational Application Developer V7.0；

2)應(yīng)用程序：基于IBM jdk1.5開發(fā)的大型企業(yè)級應(yīng)用；

3)中間件：IBM Websphere Application Server V6.1 Base Edition（單節(jié)點環(huán)境）；

4)操作系統(tǒng)：Red Hat Enterprise Linux AS4 Update 2；

5)硬件平臺：PC Server。

2 垃圾回收

垃圾回收是Java 的特性，基于這種機制開發(fā)的應(yīng)用程序更具可靠性，只要應(yīng)用程序不濫用對象，就可以保持此可靠性。在WAS版本的更新中，GC策略一直試圖在提高吞吐量的同時降低垃圾回收操作耗時，它在最初設(shè)計時采用了一種被稱為“stop-the-world”的機制，即在執(zhí)行垃圾回收時掛起所有其它線程，這在后來的異步GC機制中得到改善。現(xiàn)在WAS在6.1這一版本中對垃圾回收策略及JVM內(nèi)存管理機制都做出了很大改進，堆碎片的問題得到顯著改善。

內(nèi)存分配過程中，JVM調(diào)用內(nèi)存的大小從初始堆擴充至最大堆，在Java虛擬機配置中啟用詳細垃圾回收后，當剩余堆大小不足以滿足分配請求時，WAS將自動啟動垃圾回收，釋放足夠堆空間供程序使用。當然，這種垃圾回收是有代價的。因此，下文將通過討論GC策略之間的差異試圖找到垃圾回收代價與工程性能的平衡點。

3 垃圾回收策略

不同類型的應(yīng)用程序在不同的GC策略下性能會有所差異， Linux平臺上，基于JDK1.5的IBM WAS JVM有四種GC策略，它們使用不同的算法，因而具有不同的優(yōu)勢，應(yīng)該通過“-Xgcpolicy:策略名”參數(shù)選用一種最適合本應(yīng)用類型的GC策略。

3.1 Optthruput默認策略

雖然更換GC策略有可能改善應(yīng)用程序性能，但實際上，只需要對JVM參數(shù)做適當調(diào)整，默認策略已經(jīng)可以滿足大多數(shù)應(yīng)用程序。它雖然延續(xù)了“stop-the-world”機制，但多線程的執(zhí)行速度較快，保證了內(nèi)存分配的吞吐率。

在JVM內(nèi)存管理機制中，GC執(zhí)行頻率和持續(xù)時間是兩個非常關(guān)鍵的概念。頻率取決于JVM堆大小和調(diào)用率，持續(xù)時間取決于JVM堆大小和堆內(nèi)對象數(shù)量。大的堆需要較長時間進行填充，因此增加堆大小會支持更多對象創(chuàng)建，在垃圾回收發(fā)生前應(yīng)用程序會運行較長時間。然而，在默認GC策略下，較大的堆也需要較長時間進行垃圾回收操作。可見JVM堆大小會影響垃圾回收行為，因此要得到GC執(zhí)行頻率和持續(xù)時長之間的合理比率，首先要定位合理的JVM堆大小。

人們可以接受的典型GC頻率約10秒/次，持續(xù)時間約1至2秒。如果沒有很好的性能監(jiān)控軟件和顧問程序，則可以通過分析/profiles/yourprofile/logs/server1/下的GC日志文件[2]native_stderr.log來確定JVM堆大小的調(diào)整方案。下面舉例分析JVM初始堆512MB，最大堆1024MB時的GC操作日志：

圖1是應(yīng)用程序初始化后不久的GC日志，此時使用到的堆大小為初始的512MB，JVM在間隔約2874秒后執(zhí)行了一次長約0.4秒的GC操作，釋放了60%的小對象區(qū)。

圖1是應(yīng)用程序運行了一段時間后出現(xiàn)性能問題時的GC日志，此時堆大小已擴展至最大的1024MB，而JVM卻在間隔約0.35秒就執(zhí)行了一次長達4.5秒的GC操作仍沒能釋放出足夠的堆空間，這顯然是不正常的。

■

圖1 應(yīng)用程序初始化后的GC日志說明圖

■

圖2 應(yīng)用程序運行至故障發(fā)生時的GC日志說明圖

增大最大堆能夠增加可供應(yīng)用程序服務(wù)器使用的內(nèi)存量，并降低垃圾回收頻率。但是，一味增大此設(shè)置也將延長垃圾回收的持續(xù)時間，而該設(shè)置如果大于可供應(yīng)用程序服務(wù)器實例使用的系統(tǒng)內(nèi)存量，將產(chǎn)生系統(tǒng)頁面調(diào)度，從而導(dǎo)致性能顯著下降。理論上講，初始堆大小較適宜的啟動值是最大堆的 25%，正確調(diào)整此參數(shù)有助于降低垃圾回收開銷，從而縮短GC停頓時間并提高吞吐量。

圖2中的GC持續(xù)時間已經(jīng)超過用戶忍耐范圍，因而不宜繼續(xù)擴大最大堆。為了不讓頻繁地GC操作占滿CPU時間片，可以將初始堆適當下調(diào)，實驗中將它調(diào)整為350MB，重啟服務(wù)后長期觀察GC執(zhí)行頻率與持續(xù)時間的比例，得到圖3中的實驗數(shù)據(jù)，可見，調(diào)整后的應(yīng)用程序內(nèi)存確實呈現(xiàn)出較好的使用狀態(tài)。經(jīng)過這樣的反復(fù)調(diào)優(yōu)，便可以得到一個比較適合特定應(yīng)用的JVM堆大小。另外，出現(xiàn)圖二這種情況還應(yīng)該結(jié)合heapdump等快照文件排查應(yīng)用程序本身是否存在內(nèi)存泄露[3]等問題。

3.2 Optavgpause策略

Optavgpause策略的優(yōu)點是異步執(zhí)行，GC操作的全過程[4]被分為三個步驟：標記無用內(nèi)存→釋放無用內(nèi)存→緊湊排列（合并空閑內(nèi)存區(qū)域）。在這種 GC策略中，雖然第三步仍要掛起所有線程，但前兩步在應(yīng)用程序運行過程中即可以被觸發(fā)。這種并發(fā)的GC策略降低了應(yīng)用程序響應(yīng)停頓時間，進而消除了用戶長時間等待GC執(zhí)行的弊端。因此在對用戶響應(yīng)時間要求較高的應(yīng)用程序部署時，可以考慮采用這種策略。

它的缺點是需要以吞吐量下降為代價換取GC 停頓時間的減少。因此當

（下轉(zhuǎn)第841頁）

（上接第838頁）

應(yīng)用程序運行于64 位平臺并使用大型堆時才建議考慮這種策略。另外，前兩個階段的異步GC操作，會產(chǎn)生“無用對象標記遺漏”的問題，主要原因是執(zhí)行標記操時某對象仍然被調(diào)用，但標記完成后該對象即不被調(diào)用，而其占用的內(nèi)存空間卻不能被有效回收。

3.3 Gencon策略

Gencon策略的優(yōu)點是根據(jù)對象生命周期不同執(zhí)行分代操作，可以通過調(diào)整不同區(qū)域的大小，適應(yīng)特別的應(yīng)用。JVM堆被分為新生代和老生代，新生代又被分為分配區(qū)和幸存區(qū)。在分配區(qū)填充滿后，GC線程開始異步地標記無用對象，然后將經(jīng)過多次垃圾回收仍被調(diào)用的對象移入老生代，其它的有用對象全部復(fù)制到幸存區(qū)，最后進行壓縮處理。此次操作之后，原來的幸存區(qū)開始充當分配區(qū)的角色，繼續(xù)內(nèi)存調(diào)用。這種算法對于應(yīng)用程序分配大量短期存活對象或在使用默認策略時出現(xiàn)堆碎片的情況比較適用。

它的缺點是增加了內(nèi)存管理的難度，并且也會產(chǎn)生與Optavgpause策略類似的“無用對象標記遺漏”問題。

3.4 Subpool策略

這種策略只能在IBM p或z系列平臺上使用，建議對于有16個或更多處理器的計算機使用這種策略。它的算法與默認策略相似，優(yōu)勢與分代策略相似，但其內(nèi)存分配策略更適合對稱多處理計算機，因而當大型多處理器計算機上的應(yīng)用程序伸縮性較差時可以選用這種策略。

4 結(jié)束語

根據(jù)不同的業(yè)務(wù)方向和項目情況采取相應(yīng)的GC策略，揚長避短，才能達到較好的效果。在真實生產(chǎn)環(huán)境下更換GC策略是有較大難度的，因此建議在系統(tǒng)全面商用之前，做好應(yīng)用程序運行壓力的評估、代碼優(yōu)化、部署方案規(guī)劃等工作，這才能更好地保證應(yīng)用程序到達生產(chǎn)環(huán)境中不會出現(xiàn)難以解決的問題。同時，應(yīng)該注意在調(diào)整GC策略之前做好相應(yīng)備份工作，避免造成更大的損失。本文根據(jù)個人及團隊維護經(jīng)驗撰寫，實踐證明合理的選擇垃圾回收策略對于提高應(yīng)用程序性能、穩(wěn)定性、可靠性是行之有效的。

參考文獻：

[1] 徐正超，喻成. Java虛擬機中內(nèi)存管理機制研究[J]. 中南民族大學報(自然科學版)，2007，26(3)：88-90.

[2] IBM公司.IBM Websphere應(yīng)用服務(wù)器5.0系統(tǒng)管理與配置[M]. 張云濤，龔玲譯.北京: 清華大學出版社， 2004:586-592.

[3] 馮濤，王海源. Java程序中內(nèi)存泄漏的原因、檢測和避免[J].福建電腦，2006，(3):82-83.

[4] 鄧長春，李詠霞，朱儒明. Java虛擬機及其關(guān)鍵技術(shù)研究[J]. 電腦知識與技術(shù)，2007，(7):134-135.