alibaba / Sentinel

A powerful flow control component enabling reliability, resilience and monitoring for microservices. (面向云原生微服务的高可用流控防护组件)
https://sentinelguard.io/
Apache License 2.0
22.29k stars 7.99k forks source link

Sentinel performance footprint, leading to frequent YGC #1563

Open lcg201x opened 4 years ago

lcg201x commented 4 years ago

我用的网关是Gateway ,在没有集成Sentinel之前 ,一切正常。 但是 集成了Sentinel之后 ,发现YGC的次数每天都在增长 比如刚启动的时候 一天YGC是24次,第二天就变成了26次,第三天就变成了28次,第四天就是30次 然后就越来越频繁。总之呢就是年轻代被填满的速度越来越快。最后监控jvm的GC图填满整个年轻代几乎成了一条细线。STW次数越来越多,严重影响性能。希望能解决一下。 集成之前

gsberofr 集成之后 gsmiddle 再往后 gs3rd 继续观察 gs4rd 最后 gs5rd

sczyh30 commented 4 years ago

Could you please identify what kinds of objects were growing fast (and caused YGC frequently)?

lcg201x commented 4 years ago

您好,   抱歉没能用英语回复您。收到您的来信,我在本地跑起了简单集成sentinel的gateway(没有任何代码).   我一共做了2组截图。1rd开头的是 第一次启动到第一次ygc的对象生成情况。   2rd是 ygc以后 的对象图。   1rd.png 程序启动   1rdeden.png 启动时的伊甸园   1rdeden-3minute.png 三分钟时的伊甸园   1rdeden-3minute.png 起始伊甸园   其它图片都带了中文。   我大概描述一下 jprofile有多个分析角度。从classes角度去分析对象没看到什么问题,但是从package角度去分析对象发现 primitive arrays这一组 对象很大 好几个G   但是展开来看也都是一些基础类型的数组。   对象生成的速度大概是一分钟100M。第一次启动之后有2.55G的空间,用了24分钟就填满了。   我现在的项目正在开发,测试服务器不定期重启服务。但是根据我能观察到的现象。2.775G的伊甸园。到了第7-8天的时候 大概10-12分钟就能填满。即使是在没有任何人访问的凌晨,也是如此的速度。   2.775G的伊甸园10分钟左右填满,这个速度还是有点恐怖的。   另外我们只在gateway中集成了sentinel,在其它基础服务中没有集成,所以其它微服务的jvm表现倒是一切正常。

