2025-02-15

原文:http://www.freelamp.com/1017721999/index_html

 由 徐永久 發表於 2002年04月02日 12:33。   

本文是我在工作中調整 Solaris 8 上的 WebLogic 6.0SP2 中遇到諸多問題後,查閱相關資料而產生的一些概念,羅列出來,或許對您有所幫助。這並不代表,筆者推薦您使用 WebLogic 和 Solaris 的組合,相反,筆者歡迎相關 Tomcat 性能調整方面的心得。筆者在 Sun Tech Day 上和 Bea 公司的相關人員討論後,認為 Bea 對 Open Source 和 Free Software 缺乏必要的遠見。

另外,其中一些術語的翻譯,是我自己的”創作“,我不知道別人是怎樣翻譯的。如果有不當的地方,希望指正。

堆( Heap)是 Java 程序的對象生活的地方,包含活的對象,死的對象以及剩餘內存。

當對象不能被運行中的程序的指針所到達時,這些對象成為”垃圾“。

JVM 的堆大小決定瞭 VM 花費在收集垃圾上的時間和頻度。

收集垃圾可以接受的速度與應用有關,應該通過分析實際的垃圾收集的時間和頻率來調整。

如果堆的大小很大,那麼完全垃圾收集就會很慢,但是頻度會降低。

如果你把堆的大小和內存的需要一致,完全收集就很快,但是會更加頻繁。

調整堆大小的的目的是最小化垃圾收集的時間,以在特定的時間內最大化處理客戶的請求。

在基準測試的時候,為保證最好的性能,要把堆的大小設大,保證垃圾收集不在整個基準測試的過程中出現。

堆劃分為兩個區域:新生代和舊生代。

新生代又分為:Eden 和兩片生存空間(survivor spaces)。其中保證有一片空間在任何時間是空的,當垃圾收集發生時, Eden 中的活的對象復制到下一片生存空間,對象就在生存空間之間復制,直到到達最大門限值(老化),然後復制到舊生代。

Eden 是新的對象分配的地方。

很多對象分配以後很快成為垃圾,這些對象稱為具有 “infant mortality.” 

對象生存的時間越長,需要的收集時間也越長,因此,收集變慢。

你的應用建立和釋放對象的速度決定瞭垃圾收集的頻度。因此,在編程時,應註意使用對象的緩沖,而不是新建立對象。


大多數對象在新生代就已經死去,因此你能有效的調整垃圾收集。如果你能安排大多數對象的生存期小於一個收集時間,那麼,垃圾收集是十分高效的。

錯誤的”代“配置會導致頻繁的垃圾收集,影響系統性能。

如果系統花費很多的時間收集垃圾,請減小堆大小。

一次完全的垃圾收集應該不超過 3-5 秒。

一般說來,你應該使用物理內存的 80% 作為堆大小。


在最大工作負荷的時候,監視 WebLogic 的性能。
使用 -verbosegc 選項測量有多少時間和資源用於垃圾收集。

打開垃圾收集的詳細信息輸出以及重定向:

% java -ms64m -mx64m -verbosegc -classpath $CLASSPATH
-Dweblogic.domain=mydomain -Dweblogic.Name=clusterServer1
-Djava.security.policy==/bea/weblogic6x/lib/weblogic.policy
-Dweblogic.management.server=192.168.0.101:7001 -Dweblogic.management.username=system
-Dweblogic.management.password=systemPassword weblogic.Server >> logfile.txt

在 Solaris 系統上,采用下面的命令:

weblogic.Server > server.out 2>&1

Java HotSpot VM 選項

標準的選項在各種平臺都已經有介紹:
http://java.sun.com/j2se/1.3/docs/tooldocs/win32/java.html
http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html
http://java.sun.com/j2se/1.3/docs/tooldocs/linux/java.html

以 -X 開頭的選項都為非標準選項(並不能在所有的 VM 上實現),在後續的版本中可能會不通知而變更。

