摘要:服務是通過進行反向代理的,設置的超時時間是,所以如果卡頓在以內就不會對成功率造成太大的影響。
本文介紹了一次生產環(huán)境的JVM GC相關參數(shù)的調優(yōu)過程,通過參數(shù)的調整避免了GC卡頓對JAVA服務成功率的影響
背景以及遇到的問題我們的Java HTTP服務屬于OLTP類型,對成功率和響應時間的要求比較高,在生產環(huán)境中出現(xiàn)偶現(xiàn)的成功率突然下降然后又自動恢復的情況,如圖所示:
JVM和GC相關的參數(shù)如下:
-Xmx22528m -Xms22528m -XX:NewRatio=2 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled
總結來說,由于服務中大量使用了Cache,所以堆大小開到了22G。GC算法使用CMS(UseConcMarkSweepGC),開啟了降低標記停頓(CMSParallelRemarkEnabled),設置年輕代為并行收集(UseParNewGC),年輕代和老年代的比例為1:2 (NewRatio=2).
JVM GC日志相關的參數(shù)如下:
-Xloggc:/data/gc.log -XX:GCLogFileSize=10M -XX:NumberOfGCLogFiles=10 -XX:+UseGCLogFileRotation -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+DisableExplicitGC -verbose:gc問題解決過程 排除應用程序的內存使用問題
首先使用jmap查看內存使用情況:
jmap -histo:live PID
這個命令把程序中當前的對象按照個數(shù)和占用的空間排序以后打印出來。這里沒有發(fā)現(xiàn)使用異常的對象。
排除Cache內容過多的問題如果Cache內容過多也會導致JVM老年代容易被用滿導致頻繁GC,因此調出GC日志進行查看,發(fā)現(xiàn)每次GC以后內存使用一般是從20G降低到5G左右,因此常駐內存的Cache不是導致GC長時間卡頓的根本原因。對于GC LOG的查看有多種方式,使用VisualVM比較直觀,需要安裝VisualGC插件:
從圖中我們可以看到伊甸園和老年代的空間分配,由于整體內存是20G,設置 -XX:NewRatio=2 因此老年代是14G,伊甸園+S0+S1=7G
調整GC時間點(成功率抖動問題加重)如果GC需要處理的內存量比較大,執(zhí)行的時間也就比較長,STW (Stop the World)時間也就更長。按照這個思路調整CMS啟動的時間點,希望提早GC,也就是讓GC變得更加頻繁但是期望每次執(zhí)行的時間較少。添加了下面這兩個參數(shù):
-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=50
意思是說在Old區(qū)使用了50%的時候觸發(fā)GC。實驗后發(fā)現(xiàn)GC的頻率有所增加,但是每次GC造成的陳功率降低現(xiàn)象并沒有減弱,因此棄用這兩個參數(shù)。
調整對象在年輕代內存中駐留的時間(效果不明顯)如果能夠降低老年代GC的頻率也可以達到降低GC影響的目的,因此嘗試讓對象在年輕代內存中進行更長時間的駐留,提升這些對象在年輕代GC時候被銷毀的概率。使用參數(shù) -XX:MaxTenuringThreshold=31調整以后收效不明顯。
CMS-Remark之前強制進行年輕代的GC首先補充一下CMS的相關知識,在CMS整個過程中有兩個步驟是STW的,如圖紅色部分:
CMS并非沒有暫停,而是用兩次短暫停來替代串行標記整理算法的長暫停,它的收集周期是這樣:
初始標記(CMS-initial-mark),從root對象開始標記存活的對象
并發(fā)標記(CMS-concurrent-mark)
重新標記(CMS-remark),暫停所有應用程序線程,重新標記并發(fā)標記階段遺漏的對象(在并發(fā)標記階段結束后對象狀態(tài)的更新導致)
并發(fā)清除(CMS-concurrent-sweep)
并發(fā)重設狀態(tài)等待下次CMS的觸發(fā)(CMS-concurrent-reset)。
通過GC日志和成功率下降的時間點進行比對發(fā)現(xiàn)并不是每一次老年代GC都會導致成功率的下降,但是從中發(fā)現(xiàn)了一個規(guī)律:
前兩次GC CMS-Remark過程在4s左右造成了成功率的下降,但是第三次GC并沒有對成功率造成明顯的影響,CMS-Remark只有0.18s。Java HTTP 服務是通過Nginx進行反向代理的,nginx設置的超時時間是3s,所以如果GC卡頓在3s以內就不會對成功率造成太大的影響。
從GC日志中又發(fā)現(xiàn)一個信息:
在文檔和相關資料中沒有找到藍色部分的含義,猜測是remark處理的內存量,處理的越多就越慢。添加下面兩個參數(shù)強制在remark階段和FULL GC階段之前先在進行一次年輕代的GC,這樣需要進行處理的內存量就不會太多。
-XX:+ScavengeBeforeFullGC -XX:+CMSScavengeBeforeRemark
調優(yōu)以后效果很明顯,下面是兩臺配置完全相同的服務器在同一時間段的成功率和響應時間監(jiān)控圖,第一個沒有添加強制年輕代GC的參數(shù)。
在CMS-remark階段需要對堆中所有的內存對象進行處理,如果在這個階段之前強制執(zhí)行一次年輕代的GC會大量減少remark需要處理的內存數(shù)量,進而降低JVM卡頓對成功率的影響
對于Java HTTP服務,JVM的卡頓時間應該小于HTTP客戶端的調用超時時間,否則JVM卡頓會對成功率造成影響
參考文獻http://blog.csdn.net/historyasamirror/article/details/6245157
https://blogs.oracle.com/poonam/entry/understanding_cms_gc_logs
http://blog.sokolenko.me/2014/11/javavm-options-production.html
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/65976.html
摘要:原文鏈接本篇是專家系列的第三篇。但是,請記住調優(yōu)是不得已時的選擇。縮短耗時的單次執(zhí)行與相比,耗時有較明顯的增加。創(chuàng)建文件過程中,進程會中斷,因此不要在正常運行時系統(tǒng)上做此操作。因此校驗結果并根據(jù)具體的服務需要,決定是否要進行調優(yōu)。 原文鏈接:http://www.cubrid.org/blog/dev-platform/how-to-tune-java-garbage-collecti...
摘要:本文將介紹的參數(shù)的重要性以及在發(fā)生時對系統(tǒng)整體性能的顯著影響。我們來看下的選項在發(fā)生時會對系統(tǒng)帶來哪些影響。所以這些請求將會放到堆積隊列,隊列的長度是的中設置的。從而導致進程的數(shù)量超過,并觸發(fā)了操作系統(tǒng)進行內存交換的閥值。 原文鏈接:http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-o...
摘要:在本文中我將會介紹應用性能優(yōu)化的一般原則。性能優(yōu)化的流程圖摘取自和合著的性能,描述了應用性能優(yōu)化的處理流程。例如,對每臺服務器,你面臨著為單個分配堆內存和運行個并為每個分配堆內存的選擇。不過位能使用堆內存最大理論值只有。 原文鏈接:http://www.cubrid.org/blog/dev-platform/the-principles-of-java-application-per...
摘要:一內存調優(yōu)主要的目的是減小的頻率和的次數(shù)。調優(yōu)工具之主要用來輸出中運行的進程狀態(tài)信息。調優(yōu)工具之和用來查看堆內存使用狀況,一般結合使用。 一、jvm內存調優(yōu) 主要的...
摘要:調優(yōu)調優(yōu)中基于真實案例介紹了可用于調優(yōu)的最佳選項。的設置及其對的影響的設置及其對的影響中介紹了對選項在系統(tǒng)發(fā)生時對整體性能的影響。具體來說,我會介紹性能優(yōu)化的必要條件判斷是否需要優(yōu)化的步驟,同時也會列出在性能優(yōu)化過程中經遇到的一些問題。 1. 理解Java垃圾回收 理解Java垃圾回收中我們學習了幾種不同的GC算法的處理過程,GC的工作方式,新生代與老年代的區(qū)別。所以,你應該已經了解...
閱讀 1112·2021-09-22 15:37
閱讀 1135·2021-09-13 10:27
閱讀 2473·2021-08-25 09:38
閱讀 2449·2019-08-26 11:42
閱讀 1532·2019-08-26 11:39
閱讀 1561·2019-08-26 10:58
閱讀 2325·2019-08-26 10:56
閱讀 2573·2019-08-23 18:08