国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

Java服務(wù)GC參數(shù)調(diào)優(yōu)案例

msup / 701人閱讀

摘要：服務(wù)是通過進(jìn)行反向代理的，設(shè)置的超時(shí)時(shí)間是，所以如果卡頓在以內(nèi)就不會(huì)對(duì)成功率造成太大的影響。

本文介紹了一次生產(chǎn)環(huán)境的JVM GC相關(guān)參數(shù)的調(diào)優(yōu)過程，通過參數(shù)的調(diào)整避免了GC卡頓對(duì)JAVA服務(wù)成功率的影響

背景以及遇到的問題

我們的Java HTTP服務(wù)屬于OLTP類型，對(duì)成功率和響應(yīng)時(shí)間的要求比較高，在生產(chǎn)環(huán)境中出現(xiàn)偶現(xiàn)的成功率突然下降然后又自動(dòng)恢復(fù)的情況，如圖所示：

JVM和GC相關(guān)的參數(shù)如下：

-Xmx22528m

-Xms22528m

-XX:NewRatio=2

-XX:+UseConcMarkSweepGC

-XX:+UseParNewGC

-XX:+CMSParallelRemarkEnabled

總結(jié)來說，由于服務(wù)中大量使用了Cache，所以堆大小開到了22G。GC算法使用CMS（UseConcMarkSweepGC），開啟了降低標(biāo)記停頓（CMSParallelRemarkEnabled），設(shè)置年輕代為并行收集（UseParNewGC），年輕代和老年代的比例為1:2 （NewRatio＝2）.

JVM GC日志相關(guān)的參數(shù)如下：

-Xloggc:/data/gc.log

-XX:GCLogFileSize=10M

-XX:NumberOfGCLogFiles=10

-XX:+UseGCLogFileRotation

-XX:+PrintGCDateStamps

-XX:+PrintGCTimeStamps

-XX:+PrintGCDetails

-XX:+DisableExplicitGC

-verbose:gc
問題解決過程 排除應(yīng)用程序的內(nèi)存使用問題

首先使用jmap查看內(nèi)存使用情況：

jmap -histo:live PID

這個(gè)命令把程序中當(dāng)前的對(duì)象按照個(gè)數(shù)和占用的空間排序以后打印出來。這里沒有發(fā)現(xiàn)使用異常的對(duì)象。

排除Cache內(nèi)容過多的問題

如果Cache內(nèi)容過多也會(huì)導(dǎo)致JVM老年代容易被用滿導(dǎo)致頻繁GC，因此調(diào)出GC日志進(jìn)行查看，發(fā)現(xiàn)每次GC以后內(nèi)存使用一般是從20G降低到5G左右，因此常駐內(nèi)存的Cache不是導(dǎo)致GC長時(shí)間卡頓的根本原因。對(duì)于GC LOG的查看有多種方式，使用VisualVM比較直觀，需要安裝VisualGC插件：

從圖中我們可以看到伊甸園和老年代的空間分配，由于整體內(nèi)存是20G，設(shè)置 -XX:NewRatio=2 因此老年代是14G，伊甸園＋S0+S1=7G

調(diào)整GC時(shí)間點(diǎn)（成功率抖動(dòng)問題加重）

如果GC需要處理的內(nèi)存量比較大，執(zhí)行的時(shí)間也就比較長，STW （Stop the World）時(shí)間也就更長。按照這個(gè)思路調(diào)整CMS啟動(dòng)的時(shí)間點(diǎn)，希望提早GC，也就是讓GC變得更加頻繁但是期望每次執(zhí)行的時(shí)間較少。添加了下面這兩個(gè)參數(shù)：

-XX:+UseCMSInitiatingOccupancyOnly

-XX:CMSInitiatingOccupancyFraction=50

意思是說在Old區(qū)使用了50%的時(shí)候觸發(fā)GC。實(shí)驗(yàn)后發(fā)現(xiàn)GC的頻率有所增加，但是每次GC造成的陳功率降低現(xiàn)象并沒有減弱，因此棄用這兩個(gè)參數(shù)。

