gc引數設定錯誤導致一直full gc

阿新 • • 發佈：2019-01-29

gc param


JAVA_OPTS="${JAVA_OPTS} -Xms1g -Xmx1g -XX:NewSize=512m -XX:MaxNewSize=1g  -Xss512k -XX:SurvivorRatio=6"
JAVA_OPTS="${JAVA_OPTS} -XX:PermSize=128m -XX:MaxPermSize=256m"
JAVA_OPTS="${JAVA_OPTS} -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80" 

JAVA_OPTS="${JAVA_OPTS} -XX:+DisableExplicitGC"
JAVA_OPTS="${JAVA_OPTS} -XX:+HeapDumpOnOutOfMemoryError"
JAVA_OPTS="${JAVA_OPTS} -verbose:gc -Xloggc:$BASE_DIR/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps"
JAVA_OPTS="${JAVA_OPTS} -XX:+DoEscapeAnalysis"

現象

啟動一段時間後full gc 非常多，並且一直full gc,cpu佔用較高

jstat -gcutil 6740 1s

  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
  0.00   0.00  36.72  99.79  44.48    149    3.693  7155 2914.767 2918.460
  0.00   0.00  36.74  99.79  44.48    149    3.693  7157 2915.111 2918.804
  0.00   0.00  37.15  99.79  44.48    149    3.693  7157 2915.474 2919.167 

  0.00   0.00  37.17  99.79  44.48    149    3.693  7157 2915.474 2919.167
  0.00   0.00  37.17  99.79  44.48    149    3.693  7159 2915.794 2919.487
  0.00   0.00  37.20  99.79  44.48    149    3.693  7159 2916.166 2919.859
  0.00   0.00  37.20  99.79  44.48    149    3.693  7159 2916.166 2919.859

老年代利用率99.79%

Full gc 非常多：7159

jmap -heap 6740

Attaching to process ID 6740, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.80-b11

