成爲Java GC專家(5)

轉載地址:http://www.importnew.com/13954.html

這是“成爲Java GC專家”系列的第五篇文章。在第一篇深入淺出Java垃圾回收機制中,我們已經學習了不同的GC算法流程、GC的工作原理、新生代(Young Generation)和老年代(Old Generation)的概念。你應該瞭解了JDK7中5種GC類型以及各種類型對應用程序的影響。

在第二篇如何監控Java的垃圾回收中,闡述了JVM是怎樣實際執行垃圾回收的,我們怎樣去監控GC以及哪些工具能讓這個過程更高效。

第三篇如何如何優化Java垃圾回收機制中展示了一些基於真實案例的最佳實踐。同時講解了怎樣儘量少地將對象放入老年代空間(Old Area),避免頻繁地執行完全垃圾回收(Full GC)。還說明了如何設置GC的類型和內存大小。

在第四篇Apache的MaxClients參數詳解及其在Tomcat執行FullGC時的影響中,解釋了MaxClients參數的重要性以及它在垃圾回收過程中對整個系統性能的顯著影響。

第五篇文章將講解Java程序性能調優的原則,尤其是在這個過程中必要的知識以及判斷你的程序是否需要調優。還會介紹調優過程中你可能遇到的問題。本文最後會給出一些建議,依據這些你能在對Java程序調優時做出更好的決策。

概述

並不是每個程序都需要調優。如果一個程序性能表現和預期一樣,你不必付出額外的精力去提高它的性能。然而,在程序調試完成之後,很難馬上就滿足它的性能需求,於是就有了調優這項工作。無論哪種編程語言,對應用程序進行調優都需要豐富的技術知識並且注意力高度集中。另外,你也不應該用相同的方式對兩個程序調優,因爲每個程序都有它自己獨特的運作方式和不同的資源使用方式。正因如此,調優比寫程序需要更多基礎知識。例如,你需要熟悉虛擬機、操作系統和計算機架構。而當你面對在這些知識基礎上編寫的程序時,就能成功地對它進行調優。

有時調優Java程序只需要修改JVM參數,比如GC的參數。但也有些時候需要修改程序代碼。無論那種方法,你首先都需要監控執行Java程序的進程。因此本文會講解下面幾個問題:

  • 怎樣監控Java程序?
  • 應該給JVM設置怎樣的參數?
  • 如何確定是否需要修改代碼?

對Java程序進行調優的必要知識

Java程序在Java虛擬機中運行。因此爲了進行調優,你需要理解JVM的工作流程。我之前有一篇博文Understanding JVM Internals,將讓你對JVM有深入的瞭解。

本文中有關JVM運作過程的知識主要關於GC和Hotspot。儘管只有這兩方面的知識可能無法對所有的Java程序進行調優,但是這兩個因素在大多數情況下都影響着Java程序的性能。

值得注意的是,從操作系統的角度來看,JVM也是一個應用程序進程。爲了給JVM創造良好的運行環境,你還需要對操作系統分配資源的過程有所瞭解。這意味着,想要調優Java程序,除了JVM你也應該理解操作系統或者硬件的工作方式。

需要具有的知識還有Java這門語言本身。另外理解鎖和併發、類加載和對象創建都是非常重要的。

當開始調優Java程序時,你應該整合以上各方面的知識來完成工作。

Java程序性能調優的過程

圖1是一張Java程序性能調優的流程圖,摘自由Charlie Hunt和Binu John所著的Java Performance

圖1:Java程序性能調優的過程

JVM分佈式模型

JVM分佈式模型用於決定是在一個JVM還是多個JVM上執行Java程序。你可以根據其有效性、響應能力和可維護性來進行選擇。當在多臺服務器上運行JVM時,你也可以選擇將多個JVM運行於一臺服務器或者每臺服務器運行一個JVM。例如,對於每臺服務器,你可以運行一個使用8GB堆內存的JVM,也可以運行4個使用2GB的JVM。你理應根據處理器內核的個數還有程序的特性來決定這個數量。當優先考慮響應能力時, 使用2GB的堆內存會優於8GB的,原因是這樣能在更短的時間內完成Full GC。當然,8GB的堆內存可以降低Full GC的頻率。如果你的程序使用了內部緩存,還可以通過增加緩存命中率來提高響應能力。綜上所述,選擇合適的模型需要考慮應用程序的特性,然後在各種模型中 選定一個能夠揚長避短的。

JVM架構

選擇JVM其實就是決定使用32位還是64位的JVM。在相同的條件下,你最好用32位的。因爲32位的JVM比64位性能更好。然而,32位 JVM最大支持的堆內存是4GB(無論在32位操作系統還是64位的上,實際可分配的大小都只有2-3GB)。如果需要更大的堆內存,還是用64位的 JVM比較合適。

