年轻代频繁GC ParNew导致http变慢

文章讲述了作者在接到线上服务超时报警后,通过监控、性能分析和日志追踪,发现问题是由于超大响应体引发的内存占用和频繁GC,强调了接口设计、缓存、性能测试和流量隔离的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

背景介绍

某日下午大约四点多,接到合作方消息,线上环境,我这边维护的某http服务突然大量超时(对方超时时间设置为300ms),我迅速到鹰眼平台开启采样,发现该服务平均QPS到了120左右,平均RT在2秒多到3秒,部分毛刺高达5到6秒(正常时候在60ms左右)。

qps情况:

在这里插入图片描述

rt情况
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Yh5Dkh5l-1691546155736)(/uploads/new2021/images/m_62d7c0b3a62e26f8cc5167dc1669b3ec_r.png)]

问题解决

该服务是一个对内的运营平台服务(只部署了两台docker)预期qps个位数,近期没做过任何的线上发布,核心操作是整合查询数据库,一次请求最多涉及40次左右的DB查询,最终查询结果为一个多层树形结构,一个响应体大约50K。之前口头跟调用方约定要做缓存,现在看到QPS在120左右,(QPS证明没有做缓存),遂要求对方做缓存,降低QPS。后QPS降到80以内,rt恢复正常(平均60ms),最终QPS一直降到40(后续需要推动调用方上缓存,保证QPS在个位数)。

问题定位

由于该服务核心操作是查询数据库,且一次请求有40次DB query,遂首先排查是否慢sql导致,查看db性能监控,发现db 平均rt在0.3ms以内,可以算出来DB整体耗时在12ms左右,排除慢sql导致RT变高。

开始怀疑,是否DB连接池在高并发下出现排队,tddl默认的连接池大小是10.一查监控,整个占用的连接数从来没有超过7个,排除连接池不足的问题。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RvB79KCq-1691546155737)(/uploads/new2021/images/m_2c7e0b0f6b572ac90f9ec5dfb67ab396_r.png)]

至此,造成RT高的原因,在数据库层面被排除。

接着开始查采样到的服务调用链上的每一个执行点,看看到底是调用链上的那部分耗时最多。发现里面很多执行点都有一个特点,就是本地调用耗时特别长(几百毫秒),但是真正的服务调用(比如db查询动作)时间却很短,(0ms代表执行时间小于1ms,也间接印证之前db的平均RT在0.3ms以内)

本地调用耗时: 267ms

客户端发送请求: 0ms

服务端处理请求: 0ms

客户端收到响应: 1ms

总耗时: 1ms

这时候问题逐渐清晰,问题出现在本地方法执行的耗时过长,可是再次检查该服务所有代码,并没有需要长耗时的本地执行逻辑,那么继续看CPU的load情况。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-naLsYLu6-1691546155737)(/uploads/new2021/images/m_3382613beb181c991e8e34dd22a4a2b8_r.png)]

load长时间在4左右徘徊,我们的docker部署在4c8G的宿主机上,但是我们不能独占这个4C的,持续这么高的load已经不正常了。

继续追查cpu load飙高的原因,接着去看GC日志,发现大量的Allocation Failure,然后ParNew次数在每分钟100次以上,明显异常,见下GC日志例子

2020-03-25T16:16:18.390+0800:1294233.934: [GC (Allocation Failure)2020-03-25T16:16:18.391+0800:1294233.935: [ParNew:1770060K->25950K(1922432K),0.0317141secs]2105763K->361653K(4019584K),0.0323010secs] [Times: user=0.12sys=0.00, real=0.04secs]

每次占用cpu的时间在0.04s左右,但是由于ParNew GC太过频繁,每分钟最高100次以上,整体占用cpu时间还是很可观。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wLIQ4XwE-1691546155737)(/uploads/new2021/images/m_9dd9bb7ccc92f6f05715c7bdb851f653_r.png)]

看了下jvm内存参数

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kZdvSCtN-1691546155738)(/uploads/new2021/images/m_ab6f4b87a3fc19d1701754c6734a7cc1_r.png)]

年轻代分配了2G内存,其中eden区约1.7G

使用jmap查看年轻代对象占用空间情况,排名靠前的有多个org.apache.tomcat.util.buf包下的对象,比如ByteChunk、CharChunk、MessageBytes等,以及响应涉及的一些临时对象列表。其中ByteChunk等即tomcat响应输出相关类

至此问题明确,超大响应包(50K)在发送到网卡的过程中,需要经过从用户态user space拷贝到内核态 kernel space,然后在拷贝到网卡进行发送(像netty等的零拷贝针对的就是这种拷贝),加上响应体查询过程中,涉及的大量临时对象list,在高并发场景下,就导致年轻代内存占满,然后频繁gc(后续在合适的时间会压测该接口),这里还有一个点,很多人以为ParNewGC不会stop the world,其实是会的。频繁ParNewGC造成用户线程进入阻塞状态,让出CPU时间片,最终导致连接处理等待,接口的RT变高。整个排查过程,鹰眼,idb性能监控等可视化监控平台帮助真的很大,否则到处去查日志得查的晕头转向了。

