求助>高峰期CMS remark阶段耗时严重, 导致服务可用性下降>
15回复
1周前

高峰期CMS remark阶段耗时严重, 导致服务可用性下降



image.png

jvm参数

-Xmx6144m -Xmn3072m -Xms6144m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:MaxTenuringThreshold=5 -XX:SurvivorRatio=18 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=1 -XX:+CMSScavengeBeforeRemark -XX:+AlwaysPreTouch -XX:+ExplicitGCInvokesConcurrent -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintFlagsFinal -XX:+HeapDumpOnOutOfMemoryError -XX:CMSInitiatingOccupancyFraction=85 -XX:+UseCMSInitiatingOccupancyOnly -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled
403 阅读
请先登录,再评论

回复列表

csyangchsh1周前

感觉考虑两个点,一个是每次YGC有多少对象进了老年代,能否避免过早晋升,比如调整Survivor大小和MaxTenuringThreshold,1162391行age=1的对象大小总和就已经超过Survivor的50%,会触发动态年龄规则。二是能否让CMS早点开始,现在设置的是85%。另外,这个应用是什么类型的,并发数多少,每个请求大小多少,每个请求需要多长时间处理,可以估算Eden大概多长时间填满,大概有多少对象活下来。或者根据GC日志计算Allocation Rate和Promotion Rate。

archer1周前
回复 csyangchsh:

昨天我调整了CMS回收阈值,从85 -> 75,然后全量了之后发现今天没有CMS回收的尖刺了
image.png
看起来好像是有效果的

回复
csyangchsh1周前
回复 archer:

我不是大佬啊。。。你搜微信号csyangchsh看看。

回复
csyangchsh1周前
回复 archer:

不一定哦,老年代主要是长期存活对象,比如spring bean,连接池等。一般来说请求数据在请求完成后生命周期就结束了。只要YGC存活对象少,尽量避免晋升就行了。怕的就是突然的大流量,YGC后存活对象太多进入老年代。live data set 700M,老年代给2G算多的了。反正每次修改一个参数,然后测试验证。

回复
查看更多
墨书1周前

YGC基本没有效果,因为老生代基本满了,所以晋升失败

image.png

看样子好像是因为年轻代晋升失败导致的,进行 YGC 的时候发现老年代没有空间了。
这是我找到的一些参考:
https://stackoverflow.com/questions/27599934/avoiding-promotion-failed-in-java-cms-gc/33120472

archer1周前

分析了下日志,发现remark之前进行的minor gc没有回收掉young gen的对象,导致remark耗时比较长,具体为什么没回收掉young gen的对象,烦请大佬指教

墨书1周前

-XX:+CMSScavengeBeforeRemark,可以加上这个参数看看

archer1周前
回复 墨书:

加了这个参数的

回复