CMSgc日誌_為什麼CMSGC時出現ConcurrentModeFailure

1、為什麼cms GC時出現Concurrent Mode Failure

並發收集器（concurrentcollector）指的是回收年老代和持久代時，採用多個線程和應用線程並發執行，減少應用停頓時間，但如果參數設置不當，容易出現Concurrent ModeFailure現象，此時JVM將採用停頓的方式進行full gc，整個gc時間相當可觀，完全違背了採用CMS GC的初衷。
出現此現象的原因主要有兩個：一個是在年老代被用完之前不能完成對無引用對象的回收；一個是當新空間分配請求在年老代的剩餘空間中得到滿足。原文如（if theconcurrent collector is unable to finish reclaiming the unreachable objectsbefore the tenured generation fills up, or if an allocation cannot be satisfiedwith the available free space blocks in the tenured generation, then theapplication is paused and the collection is completed with all the applicationthreads stopped）。
出現此現象的具體gc日誌如下：
90003.167: [GC 90003.167: [ParNew: 261760K->0K(261952K), 0.0204310secs] 778897K->520196K(1310528K), 0.0207190 secs]
90006.049: [GC 90006.050: [ParNew: 261760K->0K(261952K), 0.0136380 secs]781956K->521446K(1310528K), 0.0138720 secs]
90010.628: [GC 90010.628: [ParNew: 261760K->261760K(261952K), 0.0000350secs]90010.628: [CMS (concurrent mode failure)[Unloadingclass sun.reflect.]
[Unloading class sun.reflect.]
[Unloading class sun.reflect.]
[Unloading class sun.reflect.]
[Unloading class sun.reflect.]
[Unloading class sun.reflect.]
[Unloading class sun.reflect.]
: 521446K->415777K(1048576K), 2.2550270 secs] 783206K->415777K(1310528K),2.2553820 secs]
90015.099: [GC 90015.099: [ParNew: 261760K->0K(261952K), 0.0198180 secs]677537K->418003K(1310528K), 0.0200650 secs]
90018.670: [GC 90018.670: [ParNew: 261760K->0K(261952K), 0.0131610 secs]679763K->419115K(1310528K), 0.0133750 secs]
90022.254: [GC 90022.254: [ParNew: 261760K->0K(261952K), 0.0151240 secs]680875K->420505K(1310528K), 0.0154180 secs]
當時的JVM參數如下：
-server -Xms1280m -Xmx1280m -Xmn256m -Xss256k -XX:PermSize=128m-XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC-XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled-XX:+DisableExplicitGC -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
因為配置了+CMSClassUnloadingEnabled參數，所以出現Unloading classsun.reflect.的日誌，這是個好習慣，如果空間不夠時可以卸載類來釋放空間，以進行FULL GC，相反，如果gc日誌中出現了此日誌，應該檢查各代的大小設置是否合理。這里應用從啟動到上述現象出現時還沒有進行過CMS GC，出現concurrent modefailure現象的原因是年輕代GC（ParNew），年老代所剩下的空間不足以滿足年輕代，也就是開頭提到的原因二。要避免此現象，方法一是降低觸發CMS的閥值，即參數-XX:的值，默認值是68，所以這里調低到50，讓CMS GC盡早執行，以保證有足夠的空間，如下：
-server -Xms1280m -Xmx1280m -Xmn256m -Xss256k -XX:PermSize=128m-XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC-XX:CMSFullGCsBeforeCompaction=1 -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly -XX:=50-XX:+CMSClassUnloadingEnabled -XX:+DisableExplicitGC -verbose:gc-XX:+PrintGCDetails -XX:+PrintGCTimeStamps
調完之後發現還是一樣的現象（這里有點不是很明白，年老代空間為1024m（1280m-256m），50%時觸發CMS GC，也就是在年老代512m的時候，剩下的堆空間有512m，就算年輕代全部裝進去應該也是夠的）,所以懷疑是年輕代太大，有大的對象，在年老代有碎片的情況下將很難分配，所以有了第二個解決辦法，即減少年輕代大小，避免放入年老代時需要分配大的空間，同時調整full gc時壓縮碎片的頻次，減少持久代大小，以及將觸發CMS GC的閥值適當增大（因為年輕代小了，這個調大點沒關系，後面可以再調試這個參數），參數如下：
-server -Xms1280m -Xmx1280m -Xmn128m -Xss256k -XX:PermSize=96m -XX:MaxPermSize=96m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSFullGCsBeforeCompaction=1 -XX:+UseCMSCompactAtFullCollection -XX:+CMSParallelRemarkEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:=70 -XX:+CMSClassUnloadingEnabled -XX:+DisableExplicitGC -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
調整完後沒有那個現象了，這里主要起作用的就是調小年輕代大小。在年老代到達826m(觸發CMS閥值(1280-128)*0.7=806m)時出現了CMS GC，用時27ms，日誌如下：
705.444: [GC 705.445: [ParNew: 130944K->0K(131008K), 0.0197680 secs]954628K->826284K(1310656K), 0.0199720 secs]
705.467:[GC [1 CMS-initial-mark: 826284K(1179648K)] 826744K(1310656K), 0.0271540 secs]
705.494:[CMS-concurrent-mark-start]
706.717:[CMS-concurrent-mark: 1.223/1.223 secs]
706.717:[CMS-concurrent-preclean-start]
706.717:[CMS-concurrent-preclean: 0.000/0.000 secs]
706.742:[CMS-concurrent-abortable-preclean-start]
706.742:[CMS-concurrent-abortable-preclean: 0.000/0.000 secs]
707.067: [GC 707.067: [ParNew: 130944K->0K(131008K), 0.0160200 secs]957228K->827348K(1310656K), 0.0162110 secs]
707.796: [GC[YG occupancy: 66671 K (131008 K)]707.796: [Rescan (parallel) ,0.0278280 secs]707.824: [weak refs processing, 0.0420770 secs] [1 CMS-remark:827348K(1179648K)] 894019K(1310656K), 0.0711970 secs]
707.877: [CMS-concurrent-sweep-start]
708.453: [GC 708.454: [ParNew: 130944K->0K(131008K), 0.0203760 secs]848439K->718796K(1310656K), 0.0205780 secs]
709.833: [GC 709.833: [ParNew: 130944K->0K(131008K), 0.0160170 secs]430484K->301411K(1310656K), 0.0161840 secs]
709.916: [CMS-concurrent-sweep: 1.974/2.040 secs]
709.916: [CMS-concurrent-reset-start]
709.951: [CMS-concurrent-reset: 0.034/0.034 secs]
711.187: [GC 711.187: [ParNew: 130944K->0K(131008K), 0.0130890 secs]413136K->283326K(1310656K), 0.0132600 secs]
觀察一段時間的gc情況，gc效率也很高，單次YGCT<20ms，FGCT <40ms：
$ jstat -gcutil 31935 1000
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 0.00 64.29 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.33 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.41 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.45 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.49 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.58 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.63 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.69 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.72 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.75 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.79 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.84 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.90 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.95 36.47 73.15 1293 19.514 6 0.211 19.725
0.00 0.00 64.99 36.47 73.15 1293 19.514 6 0.211 19.725
這時，想再測試下-XX:的值，調到80時又出現了上述現象Concurrent ModeFailure，啟動後還沒進行過CMS GC，在年老代914m時就出現了：
759.994: [GC 759.994: [ParNew: 130944K->0K(131008K), 0.0172910 secs]1040896K->911480K(1310656K), 0.0174730 secs]
760.879: [GC 760.879: [ParNew: 130944K->0K(131008K), 0.0300920 secs]1042424K->914190K(1310656K), 0.0302950 secs]
761.768: [GC 761.769: [ParNew: 130944K->130944K(131008K), 0.0000340secs]761.769: [CMS (concurrent mode failure)[Unloading classsun.reflect.GeneratedMethodAccessor342]edMethodAccessor348]
[Unloading class sun.reflect.GeneratedMethodAccessor411]
[Unloading class sun.reflect.GeneratedMethodAccessor407]
[Unloading class sun.reflect.GeneratedMethodAccessor541]
最後總結下，出現Concurrent ModeFailure現象時，解決辦法就是要讓年老代留有足夠的空間，以保證新對象空間的分配。另外在JVM BUG中有提到，JDK1.5_09版本之前，JVM參數-XX:是無效的，我這里應用環境的版本是JDK1.5_08，從gc日誌來看是可以生效的。
GC時還有一個常見的錯誤PromotionFailed，解決辦法類似，也是調整年輕代和年老代的比例，還有CMSGC的時機。

2、如何查看GC 及jvm配置

java雖然是自動回收內存，但是應用程序，尤其伺服器程序最好根據業務情況指明內存分配限制。否則可能導致應用程序宕掉。

舉例說明含義：
-Xms128m
表示JVM Heap(堆內存)最小尺寸128MB，初始分配
-Xmx512m
表示JVM Heap(堆內存)最大允許的尺寸256MB，按需分配。

說明：如果-Xmx不指定或者指定偏小，應用可能會導致java.lang.OutOfMemory錯誤，此錯誤來自JVM不是Throwable的，無法用try...catch捕捉。

PermSize和MaxPermSize指明虛擬機為java永久生成對象（Permanate generation）如，class對象、方法對象這些可反射（reflective）對象分配內存限制，這些內存不包括在Heap（堆內存）區之中。

-XX:PermSize=64MB 最小尺寸，初始分配
-XX:MaxPermSize=256MB 最大允許分配尺寸，按需分配
過小會導致：java.lang.OutOfMemoryError: PermGen space

MaxPermSize預設值和-server -client選項相關。
-server選項下默認MaxPermSize為64m
-client選項下默認MaxPermSize為32m

經驗：
1、慎用最小限制選項Xms,PermSize已節約系統資源。

=========================================================

近期研究對jvm的內存使用情況進行監控，因此對觀察虛擬機的內存使用方法做了一些收集，對jvm的參數設置了解了一下：

幾個基本概念：

PermGen space：全稱是Permanent Generation space，即永久代。就是說是永久保存的區域,用於存放Class和Meta信息，Class在被Load的時候被放入該區域，GC(Garbage Collection)應該不會對PermGen space進行清理，所以如果你的APP會LOAD很多CLASS的話，就很可能出現PermGen space錯誤。
Heap space：存放Instance。Java Heap分為3個區，Young即新生代，Old即老生代和Permanent。Young保存剛實例化的對象。當該區被填滿時，GC會將對象移到Old區。Permanent區則負責保存反射對象。

幾個參數設置的意義：

xms/xmx：定義YOUNG+OLD段的總尺寸，ms為JVM啟動時YOUNG+OLD的內存大小；mx為最大可佔用的YOUNG+OLD內存大小。在用戶生產環境上一般將這兩個值設為相同，以減少運行期間系統在內存申請上所花的開銷。
NewSize/MaxNewSize：定義YOUNG段的尺寸，NewSize為JVM啟動時YOUNG的內存大小；MaxNewSize為最大可佔用的YOUNG內存大小。在用戶生產環境上一般將這兩個值設為相同，以減少運行期間系統在內存申請上所花的開銷。
PermSize/MaxPermSize：定義Perm段的尺寸，PermSize為JVM啟動時Perm的內存大小；MaxPermSize為最大可佔用的Perm內存大小。在用戶生產環境上一般將這兩個值設為相同，以減少運行期間系統在內存申請上所花的開銷。
SurvivorRatio：設置YOUNG代中Survivor空間和Eden空間的比例

申請一塊內存的過程：

A. JVM會試圖為相關Java對象在Eden中初始化一塊內存區域
B. 當Eden空間足夠時，內存申請結束。否則到下一步
C. JVM試圖釋放在Eden中所有不活躍的對象（這屬於1或更高級的垃圾回收）；釋放後若Eden空間仍然不足以放入新對象，則試圖將部分Eden中活躍對象放入Survivor區/OLD區
D. Survivor區被用來作為Eden及OLD的中間交換區域，當OLD區空間足夠時，Survivor區的對象會被移到Old區，否則會被保留在Survivor區
E. 當OLD區空間不夠時，JVM會在OLD區進行完全的垃圾收集（0級）
F. 完全垃圾收集後，若Survivor及OLD區仍然無法存放從Eden復制過來的部分對象，導致JVM無法在Eden區為新對象創建內存區域，則出現」out of memory錯誤」

我們的一種resin伺服器的jvm參數設置：

「-Xmx2000M -Xms2000M -Xmn500M -XX:PermSize=250M -XX:MaxPermSize=250M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:=60 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log」

是一種典型的響應時間優先型的配置。

Java中有四種不同的回收演算法，對應的啟動參數為
–XX:+UseSerialGC
–XX:+UseParallelGC
–XX:+UseParallelOldGC
–XX:+UseConcMarkSweepGC

1. Serial Collector
大部分平台或者強制 java -client 默認會使用這種。
young generation演算法 = serial
old generation演算法 = serial (mark-sweep-compact)
這種方法的缺點很明顯，stop-the-world, 速度慢。伺服器應用不推薦使用。

2. Parallel Collector
在linux x64上默認是這種，其他平台要加 java -server 參數才會默認選用這種。
young = parallel，多個thread同時copy
old = mark-sweep-compact = 1
優點：新生代回收更快。因為系統大部分時間做的gc都是新生代的，這樣提高了throughput(cpu用於非gc時間)
缺點：當運行在8G/16G server上old generation live object太多時候pause time過長

3. Parallel Compact Collector (ParallelOld)
young = parallel = 2
old = parallel，分成多個獨立的單元，如果單元中live object少則回收，多則跳過
優點：old old generation上性能較 parallel 方式有提高
缺點：大部分server系統old generation內存佔用會達到60%-80%, 沒有那麼多理想的單元live object很少方便迅速回收，同時compact方面開銷比起parallel並沒明顯減少。

4. Concurent Mark-Sweep(CMS) Collector
young generation = parallel collector = 2
old = cms
同時不做 compact 操作。
優點：pause time會降低, pause敏感但CPU有空閑的場景需要建議使用策略4.
缺點：cpu佔用過多，cpu密集型伺服器不適合。另外碎片太多，每個object的存儲都要通過鏈表連續跳n個地方，空間浪費問題也會增大。

內存監控的方法：

1. jmap -heap pid
查看java 堆（heap）使用情況

using thread-local object allocation.
Parallel GC with 4 thread(s) //GC 方式

Heap Configuration: //堆內存初始化配置
MinHeapFreeRatio=40 //對應jvm啟動參數-XX:MinHeapFreeRatio設置JVM堆最小空閑比率(default 40)
MaxHeapFreeRatio=70 //對應jvm啟動參數 -XX:MaxHeapFreeRatio設置JVM堆最大空閑比率(default 70)
MaxHeapSize=512.0MB //對應jvm啟動參數-XX:MaxHeapSize=設置JVM堆的最大大小
NewSize = 1.0MB //對應jvm啟動參數-XX:NewSize=設置JVM堆的『新生代』的默認大小
MaxNewSize =4095MB //對應jvm啟動參數-XX:MaxNewSize=設置JVM堆的『新生代』的最大大小
OldSize = 4.0MB //對應jvm啟動參數-XX:OldSize=<value>:設置JVM堆的『老生代』的大小
NewRatio = 8 //對應jvm啟動參數-XX:NewRatio=:『新生代』和『老生代』的大小比率
SurvivorRatio = 8 //對應jvm啟動參數-XX:SurvivorRatio=設置年輕代中Eden區與Survivor區的大小比值
PermSize= 16.0MB //對應jvm啟動參數-XX:PermSize=<value>:設置JVM堆的『永生代』的初始大小
MaxPermSize=64.0MB //對應jvm啟動參數-XX:MaxPermSize=<value>:設置JVM堆的『永生代』的最大大小

Heap Usage: //堆內存分步
PS Young Generation
Eden Space: //Eden區內存分布
capacity = 20381696 (19.4375MB) //Eden區總容量
used = 20370032 (19.426376342773438MB) //Eden區已使用
free = 11664 (0.0111236572265625MB) //Eden區剩餘容量
99.94277218147106% used //Eden區使用比率
From Space: //其中一個Survivor區的內存分布
capacity = 8519680 (8.125MB)
used = 32768 (0.03125MB)
free = 8486912 (8.09375MB)
0.38461538461538464% used
To Space: //另一個Survivor區的內存分布
capacity = 9306112 (8.875MB)
used = 0 (0.0MB)
free = 9306112 (8.875MB)
0.0% used
PS Old Generation //當前的Old區內存分布
capacity = 366280704 (349.3125MB)
used = 322179848 (307.25464630126953MB)
free = 44100856 (42.05785369873047MB)
87.95982001825573% used
PS Perm Generation //當前的「永生代」內存分布
capacity = 32243712 (30.75MB)
used = 28918584 (27.57891082763672MB)
free = 3325128 (3.1710891723632812MB)
89.68751488662348% used

=====================================================================

jps
-q只輸出進程ID，而不輸出類的短名稱
-m用於輸出傳遞給Java進程（主函數）的參數
-l完整路徑
-v顯示傳遞給jvm的參數

3、phpcms v9錯誤日誌記錄怎樣清理

直接刪除error_log.php文件就可以了

4、如何查看GC 及jvm配置？

5、帝國cms的logfiles在什麼目錄下

帝國程序沒有logfiles這個文件夾或者文件，你自己下載帝國程序解壓後F3搜索下就知道了，是不是你自己建的欄目目錄是logfiles，如果是你自己應該知道，如果不是的話，非常肯定的告訴你帝國cms沒有帶這個文件或者文件夾

6、網站優化怎麼分析網站日誌帝國cms

其實分析網站的日誌作用不是非常的大，想要把網站優化好還是要做內鏈和外鏈的

7、如何刪除PHPCMS後台操作日誌?緊急!!!

登陸PHPcms後台，擴展，後台日誌管理，然後刪除一個月前的，或者你到文件裡面找到log文件進行刪除

8、蘋果飛飛 cms Linux 網站日誌在哪裡看

可以在cms所在安裝目錄搜索 log字樣文件
如
find cms -name 「*·log」

9、CMS GC會不會回收Direct ByteBuffer的內存

Oracle JDK 6u32前的版本不會。

Direct ByteBuffer是在Java Heap外分配內存，NIO等東西里使用的比較多，但Direct ByteBuffer分配出去的內存其實也是由GC負責回收的，而不像之前一篇文章里的Unsafe是完全自行管理的，Hotspot在GC時會掃描Direct ByteBuffer對象是否有引用，如沒有則同時也會回收其佔用的堆外內存，但不幸的是在6u32前的版本里，CMS GC有bug會導致可能回收不掉，具體的bug id為 7112034 ，在鏈接的Backport信息里，可以看到這個bug是在hotspot 20.7的版本里修復的（hotspot的版本號通過java -version的最後一行Java Hotspot Version之類的可以看到），6u32帶的就是這個版本，所以6u32是會回收的。

回收不掉的情況下會造成的問題是明明已經不用了，但堆外內存仍然被消耗掉，悲慘的情況下可能會導致堆外內存耗光。

Direct ByteBuffer除了上面這個bug可能造成堆外內存耗光外，還有一種場景也可能會造成堆外內存耗光，如Direct ByteBuffer對象晉升到了Old區，那這個時候就只能等Full GC觸發（CMS GC的情況下等CMS GC），因此在Direct ByteBuffer使用較多，存活時間較長的情況下，有可能會導致堆外內存耗光（因為Direct ByteBuffer本身對象所佔用的空間是很小的）。

對於上面這種類型的應用，最好是在啟動參數上增加-XX:MaxDirectMemorySize=x[m|g]，例如-XX:MaxDirectMemorySize=500m

這個參數默認的大小是-Xmx的值（在沒設置MaxDirectMemorySize參數的情況下，用jinfo -flag等方式會看到默認值是-1，但VM.maxDirectMemory這個方法里發現是-1，則會以-Xmx作為默認值），此參數的含義是當Direct ByteBuffer分配的堆外內存到達指定大小後，即觸發Full GC（這段邏輯請見Bits.reserveMemory的代碼），如Full GC後仍然分配不出Direct ByteBuffer需要的空間，則會報OOM錯誤：
java.lang.OutOfMemoryError: Direct buffer memory

因為上面所說的狀況，如碰到堆外內存佔用較多的場景，可以嘗試強制執行Full GC（強制的方法為執行jmap -histo:live）看看，多執行一兩次，如堆外內存下降的話，很有可能就是Direct ByteBuffer造成的，對於這種情況，通常加上上面的啟動參數就可解決。

10、cms gc過程中哪幾個階段暫停應用程序

問題解決：中間調整過幾次，先搞了幾台機器做了驗證，後來逐步推廣的。
1、調大heap區，由原來的4g，調整到5g，young區的大小不變，還是2g，這時候old區就由2g變為3g了（這樣保證old區有足夠的空間）；
2、設置-XX：UseCMSInitiatingOccupancyOnly，其實這個不關這個問題，只是發現半夜CMS進行的有點頻繁，就禁止掉了悲觀策略；
3、設置CMS區回收的比例，從80%調整到75%，讓old區盡早的進行，有足夠的空間剩餘；

為什麼要有GC（垃圾回收）？

JVM通過GC來回收堆和方法區中的內存，GC的基本原理就是找到程序中不再被使用的對象，然後回收掉這些對象佔用的內存。

導航:首頁 > 萬維百科 > CMSgc日誌

CMSgc日誌

與CMSgc日誌相關的知識