調(diào)整對(duì)象在年輕代內(nèi)存中駐留的時(shí)間（效果不明顯）

如果能夠降低老年代GC的頻率也可以達(dá)到降低GC影響的目的，因此嘗試讓對(duì)象在年輕代內(nèi)存中進(jìn)行更長時(shí)間的駐留，提升這些對(duì)象在年輕代GC時(shí)候被銷毀的概率。使用參數(shù) -XX:MaxTenuringThreshold=31調(diào)整以后收效不明顯。

CMS-Remark之前強(qiáng)制進(jìn)行年輕代的GC

首先補(bǔ)充一下CMS的相關(guān)知識(shí)，在CMS整個(gè)過程中有兩個(gè)步驟是STW的，如圖紅色部分：

CMS并非沒有暫停，而是用兩次短暫停來替代串行標(biāo)記整理算法的長暫停，它的收集周期是這樣：

初始標(biāo)記(CMS-initial-mark),從root對(duì)象開始標(biāo)記存活的對(duì)象

并發(fā)標(biāo)記(CMS-concurrent-mark)

重新標(biāo)記(CMS-remark),暫停所有應(yīng)用程序線程，重新標(biāo)記并發(fā)標(biāo)記階段遺漏的對(duì)象（在并發(fā)標(biāo)記階段結(jié)束后對(duì)象狀態(tài)的更新導(dǎo)致）

并發(fā)清除(CMS-concurrent-sweep)

并發(fā)重設(shè)狀態(tài)等待下次CMS的觸發(fā)(CMS-concurrent-reset)。

通過GC日志和成功率下降的時(shí)間點(diǎn)進(jìn)行比對(duì)發(fā)現(xiàn)并不是每一次老年代GC都會(huì)導(dǎo)致成功率的下降，但是從中發(fā)現(xiàn)了一個(gè)規(guī)律：

前兩次GC CMS-Remark過程在4s左右造成了成功率的下降，但是第三次GC并沒有對(duì)成功率造成明顯的影響,CMS-Remark只有0.18s。Java HTTP 服務(wù)是通過Nginx進(jìn)行反向代理的，nginx設(shè)置的超時(shí)時(shí)間是3s，所以如果GC卡頓在3s以內(nèi)就不會(huì)對(duì)成功率造成太大的影響。

從GC日志中又發(fā)現(xiàn)一個(gè)信息：

在文檔和相關(guān)資料中沒有找到藍(lán)色部分的含義，猜測(cè)是remark處理的內(nèi)存量，處理的越多就越慢。添加下面兩個(gè)參數(shù)強(qiáng)制在remark階段和FULL GC階段之前先在進(jìn)行一次年輕代的GC，這樣需要進(jìn)行處理的內(nèi)存量就不會(huì)太多。

-XX:+ScavengeBeforeFullGC 

-XX:+CMSScavengeBeforeRemark

調(diào)優(yōu)以后效果很明顯，下面是兩臺(tái)配置完全相同的服務(wù)器在同一時(shí)間段的成功率和響應(yīng)時(shí)間監(jiān)控圖，第一個(gè)沒有添加強(qiáng)制年輕代GC的參數(shù)。


結(jié)論

在CMS-remark階段需要對(duì)堆中所有的內(nèi)存對(duì)象進(jìn)行處理，如果在這個(gè)階段之前強(qiáng)制執(zhí)行一次年輕代的GC會(huì)大量減少remark需要處理的內(nèi)存數(shù)量，進(jìn)而降低JVM卡頓對(duì)成功率的影響

對(duì)于Java HTTP服務(wù)，JVM的卡頓時(shí)間應(yīng)該小于HTTP客戶端的調(diào)用超時(shí)時(shí)間，否則JVM卡頓會(huì)對(duì)成功率造成影響

參考文獻(xiàn)

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

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://m.specialneedsforspecialkids.com/yun/65976.html

相關(guān)文章

  • [譯]GC專家系列3-GC調(diào)優(yōu)

    摘要：原文鏈接本篇是專家系列的第三篇。但是，請(qǐng)記住調(diào)優(yōu)是不得已時(shí)的選擇。縮短耗時(shí)的單次執(zhí)行與相比，耗時(shí)有較明顯的增加。創(chuàng)建文件過程中，進(jìn)程會(huì)中斷，因此不要在正常運(yùn)行時(shí)系統(tǒng)上做此操作。因此校驗(yàn)結(jié)果并根據(jù)具體的服務(wù)需要，決定是否要進(jìn)行調(diào)優(yōu)。 原文鏈接：http://www.cubrid.org/blog/dev-platform/how-to-tune-java-garbage-collecti...

    leap_frog 評(píng)論0 收藏0

  • [譯]GC專家系列4-Apache的MaxClients設(shè)置及其對(duì)Tomcat Full GC的影響

    摘要：本文將介紹的參數(shù)的重要性以及在發(fā)生時(shí)對(duì)系統(tǒng)整體性能的顯著影響。我們來看下的選項(xiàng)在發(fā)生時(shí)會(huì)對(duì)系統(tǒng)帶來哪些影響。所以這些請(qǐng)求將會(huì)放到堆積隊(duì)列，隊(duì)列的長度是的中設(shè)置的。從而導(dǎo)致進(jìn)程的數(shù)量超過，并觸發(fā)了操作系統(tǒng)進(jìn)行內(nèi)存交換的閥值。 原文鏈接：http://www.cubrid.org/blog/dev-platform/maxclients-in-apache-and-its-effect-o...

    DangoSky 評(píng)論0 收藏0

  • [譯]GC專家系列5－Java應(yīng)用性能優(yōu)化的原則

    摘要：在本文中我將會(huì)介紹應(yīng)用性能優(yōu)化的一般原則。性能優(yōu)化的流程圖摘取自和合著的性能，描述了應(yīng)用性能優(yōu)化的處理流程。例如，對(duì)每臺(tái)服務(wù)器，你面臨著為單個(gè)分配堆內(nèi)存和運(yùn)行個(gè)并為每個(gè)分配堆內(nèi)存的選擇。不過位能使用堆內(nèi)存最大理論值只有。 原文鏈接：http://www.cubrid.org/blog/dev-platform/the-principles-of-java-application-per...

    lufficc 評(píng)論0 收藏0

  • jvm調(diào)優(yōu)

    摘要：一內(nèi)存調(diào)優(yōu)主要的目的是減小的頻率和的次數(shù)。調(diào)優(yōu)工具之主要用來輸出中運(yùn)行的進(jìn)程狀態(tài)信息。調(diào)優(yōu)工具之和用來查看堆內(nèi)存使用狀況，一般結(jié)合使用。 一、jvm內(nèi)存調(diào)優(yōu) 主要的...

    snowLu 評(píng)論0 收藏0

  • GC專家系列目錄索引

    摘要：調(diào)優(yōu)調(diào)優(yōu)中基于真實(shí)案例介紹了可用于調(diào)優(yōu)的最佳選項(xiàng)。的設(shè)置及其對(duì)的影響的設(shè)置及其對(duì)的影響中介紹了對(duì)選項(xiàng)在系統(tǒng)發(fā)生時(shí)對(duì)整體性能的影響。具體來說，我會(huì)介紹性能優(yōu)化的必要條件判斷是否需要優(yōu)化的步驟，同時(shí)也會(huì)列出在性能優(yōu)化過程中經(jīng)遇到的一些問題。 1. 理解Java垃圾回收 理解Java垃圾回收中我們學(xué)習(xí)了幾種不同的GC算法的處理過程，GC的工作方式，新生代與老年代的區(qū)別。所以，你應(yīng)該已經(jīng)了解...

    ermaoL 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<