由於 -XX 選項需要特別的系統權限,因此不建議隨便使用。

在 1.3.0 之前的版本, J2SDK 的 Solaris 版本帶有一個虛擬機的實現叫做 Exact VM(EVM),從 1.3.0 開始這個虛擬機被 Java HotSpot VM 所取代。

Java HotSpot VM 目前認識下面的 -X 選項:

-Xincgc 使用訓練 GC
-Xnoincgc 不是用訓練 GC(缺省)
-XX:MaxHeapFreeRatio=<Maximum> 最大堆剩餘百分比(缺省 70) 
-X:MinHeapFreeRation=<Minimum> 堆最小剩餘百分比(缺省 40) 
-Xint 隻作解析 (不作 JIT 編譯) 
-XX:+UseBoundThreads 綁定用戶級別的線程 (隻針對 Solaris) 
-Xmn<Size> 設置年輕一代的大小( young generation )(隻對 1.4) 

對象分配在 Eden,並且在這裡死亡,當 Eden 滿時,引起一個小的收集(minor collection),一些生存的對象被移動到舊生代,如果舊生代需要收集,則引起大收集(major collection ),這會比較緩慢。

如果 GC 成為瓶頸,那麼需要指定代的大小,檢查 GC 的詳細輸出,研究 GC 參數對性能的影響。

舊生代的收集采用 mark-compact 的方式,其中的一部分叫做”永久代“(permanent generation)很特別,他包括瞭 JVM 自身的所有反映數據(reflective data),例如類以及方法。

暫停時間的含義是應用因為垃圾收集而顯示出來的短暫停頓。

吞吐量的含義是在一段比較長的時間內,沒有用在垃圾收集的時間和總時間的百分比。

減少暫停時間的辦法可以采用小的年輕代和增量收集,但是這以犧牲吞吐率為代價。


Footprint 是一批工作進程的集合,以頁和緩沖行數計量,在物理內存有限或者有很多處理器的系統裡,footprint 可代表伸縮性。

Promptness 是對象死去的時間和內存變為可用時的時間差,在分佈系統中(包括 RMI)需要考慮。

很大的新生代能提高吞吐率,但是犧牲瞭 footprint 和 promptness。

Solaris 的 footprint 可以采用 pmap 命令來查看。


[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]
上面的三行是 GC 的詳細輸出,我們可以看到兩次小收集和一次大收集。箭頭前後的兩個數字代表 GC 後活的對象的組合長度。括號內的數字代表合計的空間,等於堆大小減去一片生存空間。

除非你遇到暫停的問題,否則,可以分配足夠的內存給 JVM,缺省的 64MB 總是太小。

設置 -Xms 和 -Xmx 為同樣的值能提高 JVM 的預測,但是如果你的選擇不對的話, JVM 不會補償。

當增加處理器時,記得增加內存,因為分配可以並行進行,而 GC 不是並行的。


NewSize 和 MaxNewSize 綁定新生代的長度的低端和高端,設置為一樣大小時和 -Xms 和 -Xmx 一樣解決新生代的預測時間。

如果生存空間太小,拷貝直接進入舊生代,如果太大的話,會空閑在那裡。

除非你碰到過渡的大收集或者暫停時間,否則分配足夠的內存給新生代,缺省的 MaxNewSize (32MB) 往往太小。

如果需要的話,最大的永久代大小可以使用 MaxPermSize 增加。

直接的 GC 調用可以采用 -XX:+DisableExplicitGC 來關閉。

對於大服務器而言,1.4 的 JVM 能提供 64 bit 尋址能力,提供更大的新生代大小,並發收集來減少大收集引起的暫停的影響。

Java HotSpot Client VM 主要用於減少應用啟動時間以及內存的 footprint 。

Java HotSpot Server VM 和 Java HotSpot Client VM 類似,但是在最大性能上作瞭調整。用於長期運行的服務應用。


Solaris 和 Linux 的 J2SE 1.3 隨帶 Java HotSpot Server VM 預安裝。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *