服务简介,我们的服务是为终端提供调用的接口,每天请求量vv高达50亿+,高峰qps达10W+,单台压测结果qps最大3000+。对高并发场景下,对于接口的并发能力、性能要求比较高,对于请求响应极短也是有更高的要求。
服务为什么能够承载这么大的流量,主要是做了多级缓存处理,写操作直接是在缓存+消息队列,读操作基本落在本地cache和分布式缓存里。另外就是多线程并发处理等等。
1. 慢请求统计
通过统计nginx日志发现,近期服务出现了响应超过1秒的请求有所增加,那就查查呗。
![]()
![]()
统计一天的 nginx请求,一共请求5000W次,超过一秒的5000+,大概万分之一,好像也不是运维说的那么悲观,千分之一的超过秒级。
2.看看GC的情况吧
重启后运行1天的情况

运行半个月的情况,由于没有截图,文字描述带过。
老年代占用率98%,频繁触发FGC,触发后老年代占用率并不能释放多少,由此可以推断,GC有可能GC导致程序卡顿。
查看GC应该是诊断该问题的关键!!!
3.优化
java -jar -Xms4g -Xmx4g -XX:+UseG1GC xxx.jar
优化前未指定任何参数,优化后指定最大、最小堆内存、指定G1垃圾回收器。
默认堆内存和指定堆内存,以及垃圾回收优缺点,自行百度,不在本文讨论范围内。
4.观察优化后的GC
重启后运行1天的情况

5. 慢请求统计
![]()
6.优化前后对比
GC对比
| 指标 | 优化前 | 优化后 |
| YGC | 36646 | 8164 |
| FGC | 21 | 0 |
秒级请求数
| 指标 | 优化前 | 优化后 |
| 大于1秒请求数 | 5177 | 304 |
本文主要探讨了一项Java服务在处理高并发请求时遇到的响应延迟问题。通过对nginx日志的分析,发现万分之一的请求响应时间超过1秒。进一步分析GC情况,发现在使用默认配置下,老年代占用率高,频繁触发Full GC,导致性能瓶颈。为解决这一问题,进行了JVM参数优化,调整了最大和最小堆内存并启用了G1垃圾回收器。优化后,YGC和FGC次数显著减少,超过1秒的请求也大幅下降。这表明,合理的JVM配置对于服务性能至关重要。

被折叠的 条评论
为什么被折叠?



