[轉]tomcat查看GC信息

tomcat查看GC信息
tomcat啟動參數,將JVM GC資訊寫入tomcat_gc.log
CATALINA_OPTS='-Xms512m -Xmx4096m -XX:PermSize=64M -XX:MaxNewSize=128m -XX:MaxPermSize=64m -XX:ParallelGCThreads=8 -XX:+UseConcMarkSweepGC -Xloggc:/var/log/search/tomcat_gc.log'
各個參數含義,以及GC機制,參考下文:
一、相關概念
基本回收演算法
1.    引用計數(Reference Counting 
比較古老的回收演算法。原理是此物件有一個引用,即增加一個計數,刪除一個引用則減少一個計數。垃圾回收時,只用收集計數為0的物件。此演算法最致命的是無法處理迴圈引用的問題。
2.    標記-清除(Mark-Sweep 
此演算法執行分兩階段。第一階段從引用根節點開始標記所有被引用的物件,第二階段遍歷整個堆,把未標記的物件清除。此演算法需要暫停整個應用,同時,會產生記憶體碎片。
3.    複製(Copying 
演算法把記憶體空間劃為兩個相等的區域,每次只使用其中一個區域。垃圾回收時,遍歷當前使用區域,把正在使用中的物件複製到另外一個區域中。次演算法每次只處理 正在使用中的物件,因此複製成本比較小,同時複製過去以後還能進行相應的記憶體整理,不過出現碎片問題。當然,此演算法的缺點也是很明顯的,就是需要兩倍 記憶體空間。
4.    標記-整理(Mark-Compact 
此演算法結合了標記-清除 兩個演算法的優點。也是分兩階段,第一階段從根節點開始標記所有被引用物件,第二階段遍歷整個堆,把清除未標記物件並且把存活物件壓縮到堆的其中一 塊,按順序排放。此演算法避免了標記-清除的碎片問題,同時也避免了複製演算法的空間問題。
5.    增量收集(Incremental Collecting 
實施垃圾回收演算法,即:在應用進行的同時進行垃圾回收。不知道什麼原因JDK5.0中的收集器沒有使用這種演算法的。
6.    分代(Generational Collecting 
基於對物件生命週期分析後得出的垃圾回收演算法。把物件分為年青代、年老代、持久代,對不同生命週期的物件使用不同的演算法(上述方式中的一個)進行回收。現在的垃圾回收器(從J2SE1.2開始)都是使用此演算法的。

分代垃圾回收詳述
1.    Young(年輕代) 
輕代分三個區。一個Eden區,兩個Survivor區。大部分物件在Eden區中生成。當Eden區滿時,還存活的對象將被複製到Survivor (兩個中的一個),當這個Survivor區滿時,此區的存活物件將被複製到另外一個Survivor區,當這個Survivor去也滿了的時候,從第一 Survivor區複製過來的並且此時還存活的對象,將被複製年老區(Tenured)”。需要注意,Survivor的兩個區是對稱的,沒先後關 系,所以同一個區中可能同時存在從Eden複製過來 物件,和從前一個Survivor複製過來的物件,而複製到年老區的只有從第一個Survivor去過來的物件。而且,Survivor區總有一個是空 的。
2.    Tenured(年老代) 
年老代存放從年輕代存活的對象。一般來說年老代存放的都是生命期較長的物件。
3.    Perm(持久代) 
於存放靜態檔,如今Java類、方法等。持久代對垃圾回收沒有顯著影響,但是有些應用可能動態生成或者調用一些class,例如Hibernate等, 在這種時候需要設置一個比較大的持久代空間來存放這些運行過程中新增的類。持久代大小通過-XX:MaxPermSize=進行設置。

GC類型 
GC有兩種類型:Scavenge GCFull GC
1.    Scavenge GC 
一般情況下,當新物件生成,並且在Eden申請空間失敗時,就好觸發Scavenge GC,堆Eden區域進行GC,清除非存活對象,並且把尚且存活的對象移動到Survivor區。然後整理Survivor的兩個區。
2.    Full GC 
對整個堆進行整理,包括YoungTenuredPermFull GCScavenge GC要慢,因此應該盡可能減少Full GC。有如下原因可能導致Full GC
1.    Tenured被寫滿
2.    Perm域被寫滿
3.    System.gc()被顯示調用
4.    上一次GC之後Heap的各域分配策略動態變化
二、垃圾回收器

目前的收集器主要有三種:串列收集器、並行收集器、併發收集器
1.    串列收集器 
使用單執行緒所有垃圾回收工作,因為無需多執行緒交互,所以效率比較高。但是,也無法使用多處理器的優勢,所以此收集器適合單一處理器機器。當然,此收集器也可以用在小資料量(100M左右)情況下的多處理器機器上。可以使用-XX:+UseSerialGC打開。
2.    並行收集器 
1.    對年輕代進行並行垃圾回收,因此可以減少垃圾回收時間。一般在多執行緒多處理器機器上使用。使用-XX:+UseParallelGC.打開。並行收集器在J2SE5.0第六6更新上引入,在Java SE6.0中進行了增強--可以堆年老代進行並行收集。如果年老代不使用併發收集的話,是使用單執行緒進行垃圾回收,因此會制約擴展能力。使用-XX:+UseParallelOldGC打開。
2.    使用-XX:ParallelGCThreads=設置並行垃圾回收的執行緒數。此值可以設置與機器處理器數量相等
3.    此收集器可以進行如下配置:
1.    最大垃圾回收暫停:指定垃圾回收時的最長暫停時間,通過-XX:MaxGCPauseMillis=指定。為毫秒.如果指定了此值的話,堆大小和垃圾回收相關參數會進行調整以達到指定值。設定此值可能會減少應用的輸送量。
2.    輸送量:輸送量為垃圾回收時間與非垃圾回收時間的比值,通過-XX:GCTimeRatio=來設定,公式為1/1+N。例如,-XX:GCTimeRatio=19時,表示5%的時間用於垃圾回收。預設情況為99,即1%的時間用於垃圾回收。
3.    併發收集器 
可以保證大部分工作都併發進行(應用不停止),垃圾回收只暫停很少的時間,此收集器適合對回應時間要求比較高的中、大規模應用。使用-XX:+UseConcMarkSweepGC打開。
1.    發收集器主要減少年老代的暫停時間,他在應用不停止的情況下使用獨立的垃圾回收執行緒,跟蹤可達物件。在每個年老代垃圾回收週期中,在收集初期併發收集器會 對整個應用進行簡短的暫停,在收集中還會再暫停一次。第二次暫停會比第一次稍長,在此過程中多個執行緒同時進行垃圾回收工作。
2.    併發收集器使用處理器換來短暫的停頓時間。在一個N個處理器的系統上,併發收集部分使用K/N個可用處理器進行回收,一般情況下1<=K<=N/4
3.    在只有一個處理器的主機上使用併發收集器,設置為incremental mode模式也可獲得較短的停頓時間。
4.    浮動垃圾:由於在應用運行的同時進行垃圾回收,所以有些垃圾可能在垃圾回收進行完成時產生,這樣就造成了“Floating Garbage”,這些垃圾需要在下次垃圾回收週期時才能回收掉。所以,併發收集器一般需要20%的預留空間用於這些浮動垃圾。
5.    Concurrent Mode Failure:併發收集器在應用運行時進行收集,所以需要保證堆在垃圾回收的這段時間有足夠的空間供程式使用,否則,垃圾回收還未完成,堆空間先滿了。這種情況下將會發生併發模式失敗,此時整個應用將會暫停,進行垃圾回收。
6.    啟動併發收集器:因為併發收集在應用運行時進行收集,所以必須保證收集完成之前有足夠的記憶體空間供程式使用,否則會出現“Concurrent Mode Failure”。通過設置-XX:CMSInitiatingOccupancyFraction=指定還有多少剩餘堆時開始執行併發收集
4.    小結
1.    連續處理器: 
--
適用情況:資料量比較小(100M左右);單一處理器下並且對回應時間無要求的應用。 
--
缺點:只能用於小型應用
2.    並行處理器: 
--
適用情況:對輸送量有高要求,多CPU、對應用回應時間無要求的中、大型應用。舉例:幕後處理、科學計算。 
--
缺點:應用回應時間可能較長
3.    併發處理器: 
--適用情況:對回應時間有高要求,多CPU、對應用回應時間有較高要求的中、大型應用。舉例:Web伺服器/應用伺服器、電信交換、整合式開發環境。

三、常見配置舉例
1.    堆大小設置 
JVM 中最大堆大小有三方面限制:相關作業系統的資料模型(32-bt還是64-bit)限制;系統的可用虛擬記憶體限制;系統的可用實體記憶體限制。32位元系統 下,一般限制在1.5G~2G64為作業系統對記憶體無限制。我在Windows Server 2003 系統,3.5G實體記憶體,JDK5.0下測試,最大可設置為1478m 
典型設置:
1.    java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m
:設置JVM最大可用記憶體為3550M
-Xms3550m
:設置JVM促使記憶體為3550m。此值可以設置與-Xmx相同,以避免每次垃圾回收完成後JVM重新分配記憶體。
-Xmn2g
:設置年輕代大小為2G整個堆大小=年輕代大小 + 年老代大小 + 持久代大小。持久代一般固定大小為64m,所以增大年輕代後,將會減小年老代大小。此值對系統性能影響較大,Sun官方推薦配置為整個堆的3/8
-Xss128k
: 設置每個執行緒的堆疊大小。JDK5.0以後每個執行緒堆疊大小為1M,以前每個執行緒堆疊大小為256K。更具應用的執行緒所需記憶體大小進行調整。在相同物理內 存下,減小這個值能生成更多的執行緒。但是作業系統對一個進程內的執行緒數還是有限制的,不能無限生成,經驗值在3000~5000左右。 
2.    java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0 
-XX:NewRatio=4:設置年輕代(包括Eden和兩個Survivor區)與年老代的比值(除去持久代)。設置為4,則年輕代與年老代所占比值為14,年輕代占整個堆疊的1/5
-XX:SurvivorRatio=4
:設置年輕代中Eden區與Survivor區的大小比值。設置為4,則兩個Survivor區與一個Eden區的比值為2:4,一個Survivor區占整個年輕代的1/6 
-XX:MaxPermSize=16m:設置持久代大小為16m 
-XX:MaxTenuringThreshold=0:設置垃圾最大年齡。如果設置為0的話,則年輕代物件不經過Survivor區,直接進入年老代。對於年老代比較多的應用,可以提高效率。如果將此值設置為一個較大值,則年輕代物件會在Survivor區進行多次複製,這樣可以增加物件再年輕代的存活時間,增加在年輕代即被回收的概論。
2.    回收器選擇 
JVM給了三種選擇:串列收集器、並行收集器、併發收集器,但是串列收集器只適用於小資料量的情況,所以這裡的選擇主要針對並行收集器和併發收集器。預設情況下,JDK5.0以前都是使用串列收集器,如果想使用其他收集器需要在啟動時加入相應參數。JDK5.0以後,JVM會根據當前系統組態進行判斷。
0.    輸送量優先的並行收集器 
如上文所述,並行收集器主要以到達一定的輸送量為目標,適用於科學技術和幕後處理等。 
典型配置
1.    java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelGC
:選擇垃圾收集器為並行收集器。此配置僅對年輕代有效。即上述配置下,年輕代使用併發收集,而年老代仍舊使用串列收集。
-XX:ParallelGCThreads=20
:配置並行收集器的執行緒數,即:同時多少個執行緒一起進行垃圾回收。此值最好配置與處理器數目相等。
2.    java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
-XX:+UseParallelOldGC
:配置年老代垃圾收集方式為並行收集。JDK6.0支援對年老代並行收集。 
3.    java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=100:
設置每次年輕代垃圾回收的最長時間,如果無法滿足此時間,JVM會自動調整年輕代大小,以滿足此值。 
4.    java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy 
-XX:+UseAdaptiveSizePolicy:設置此選項後,並行收集器會自動選擇年輕代區大小和相應的Survivor區比例,以達到目標系統規定的最低相應時間或者收集頻率等,此值建議使用並行收集器時,一直打開。
1.    回應時間優先的併發收集器 
如上文所述,併發收集器主要是保證系統的回應時間,減少垃圾收集時的停頓時間。適用于應用伺服器、電信領域等。 
典型配置
0.    java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
:設置年老代為併發收集。測試中配置這個以後,-XX:NewRatio=4的配置失效了,原因不明。所以,此時年輕代大小最好用-Xmn設置。 
-XX:+UseParNewGC:設置年輕代為並行收集。可與CMS收集同時使用。JDK5.0以上,JVM會根據系統組態自行設置,所以無需再設置此值。
1.    java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection 
-XX:CMSFullGCsBeforeCompaction:由於併發收集器不對記憶體空間進行壓縮、整理,所以運行一段時間以後會產生碎片,使得運行效率降低。此值設置運行多少次GC以後對記憶體空間進行壓縮、整理。
-XX:+UseCMSCompactAtFullCollection:打開對年老代的壓縮。可能會影響性能,但是可以消除碎片
3.    輔助資訊 
JVM提供了大量命令列參數,列印資訊,供調試使用。主要有以下一些:
0.    -XX:+PrintGC 
輸出形式[GC 118250K->113543K(130112K), 0.0094143 secs]
                [Full GC 121376K->10414K(130112K), 0.0650971 secs]
1.    -XX:+PrintGCDetails 
輸出形式[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]
                [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
2.    -XX:+PrintGCTimeStamps -XX:+PrintGCPrintGCTimeStamps可與上面兩個混合使用 
輸出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs] 
3.    -XX:+PrintGCApplicationConcurrentTime:列印每次垃圾回收前,程式未中斷的執行時間。可與上面混合使用 
輸出形式:Application time: 0.5291524 seconds 
4.    -XX:+PrintGCApplicationStoppedTime:列印垃圾回收期間程式暫停的時間。可與上面混合使用 
輸出形式:Total time for which application threads were stopped: 0.0468229 seconds 
5.    -XX:PrintHeapAtGC:列印GC前後的詳細堆疊資訊 
輸出形式: 
34.702: [GC {Heap before gc invocations=7:
 
def new generation   total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
 
eden space 49152K,  99% used [0x1ebd0000, 0x21bce430, 0x21bd0000) 
from space 6144K,  55% used [0x221d0000, 0x22527e10, 0x227d0000) 
to   space 6144K,   0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
 
tenured generation   total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
 
the space 69632K,   3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000) 
compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
 
the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
 
ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
 
rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
 
34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)
Heap after gc invocations=8:
def new generation   total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000) 
eden space 49152K,   0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000) 
from space 6144K,  55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
 
to   space 6144K,   0% used [0x221d0000, 0x221d0000, 0x227d0000)
 
tenured generation   total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
 
the space 69632K,   4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000) 
compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
 
the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
 
ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
 
rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
 
}
 
, 0.0757599 secs]
6.    -Xloggc:filename:與上面幾個配合使用,把相關日誌資訊記錄到檔以便分析。
4.    常見配置匯總
0.    堆設置
0.    -Xms:初始堆大小
1.    -Xmx:最大堆大小
2.    -XX:NewSize=n:設置年輕代大小
3.    -XX:NewRatio=n:設置年輕代和年老代的比值。如:3,表示年輕代與年老代比值為13,年輕代占整個年輕代年老代和的1/4
4.    -XX:SurvivorRatio=n:年輕代中Eden區與兩個Survivor區的比值。注意Survivor區有兩個。如:3,表示EdenSurvivor=32,一個Survivor區占整個年輕代的1/5
5.    -XX:MaxPermSize=n:設置持久代大小
1.    收集器設置
0.    -XX:+UseSerialGC:設置串列收集器
1.    -XX:+UseParallelGC:設置並行收集器
2.    -XX:+UseParalledlOldGC:設置並行年老代收集器
3.    -XX:+UseConcMarkSweepGC:設置併發收集器
2.    垃圾回收統計資訊
0.    -XX:+PrintGC
1.    -XX:+PrintGCDetails
2.    -XX:+PrintGCTimeStamps
3.    -Xloggc:filename
3.    並行收集器設置
0.    -XX:ParallelGCThreads=n:設置並行收集器收集時使用的CPU數。並行收集執行緒數。
1.    -XX:MaxGCPauseMillis=n:設置並行收集最大暫停時間
2.    -XX:GCTimeRatio=n:設置垃圾回收時間占程式執行時間的百分比。公式為1/(1+n)
4.    併發收集器設置
0.    -XX:+CMSIncrementalMode:設置為增量模式。適用于單CPU情況。
1.    -XX:ParallelGCThreads=n:設置併發收集器年輕代收集方式為並行收集時,使用的CPU數。並行收集執行緒數。

四、調優總結
1.    年輕代大小選擇
1.    回應時間優先的應用盡可能設大,直到接近系統的最低回應時間限制(根據實際情況選擇)。在此種情況下,年輕代收集發生的頻率也是最小的。同時,減少到達年老代的對象。
2.    輸送量優先的應用:盡可能的設置大,可能到達Gbit的程度。因為對回應時間沒有要求,垃圾收集可以並行進行,一般適合8CPU以上的應用。
2.    年老代大小選擇
0.    回應時間優先的應用:年老代使用併發收集器,所以其大小需要小心設置,一般要考慮併發會話率會話持續時間等一些參數。如果堆設置小了,可以會造成記憶體碎片、高回收頻率以及應用暫停而使用傳統的標記清除方式;如果堆大了,則需要較長的收集時間。最優化的方案,一般需要參考以下資料獲得:
1.    併發垃圾收集資訊
2.    持久代併發收集次數
3.    傳統GC資訊
4.    花在年輕代和年老代回收上的時間比例
減少年輕代和年老代花費的時間,一般會提高應用的效率
1.    輸送量優先的應用:一般輸送量優先的應用都有一個很大的年輕代和一個較小的年老代。原因是,這樣可以盡可能回收掉大部分短期物件,減少中期的物件,而年老代盡存放長期存活對象。
3.    較小堆引起的碎片問題 
為年老代的併發收集器使用標記、清除演算法,所以不會對堆進行壓縮。當收集器回收時,他會把相鄰的空間進行合併,這樣可以分配給較大的物件。但是,當堆空間 較小時,運行一段時間以後,就會出現碎片,如果併發收集器找不到足夠的空間,那麼併發收集器將會停止,然後使用傳統的標記、清除方式進行回收。如果出 碎片,可能需要進行如下配置:
0.    -XX:+UseCMSCompactAtFullCollection:使用併發收集器時,開啟對年老代的壓縮。
1.    -XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這裡設置多少次Full GC後,對年老代進行壓縮


留言

張貼留言

這個網誌中的熱門文章

TOAD常用技巧分享

何謂RMA