using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC

Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize      = 1073741824 (1024.0MB)
   NewSize          = 536870912 (512.0MB)
   MaxNewSize       = 1073741824 (1024.0MB)
   OldSize          = 5439488 (5.1875MB)
   NewRatio         = 2
   SurvivorRatio    = 6
   PermSize         = 134217728 (128.0MB)
   MaxPermSize      = 268435456 (256.0MB)
   G1HeapRegionSize = 0 (0.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
   capacity = 939524096 (896.0MB)
   used     = 324895744 (309.8447265625MB)
   free     = 614628352 (586.1552734375MB)
   34.580884660993306% used
Eden Space:
   capacity = 805371904 (768.0625MB)
   used     = 324895744 (309.8447265625MB)
   free     = 480476160 (458.2177734375MB)
   40.34108247212955% used
From Space:
   capacity = 134152192 (127.9375MB)
   used     = 0 (0.0MB)
   free     = 134152192 (127.9375MB)
   0.0% used
To Space:
   capacity = 134152192 (127.9375MB)
   used     = 0 (0.0MB)
   free     = 134152192 (127.9375MB)
   0.0% used
concurrent mark-sweep generation:
   capacity = 65536 (0.0625MB)
   used     = 65400 (0.06237030029296875MB)
   free     = 136 (1.2969970703125E-4MB)
   99.79248046875% used
Perm Generation:
   capacity = 134217728 (128.0MB)
   used     = 59700376 (56.934715270996094MB)
   free     = 74517352 (71.0652847290039MB)
   44.4802463054657% used

21022 interned Strings occupying 2161776 bytes.

老年代配置太小：5.1875M

gc.log

CommandLine flags: -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+DisableExplicitGC -XX:+DoEscapeAnalysis -XX:+HeapDumpOnOutOfMemoryError -XX:InitialHeapSize=1073741824 -XX:MaxHeapSize=1073741824 -XX:MaxNewSize=1073741824 -XX:MaxPermSize=268435456 -XX:NewSize=536870912 -XX:OldPLABSize=16 -XX:PermSize=134217728 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:SurvivorRatio=6 -XX:ThreadStackSize=512 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseParNewGC 
2017-05-02T16:52:06.943-0800: 13.247: [GC2017-05-02T16:52:06.943-0800: 13.247: [ParNew: 786496K->31371K(917504K), 0.0725850 secs] 786496K->31371K(917568K), 0.0727990 secs] [Times: user=0.13 sys=0.02, real=0.07 secs] 
2017-05-02T16:52:31.607-0800: 37.910: [GC2017-05-02T16:52:31.609-0800: 37.912: [ParNew: 817867K->46918K(917504K), 0.2479520 secs] 817867K->46918K(917568K), 0.2501410 secs] [Times: user=0.23 sys=0.15, real=0.25 secs] 
2017-05-02T16:56:01.853-0800: 248.156: [GC2017-05-02T16:56:01.855-0800: 248.158: [ParNew: 833414K->41409K(917504K), 0.0957810 secs] 833414K->41409K(917568K), 0.0979290 secs] [Times: user=0.17 sys=0.12, real=0.10 secs] 
2017-05-02T16:57:14.966-0800: 321.270: [GC2017-05-02T16:57:14.968-0800: 321.271: [ParNew: 827905K->40734K(917504K), 0.0534460 secs] 827905K->40734K(917568K), 0.0554990 secs] [Times: user=0.16 sys=0.03, real=0.06 secs] 
2017-05-02T16:58:28.893-0800: 395.197: [GC2017-05-02T16:58:28.895-0800: 395.198: [ParNew: 827230K->42165K(917504K), 0.0903920 secs] 827230K->42165K(917568K), 0.0916100 secs] [Times: user=0.17 sys=0.01, real=0.09 secs] 
2017-05-02T16:59:44.275-0800: 470.578: [GC2017-05-02T16:59:44.277-0800: 470.580: [ParNew: 828661K->42810K(917504K), 0.0520530 secs] 828661K->42810K(917568K), 0.0541480 secs] [Times: user=0.15 sys=0.01, real=0.05 secs] 
2017-05-02T17:01:02.837-0800: 549.140: [GC2017-05-02T17:01:02.839-0800: 549.142: [ParNew: 829306K->42849K(917504K), 0.1528770 secs] 829306K->42849K(917568K), 0.1548970 secs] [Times: user=0.19 sys=0.19, real=0.16 secs] 
2017-05-02T17:02:21.761-0800: 628.065: [GC2017-05-02T17:02:21.763-0800: 628.067: [ParNew: 829345K->42779K(917504K), 0.0484280 secs] 829345K->42779K(917568K), 0.0504720 secs] [Times: user=0.16 sys=0.02, real=0.05 secs] 
2017-05-02T17:03:41.109-0800: 707.413: [GC2017-05-02T17:03:41.111-0800: 707.415: [ParNew: 829275K->42570K(917504K), 0.0451940 secs] 829275K->42570K(917568K), 0.0472230 secs] [Times: user=0.16 sys=0.00, real=0.05 secs] 
2017-05-02T17:04:59.543-0800: 785.846: [GC2017-05-02T17:04:59.545-0800: 785.848: [ParNew: 829066K->35805K(917504K), 0.0540570 secs] 829066K->35805K(917568K), 0.0560790 secs] [Times: user=0.17 sys=0.01, real=0.05 secs] 
2017-05-02T17:06:19.281-0800: 865.585: [GC2017-05-02T17:06:19.283-0800: 865.587: [ParNew: 822301K->43009K(917504K), 0.0664980 secs] 822301K->43009K(917568K), 0.0687660 secs] [Times: user=0.16 sys=0.02, real=0.07 secs] 
2017-05-02T17:07:40.577-0800: 946.881: [GC2017-05-02T17:07:40.579-0800: 946.883: [ParNew: 829505K->35695K(917504K), 0.0500640 secs] 829505K->35695K(917568K), 0.0522790 secs] [Times: user=0.16 sys=0.01, real=0.06 secs] 
2017-05-02T17:09:01.660-0800: 1027.964: [GC2017-05-02T17:09:01.662-0800: 1027.965: [ParNew: 822191K->35550K(917504K), 0.0462440 secs] 822191K->35550K(917568K), 0.0482520 secs] [Times: user=0.15 sys=0.01, real=0.04 secs] 
2017-05-02T17:10:23.692-0800: 1109.995: [GC2017-05-02T17:10:23.694-0800: 1109.997: [ParNew: 822046K->35915K(917504K), 0.0474050 secs] 822046K->35915K(917568K), 0.0496640 secs] [Times: user=0.15 sys=0.00, real=0.05 secs] 
2017-05-02T17:11:45.330-0800: 1191.634: [GC2017-05-02T17:11:45.332-0800: 1191.636: [ParNew: 822411K->39798K(917504K), 0.0438740 secs] 822411K->39798K(917568K), 0.0460200 secs] [Times: user=0.15 sys=0.00, real=0.04 secs] 
2017-05-02T17:20:13.443-0800: 1699.747: [GC2017-05-02T17:20:13.444-0800: 1699.747: [ParNew (promotion failed): 826294K->819078K(917504K), 2.5235450 secs]2017-05-02T17:20:15.967-0800: 1702.271: [CMS: 50K->63K(64K), 0.4754080 secs] 826294K->25600K(917568K), [CMS Perm : 58218K->57910K(131072K)], 3.0024250 secs] [Times: user=1.93 sys=1.58, real=3.00 secs] 
2017-05-02T17:20:16.452-0800: 1702.755: [GC [1 CMS-initial-mark: 63K(64K)] 25845K(917568K), 0.0516520 secs] [Times: user=0.04 sys=0.00, real=0.05 secs] 
2017-05-02T17:20:16.504-0800: 1702.808: [CMS-concurrent-mark-start]
2017-05-02T17:20:16.638-0800: 1702.942: [CMS-concurrent-mark: 0.131/0.134 secs] [Times: user=0.07 sys=0.01, real=0.13 secs] 
2017-05-02T17:20:16.639-0800: 1702.942: [CMS-concurrent-preclean-start]
2017-05-02T17:20:16.683-0800: 1702.986: [CMS-concurrent-preclean: 0.044/0.044 secs] [Times: user=0.03 sys=0.00, real=0.05 secs] 
2017-05-02T17:20:16.683-0800: 1702.986: [CMS-concurrent-abortable-preclean-start]
2017-05-02T17:20:16.683-0800: 1702.986: [CMS-concurrent-abortable-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2017-05-02T17:20:16.683-0800: 1702.987: [GC[YG occupancy: 33450 K (917504 K)]2017-05-02T17:20:16.683-0800: 1702.987: [Rescan (parallel) , 0.0393800 secs]2017-05-02T17:20:16.723-0800: 1703.026: [weak refs processing, 0.0002250 secs]2017-05-02T17:20:16.723-0800: 1703.026: [class unloading, 0.0066750 secs]2017-05-02T17:20:16.730-0800: 1703.033: [scrub symbol table, 0.0173430 secs]2017-05-02T17:20:16.747-0800: 1703.050: [scrub string table, 0.0008670 secs] [1 CMS-remark: 63K(64K)] 33514K(917568K), 0.0677130 secs] [Times: user=0.12 sys=0.01, real=0.07 secs] 
2017-05-02T17:20:16.751-0800: 1703.055: [CMS-concurrent-sweep-start]
2017-05-02T17:20:16.763-0800: 1703.067: [CMS-concurrent-sweep: 0.012/0.012 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
2017-05-02T17:20:16.764-0800: 1703.067: [CMS-concurrent-reset-start]
2017-05-02T17:20:16.764-0800: 1703.067: [CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2017-05-02T17:20:18.766-0800: 1705.069: [GC [1 CMS-initial-mark: 63K(64K)] 44182K(917568K), 0.0303270 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 
2017-05-02T17:20:18.797-0800: 1705.100: [CMS-concurrent-mark-start]
2017-05-02T17:20:18.830-0800: 1705.134: [CMS-concurrent-mark: 0.034/0.034 secs] [Times: user=0.03 sys=0.00, real=0.04 secs] 
2017-05-02T17:20:18.831-0800: 1705.134: [CMS-concurrent-preclean-start]
2017-05-02T17:20:18.831-0800: 1705.134: [CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2017-05-02T17:20:18.831-0800: 1705.134: [CMS-concurrent-abortable-preclean-start]
2017-05-02T17:20:18.831-0800: 1705.134: [CMS-concurrent-abortable-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
2017-05-02T17:20:18.831-0800: 1705.135: [GC[YG occupancy: 44172 K (917504 K)]2017-05-02T17:20:18.831-0800: 1705.135: [Rescan (parallel) , 0.0351060 secs]2017-05-02T17:20:18.866-0800: 1705.170: [weak refs processing, 0.0001470 secs]2017-05-02T17:20:18.867-0800: 1705.170: [class unloading, 0.0044870 secs]2017-05-02T17:20:18.871-0800: 1705.174: [scrub symbol table, 0.0142320 secs]2017-05-02T17:20:18.885-0800: 1705.189: [scrub string table, 0.0007320 secs] [1 CMS-remark: 63K(64K)] 44236K(917568K), 0.0575210 secs] [Times: user=0.15 sys=0.00, real=0.05 secs] 
2017-05-02T17:20:18.889-0800: 1705.192: [CMS-concurrent-sweep-start]
2017-05-02T17:20:18.899-0800: 1705.203: [CMS-concurrent-sweep: 0.010/0.010 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
2017-05-02T17:20:18.900-0800: 1705.203: [CMS-concurrent-reset-start]
2017-05-02T17:20:18.900-0800: 1705.203: [CMS-concurrent-reset: 0.001/0.001 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

解決辦法

修改gc記憶體引數，減小新生代大小，加大old區大小

JAVA_OPTS="${JAVA_OPTS} -Xms1g -Xmx1g -XX:NewSize=512m -XX:MaxNewSize=512m  -Xss512k -XX:SurvivorRatio=6"

總結

gc引數配置不當，導致old太小，最終導致一直full gc。

如何確定新老年代的記憶體大小，看起來很複雜，有知道的煩請分享一下。

gc引數設定錯誤導致一直full gc

gc param JAVA_OPTS="${JAVA_OPTS} -Xms1g -Xmx1g -XX:NewSize=512m -XX:MaxNewSize=1g -Xss512k -XX:SurvivorRatio=6" JAVA_OPTS="${J

集合未分頁處理導致的full-gc

參考文獻：戰小狼:OMG！又一個頻繁FullGC的案例； jdk8下進行的，jdk11不存在此案例問題。 1. 問題集合持有的x物件不能被young-gc，從而晉升到old區導致full-gc。因此可以設定閾值在年輕代佔滿之前釋放掉x物件——可被young-gc掉。錯誤程式碼

JVM gc引數設定與分析

原文：概述 java的最大好處是自動垃圾回收，這樣就無需我們手動的釋放物件空間了，但是也產生了相應的負效果，gc是需要時間和資源的，不好的gc會嚴重影響系統的系能，因此良好的gc是JVM的高效能的保證。JVM堆分為新生代，舊生代和年老代，新生代可用的gc方式有：序列

故障分析：核心引數設定不當導致資料庫異常重啟

編輯手記：資料庫中每一個不起眼的引數，都有其內部的原理，不可隨意更改。今天分享一則因核心引數SEMOPM設定太小，加上在業務高併發時段LGWR寫入太慢，系統呼叫失敗，最終資料庫異常宕機的案例。故障現象資料庫CRASH，在CRASH前，ALERT中顯示如下的日誌內容我們看到中間有27300和2

JVM頻繁Full GC導致服務不可用定位過程

背景：公司推行微服務策略，我負責的XX模組相對於其他業務來講相對獨立，所以作為微服務推行的試點。於是分析業務邊界；做相關的架構升級：從Spring3.X升級到Spring5.X（引入了SpringBoot2.0）從JDK7升級到JDK8（老年代

效能案例-JVM頻繁full GC 問題（JVM引數優化）

說明：這個是兩三年前的一個案例，剛剛新開發的服務，jdk版本為1.71、問題描述：某服務執行緒十幾分鍾就出現一次full GC現象，需要優化（其他4個服務也存在類似問題）2、問題原因：jvm 永久帶未配置（預設值過小）3、測試過程：以xx_core_service-1.0.0

BM、GC、SGBM三種演算法的比較和BM在OpenCV3下的引數設定

第一部分BM、GC和SGBM演算法的效能比較轉自：http://blog.csdn.net/chenyusiyuan/article/details/5967291，其中原博主推薦的Stefano Mattoccia大神的講義Stereo Vision：

Full GC

onf 5.0 並發 net 滿了執行c 發的 cms gc 反射 1，新生代：（1）所有對象創建在新生代的Eden區，當Eden區滿後觸發新生代的Minor GC，將Eden區和非空閑Survivor區存活的對象復制到另外一個空閑的Survivor區中。（2）保證一個S

full GC觸發的條件

錯誤 failure tab 大於 lur vivo abort mar 進行 full GC觸發的條件除直接調用System.gc外，觸發Full GC執行的情況有如下四種。1. 舊生代空間不足舊生代空間只有在新生代對象轉入及創建為大對象、大數組時才會出現不足的現象，當執

full gc頻繁的分析及解決案例

過大 heap times 正常的出現結構 lec 收集器 max full gc頻繁的分析及解決案例2016-04-14 09:20:54 0個評論來源：end‘s coding life 收藏我要投稿現象 ? 1

可怕的Full GC （轉自Hbase不睡覺書）

一個 size 常見美麗 blank 到來開發 htm 直接 PS：之前做項目的時候，需要做個復雜的查詢，大量的查詢總是導致hbase集群奔潰，最後定位到時full GC的原因。以下轉自《Hbase不睡覺書》------------------------ 可怕的Fu

jvm：觸發JVM進行Full GC的情況及應對策略

堆記憶體劃分為 Eden、Survivor 和 Tenured/Old 空間，如下圖所示：從年輕代空間（包括 Eden 和 Survivor 區域）回收記憶體被稱為 Minor GC，對老年代GC稱為Major GC,而Full GC是對整個堆來說的，在最近幾個版本的JDK裡預設包括了對永生帶

JVM菜鳥進階高手之路六（JVM每隔一小時執行一次Full GC）

JVM菜鳥進階高手之路六（JVM每隔一小時執行一次Full GC）轉載請註明原創出處，謝謝！上次分析詳細地址在：http://www.cnblogs.com/lirenzuo/p/7531700.html 以為上次問題是rmi的問題就此結束了，但是問題並沒有結束，其實本次問

MySQL wait_timeout引數設定與網上常見錯誤小糾

discard connection com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure The last packet successfully receive

Minor GC 和 Major GC / Full GC

新生代 GC ( Minor GC ) ：指發生在新生代的垃圾收集動作，因為 Java 物件大多都具備朝生夕滅的特性，所以 Minor GC 非常頻繁，一般回收速度也比較快。老年代 GC ( Major GC / Full GC ) ：指發

JIRA應用的記憶體引數設定不當+容器沒有對資源進行限制導致服務掛掉的例子

背景: 應用的部署結構是這樣的:使用rancher管理的Docker叢集,有三臺物理主機,二十多個Docker容器, 提供的功能是問題跟蹤(JIRA),文件管理(Confluence),程式碼託管(svn,gitlab),持續整合(jenkins,gitlab-ci + Docker),程式碼質量管理(Son

解決 Flask 專案無法用 .env 檔案中解析的引數設定環境變數的錯誤

在 Windows 上啟動 Flask 專案時，工作目錄有 UTF-8 編碼的 .env 檔案，裡面配置的環境變數在 Python2 中識別為 Unicode 型別，導致下述錯誤： * Serving Flask app "bootstrap" (lazy loading) * Environme

虛擬機器塊裝置掛載引數錯誤導致無法開機問題處理

故障現象給虛擬機器增加一個卷後，重啟無法進入系統。故障原因 /etc/fstab中填寫的檔案系統型別與分割槽實際檔案系統不一致。處理方法將虛擬機器系統卷掛載到其他虛擬機器上，修改/etc/fstab為正確配置。排查過程同事給一臺虛擬機器

(轉載)一次生產系統 Full GC 問題分析與排查總結

一次生產系統 Full GC 問題分析與排查總結轉載請註明 AIQ - 最專業的機器學習大資料社群 http://www.6aiq.com AIQ 機器學習大資料知乎專欄點選關注一次生產系統 Full GC 問題分

Java虛擬機器7：記憶體溢位和記憶體洩露、並行和併發、Minor GC和Full GC、Client模式和Server模式的區別

記憶體溢位和記憶體洩露的區別 1、記憶體溢位記憶體溢位指的是程式在申請記憶體的時候，沒有足夠大的空間可以分配了。 2、記憶體洩露記憶體洩露指的是程式在申請記憶體之後，沒有辦法釋放掉已經申請到記憶體，它始終佔用著記憶體，即被分配的物件可達但無用。記憶體洩露一般都是因

gc引數設定錯誤導致一直full gc

gc param

現象

jstat -gcutil 6740 1s

jmap -heap 6740

gc.log

解決辦法

總結

相關推薦