经验总结
接口设计,需要避免超大响应体出现,分而治之,将一个大接口拆分为多个小接口。

缓存设计,像这个服务一样,一个请求带来将近40次DB查询的,需要考虑在服务端进行缓存(当时偷懒了,要求调用方去做缓存)。

性能设计,要对自己负责系统的性能了如指掌,可以通过压测等手段得到自己系统的天花板,否则,某一个接口hang住,会导致整个应用的可用性出现问题。

流量隔离,内部应用和外部流量之间,需要进行流量隔离,即使通过缓存,也有缓存击穿的问题。

口头说的东西都不靠谱,要落在文档上,还需要检查执行情况。

<think>嗯,用户问的是ParNewGC的YGC是否是异步的。首先,我得确认ParNewGC是什么,它属于哪种垃圾收集器。ParNewGC是新生代的收集器,通常与CMS配合使用,用于年轻代的垃圾回收。 接下来,YGC指的是Young Generation Garbage Collection,也就是年轻代GC。用户想知道这个过程是否是异步的。根据JVM的工作原理,大部分年轻代GC都是“Stop-The-World”事件,也就是说在GC过程中,所有应用线程都会被暂停,直到GC完成。所以这里的异步可能是指GC线程和应用线程是否能并行运行。 ParNewGC是一个多线程的收集器,它在进行YGC时会使用多个线程来加速垃圾回收,但这些工作仍然是在STW的情况下进行的。因此,虽然ParNewGC使用了多线程,但YGC本身并不是异步的,因为应用线程必须等待GC完成才能继续执行。 可能需要进一步确认是否有异步处理的情况,但一般来说,年轻代GC都是同步的STW事件。CMS收集器在处理老年代时会有并发阶段,但ParNewGC本身在年轻代的收集是同步的。需要确保用户没有混淆不同的GC阶段或者收集器类型。 另外,用户可能对异步GC的概念有疑问,比如是否存在某些情况下YGC可以与应用线程并发执行。根据现有的知识,主流的年轻代收集器如ParNew和Parallel Scavenge都是STW的,而G1和ZGC在部分阶段可以并发,但年轻代的收集仍然需要暂停应用线程。 因此,总结来说,ParNewGC的YGC不是异步的,而是同步的STW事件,尽管它使用多线程来缩短暂停时间。</think>关于 ParNew GC 的 Young GC(YGC)是否异步的问题,需分层次说明: --- ### **1. 核心结论** - **ParNew GC 的 YGC 是同步的 Stop-The-World(STW)事件** 其暂停所有应用线程执行,**无法与业务线程并发运行**。 --- ### **2. 技术细节** #### **2.1 ParNew GC 的特性** - **角色定位** 专用于新生代的 **多线程** 垃圾收集器,常与 CMS(Concurrent Mark-Sweep)配合使用。 - **执行模式** - 触发条件:新生代空间不足时(如 Eden 区满) - 工作方式:使用多个 GC 线程 **并行** 执行垃圾回收 - **全程 STW**:GC 线程工作时,所有应用线程必须暂停 #### **2.2 异步 VS 同步的界定** - **异步 GC**(如 CMS 的并发标记阶段) - GC 线程与业务线程 **并发执行** - 无需暂停应用(特定阶段除外) - **同步 GC**(如 ParNew YGC) - **必须完全暂停应用线程** - 暂停时间与堆大小、存活对象数量相关 #### **2.3 对比其他收集器** | 收集器 | YGC 是否异步 | 典型场景 | |---------------|--------------|-----------------------| | ParNew | ❌ 同步 | 搭配 CMS 使用 | | Parallel Scavenge | ❌ 同步 | 高吞吐量场景 | | G1 | ❌ 同步 | 低延迟优先 | | ZGC/Shenandoah | ✅ 异步 | 超大堆、亚毫秒级暂停 | --- ### **3. 监控验证** 通过 GC 日志可明确观察到 STW 现象: ```log [0.234s][info][gc] GC(1) Pause Young (ParNew) 100M->60M(200M) 15.678ms ``` - `Pause Young` 明确表示 STW 暂停 - 暂停时间 `15.678ms` 内所有应用线程阻塞 --- ### **4. 优化方向** 若需减少 YGC 对业务的影响: 1. **缩短单次暂停时间** - 减小新生代大小(-Xmn) - 增加 GC 线程数(-XX:ParallelGCThreads) 2. **降低 GC 频率** - 增大 Eden 区(如调整 -XX:NewRatio) - 优化对象分配(减少短命对象) 3. **升级收集器** - 使用 ZGC/Shenandoah 实现 **真正异步的 YGC** --- ### **附:关键参数参考** ```bash # 强制使用 ParNew + CMS 组合 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC # 设置 ParNew 线程数(默认=CPU核数) -XX:ParallelGCThreads=4 ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值