最后祝您能快速定位问题,希望可以帮到您。谢谢您的来信。                                                                                                                                                                                        祝工作顺利,生活开心。                                                                                                                                                                                          您忠实的fans。 ------------------ 原始邮件 ------------------ 发件人: "Eric Zhao"<notifications@github.com>; 发送时间: 2020年6月29日(星期一) 下午3:54 收件人: "alibaba/Sentinel"<Sentinel@noreply.github.com>; 抄送: "栾晨光"<10136547@qq.com>;"Author"<author@noreply.github.com>; 主题: Re: [alibaba/Sentinel] Sentinel performance footprint, leading to frequent YGC (#1563)

Could you please identify what kinds of objects were growing fast (and caused YGC frequently)?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

jasonjoo2010 commented 4 years ago

看也都是一些基础类型的数组。   对象生成的速度大概是一分钟100M。第一次启动之后有2.55G的空间,用了24分钟就填满了。   我现在的项目正在开发,测试服务器不定期重启服务。但是根据我能观察到的现象。2.775G的伊甸园。到了第7-8天的时候 大概10-12分钟就能填满。即使是在没有任何人访问的凌晨,也是如此的速度。   2.775G的伊甸园10分钟左右填满,这个速度还是有点恐怖的。   另外我们只在gateway中集成了sentinel,在其它基础服务中没有集成,所以其它微服务的jvm表现倒是一切正常。 最后祝您能快速定位问题,希望可以帮到您。谢谢您的来信。                                                                             &

截图用邮件应该是没回复上,可以稍后补充下截图,最好是在eden达到80%+的时候用jstat截下对象统计排行脱敏后作为附件发上来作为参考

jasonjoo2010 commented 4 years ago

另外需要了解下,是否有使用热点参数,资源数大概什么量级,sentinel什么版本(最好是把相关的依赖树一起发一下)

lcg201x commented 4 years ago

您好,赵老师   我这几天出差了,没顾上回复,实在是抱歉,事情有了新的进展。   首先给您汇报一下我gateway 客户端POM文件的坐标使用如下   <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId> <version>2.1.0.RELEASE</version> </dependency> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-sentinel-gateway</artifactId> <version>2.1.0.RELEASE</version> </dependency> <dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-transport-simple-http</artifactId> <version>1.6.3</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-gateway</artifactId> <version>2.2.0.RELEASE</version> </dependency> sentinel dashborad是1.7.2版本以下是我的启动参数 -Duser.timezone=GMT+08 -Xmx2048M -Xms2048M -Xmn1786M -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -XX:SurvivorRatio=8 -XX:-UseAdaptiveSizePolicy -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=2 -XX:CompressedClassSpaceSize=32M -Dfile.encoding=UTF-8 接下来给您汇报一下新情况。 上一次截图其实就是观察对象生成情况,发现int数组占据了好几个G 其实就是基础类型。 但是昨晚下班的时候,我们一个程序员修改了common模块 导致所有的微服务,除了网关之外的全部报错起不来,也就是说微服务和nacos,sentinel全都断了联系, 今天早晨来的时候我却意外发现网关的jvm图恢复了正常。 然后开发人员修复了common的错误之后。所有微服务上线,我发现jvm图形又开始变得频繁。 所以,根绝这条线索可以肯定的是,jvm产生对象频繁肯定是由于gateway和这些微服务联系沟通所产生的。 但是这里有一个问题,对象产生频繁没什么,我把内存调大就行了,但是它最主要的问题是越来越频繁。处于一个增长趋势。如下图  

最左边是微服务挂之前。超级频繁的gc 中间是微服务挂了之后,jvm恢复正常。 最后是微服务恢复之后,有些频繁但是不那么频繁。 但是可以肯定的是 运行3-5天之后 就又会越来越频繁 回到最左边的状态。

最后 补充上上次漏掉的截图。

------------------ 原始邮件 ------------------ 发件人: "Eric Zhao"<notifications@github.com>; 发送时间: 2020年6月30日(星期二) 下午3:44 收件人: "alibaba/Sentinel"<Sentinel@noreply.github.com>; 抄送: "栾晨光"<10136547@qq.com>;"Author"<author@noreply.github.com>; 主题: Re: [alibaba/Sentinel] Sentinel performance footprint, leading to frequent YGC (#1563)

另外需要了解下,是否有使用热点参数,资源数大概什么量级,sentinel什么版本(最好是把相关的依赖树一起发一下)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

lcg201x commented 4 years ago

您好,赵老师:   上一封邮件最后忘了说热点参数的问题。目前我这个gateway集成sentinel只是简单集成 没有任何代码没有任何拦截器没有任何限流以及热点参数。就是简单打通。没别的了。

------------------ 原始邮件 ------------------ 发件人: "Eric Zhao"<notifications@github.com>; 发送时间: 2020年6月30日(星期二) 下午3:44 收件人: "alibaba/Sentinel"<Sentinel@noreply.github.com>; 抄送: "栾晨光"<10136547@qq.com>;"Author"<author@noreply.github.com>; 主题: Re: [alibaba/Sentinel] Sentinel performance footprint, leading to frequent YGC (#1563)

另外需要了解下,是否有使用热点参数,资源数大概什么量级,sentinel什么版本(最好是把相关的依赖树一起发一下)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

lcg201x commented 4 years ago

0 1rd 1rdeden 1rdeden-3minute 1rd 快要回收前的class 1rd回收前 包图 1rd快要回收 2rd开始 2rd class图 2rd包图

lcg201x commented 4 years ago

不知道为什么邮件回复,挂不上图。今天补充了图片,实在抱歉。

jasonjoo2010 commented 4 years ago

根据描述,这个跟之前一个人碰到的疑似Metric拉取相关问题有点像,尤其是闲时ygc的问题

@sczyh30

lcg201x commented 4 years ago

又观察了两个星期,补充一下我观察到的情况。 果然就如我所说的一样YGC越来越频繁,现在不到两个G的伊甸园只要2分钟就能填满,然后YGC t w