表1:性能比較(數據來源

測試基準 時間(秒) 係數
C++ Opt 23 1.0x
C++ Dbg 197 8.6x
Java 64-bit 134 5.8x
Java 32-bit 290 12.6x
Java 32-bit GC* 106 4.6x
Java 32-bit SPEC GC* 89 3.7x
Scala 82 3.6x
Scala low-level* 67 2.9x
Scala low-level GC* 58 2.5x
Go 6g 161 7.0x
Go Pro* 126 5.5x

下一步就是運行程序來測試它的性能。這個過程包括GC調優、改變操作系統設置和修改代碼。對於這些工作,你可以使用系統監視工具或者性能分析工具。

注意:針對響應能力的調優和針對吞吐量的調優可能使用不同的方法。如果經常性地發生stop-the-word(串行GC暫時中斷程序執行),程序的響應能力就會被降低。比如在高吞吐量時執行Full GC。不要忘記,在調優時往往有得有失。這樣需要折衷處理的事情不僅發生在響應能力和吞吐量之間。例如使用更多的CPU資源來降低內存的使用,或者不得不忍受響應能力和吞吐量其中一個性能指標的下降。相反的情況同樣可能發生,實際的調優應該根據各指標的優先級來執行。

上面圖1中的流程展示了幾乎可用於所有Java程序的性能調優過程,包括Swing應用。然而,對於我們公司NHN用於提供網絡服務的服務器端程序來說,這個方法多少有些不合適。下面圖2中的流程是根據圖1修改而來,它更簡單,也更適合NHN。

圖2:對HNH的Java程序的調優過程

其中,Select JVM表示儘可能使用32位的JVM,除非你需要用64位的JVM來維護一個數GB的緩存。

現在,跟隨圖2中的流程,你會瞭解到每一步具體的工作。

JVM參數

我會主要講解如何爲Web服務端程序設置合適的JVM參數。儘管不一定適合所有的案例,但是最好的GC算法Concurrent Mark Sweep(CMS垃圾回收),特別是對於Web服務端程序。因爲低延遲是非常重要的。當然,在使用CMS時,由於新生代空間(New Area)的分配,可能發生較長時間的stop-the-world現象,不過調整新生代空間的大小或者它和整個堆空間的比例可能解決這個問題。

指定新生代空間的大小和指定整個對堆內存的大小同樣重要。你最好使用–XX:NewRatio來指定新生代和整個堆的大小比例,或者直接用–XX:NewSize來指定所需的新生代空間。這個配置是非常必要的,因爲大部分對象都不會存活很久。在Web程序中,除了緩存數據,其他多數對象都只在HttpRequestHttpResponse期間創建。這個時間幾乎不會超過1秒,表示這些對象的存活時間也不會超過1秒。如果新生代空間不夠大,對象會被轉移到老年代空間,以便騰出地方給新對象使用。老年代空間(Old Area)垃圾回收的代價是比新生代空間大的多的,因此很需要設置一個充足的新生代空間。

然而,當新生代空間的大小超過一個特定的水平,程序的響應能力會被降低。因爲新生代空間的垃圾回收過程,基本上是將數據從一個Survivor Area複製到另外一個(From Space和To Space)。另外,stop-the-world的現象在新生代空間和老年代空間執行垃圾回收時都會發生。如果新生代空間變大,那麼Survivor Area的空間也會更大,於是每次複製的數據就更多。基於這樣一種特性,我們應該通過指定不同操作系統中HotSpot JVM的NewRatio參數來分配合適大小的新生代空間。

表2:不同操作系統和配置下NewRatio的默認值

操作系統及參數 默認-XX:NewRatio
Sparc -server 2
Sparc -client 8
x86 -server 8
x86 -client 12

如果設置了NewRatio,那麼整個堆空間的1/(NewRatio +1)就是新生代空間的大小。上表可以看出Sparc -server的NewRatio默認值很小,因爲相比x86的操作系統,Sparc以前更多用於高端應用,這個值就是爲它們設置的。但現在x86操作系統的性能有很大提升,使用它們作爲服務器已經很普遍了。因此指定NewRatio爲2或者3是更好的選擇,就和Sparc -server上的配置一樣。

另外,你還可以通過指定NewSizeMaxNewSize來代替NewRatio。那麼新生代空間創建時的大小就是指定的NewSize,隨後可以一直增長到MaxNewSize的值。Eden(新創建對象存放的區域)和Survivor Area兩個區域會隨比例增加。就和你爲-Xms(譯者注:原文是-Xs,應該是筆誤)和-Xmx設置相同的值一樣,將MaxSize和 MaxNewSize設置爲相同的也是一個好選擇。

如果同時指定了NewRatio和NewSize,你應該使用更大的那個。於是,當堆空間被創建時,你可以用過下面的表達式計算初始新生代空間的大小:

1
min(MaxNewSize, max(NewSize, heap/(NewRatio+1)))

無論如何,僅通過一次嘗試就找到合適的堆空間和新生代空間大小是不可能的。根據我在NHN運行Web服務器的經驗,建議使用下面的JVM參數來運行Java程序。監控在這些參數的條件下程序的性能表現之後,你就能夠選擇更合適的GC算法或者配置。

表3:推薦的JVM參數

類型 參數
運行模式 -sever
整個堆內存大小 爲-Xms和-Xmx設置相同的值。
新生代空間大小 -XX:NewRatio: 2到4. -XX:NewSize=? –XX:MaxNewSize=?. 使用NewSize代替NewRatio也是可以的。
持久代空間大小 -XX:PermSize=256m -XX:MaxPermSize=256m. 設置一個在運行中不會出現問題的值即可,這個參數不影響性能。
GC日誌 -Xloggc:$CATALINA_BASE/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps. 記錄GC日誌並不會特別地影響Java程序性能,推薦你儘可能記錄日誌。
GC算法 -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75. 一般來說推薦使用這些配置,但是根據程序不同的特性,其他的也有可能更好。
發生OOM時創建堆內存轉儲文件 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=$CATALINA_BASE/logs
發生OOM後的操作 -XX:OnOutOfMemoryError=$CATALINA_HOME/bin/stop.sh 或 -XX:OnOutOfMemoryError=$CATALINA_HOME/bin/restart.sh. 記錄內存轉儲文件後,爲了管理的需要執行一個合適的操作。

測定程序的性能

爲了得到程序的性能表現,需要以下這些信息:

  • 系統吞吐量(TPS、OPS):從整體概念上理解程序的性能。
  • 每秒請求數(Request Per Second – RPS):嚴格來說,RPS和單純的響應能力是不同的,但是你可以把它理解爲響應能力。通過這個指標,你能夠瞭解到用戶需要多長時間才能得到請求的結果。
  • RPS的標準差:如果可能的話,還有必要包括事件的RPS。一旦出現了偏差,你應該檢查GC或者網絡系統。

爲了得到更準確的性能表現,你應該等到程序徹底啓動完成後再進行測量,因爲字節碼隨後會被HotSpot JIT編譯爲本地機器碼。總體來說,需要在程序加載完指定功能後,用nGrinder等工具測試至少10分鐘。

切實地調優

如果nGrinder測試的結果滿足了預期,那麼你不需要對程序進行性能調優。如果沒有達到預期結果,你就應該執行調優來解決問題。接下來會通過實例講解方法。

stop-the-world耗時過長

stop-the-world耗時過長可能是由於GC參數不合理或者代碼實現不正確。你可以通過分析工具或堆內存轉儲文件(Heap dump)來定位問題,比如檢查堆內存中對象的類型和數量。如果在其中找到了很多不必要的對象,那麼最好去改進代碼。如果沒有發現創建對象的過程中有特別的問題,那麼最好單純地修改GC參數。

爲了適當地調整GC參數,你需要獲取一段足夠長時間的GC日誌,還必須知道哪些情況會導致長時間的stop-the-world。想了解更多關於如何選擇合適的GC參數,可以閱讀我同事的一篇博文:How to Monitor Java Garbage Collection

CPU使用率過低

當系統發生阻塞,吞吐量和CPU使用率都會降低。這可能是由於網絡系統或者併發的問題。爲了解決這個問題,你可以分析線程轉儲信息(Thread dump)或者使用分析工具。閱讀這篇文章可以獲得更多關於線程轉儲分析的知識:How to Analyze Java Thread Dumps

你可以使用商業的分析工具對線程鎖進行精確的分析,不過大部分時候,只需使用JVisualVM中的CPU分析器,就能獲得足夠的信息。

CPU使用率過高

如果吞吐量很低但是CPU使用率卻很高,很可能是低效率代碼導致的。這種情況下,你應該使用分析工具定位代碼中性能的瓶頸。可使用的工具有:JVisualVMEclipse TPTP或者JProbe

調優方法

建議你使用如下方法對程序進行調優。

首先,檢查性能調優是否必要。測量性能不是一件簡單的工作,你也不能保證每次都獲得滿意的結果。因此如果程序已經滿足預期性能需求,不必在調優上增加額外的投入了。

問題只出在一個地方,你要做的就是去解決掉它。二八定律(Pareto principle)對性能調優同樣適用。這不是說某個模塊的低性能一定只源於一個問題,而是強調我們應該在調優時把注意力放在影響最大的那個問題上。在處理好了最重要的之後,你才應該去解決剩下其他的。也就是建議一次只對一個問題進行修復。

另外需要考慮到氣球效應(Balloon effect),有得必有失。你可以通過使用緩存來提高響應能力,但是當緩存逐漸增大,執行一次Full GC的時間也會更長。一般而言,如果你希望內存使用率比較低,那麼吞吐量和響應能力可能都會惡化。因此,要知道什麼對自己程序來說最重要的,而哪些又是次要的。

到此爲止,你應該已經瞭解瞭如何對Java程序進行性能調優。爲了介紹性能測定的具體過程,我不得不省略其中一些細節,不過我認爲這些也足夠應對大多數Java Web服務端程序了。

最後祝調優好運!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章