系统频繁full gc，导致接口访问超时问题排查过程

最新推荐文章于 2024-08-17 02:38:24 发布
最新推荐文章于 2024-08-17 02:38:24 发布
阅读量2.4k 收藏 2
点赞数
分类专栏： java jvm 文章标签： full gc druid socketTimeout
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/earthhour/article/details/107671601
版权
本文详细记录了一次系统接口访问超时问题的排查过程，发现由于频繁Full GC导致JVM停止服务，进而分析了Metaspace空间占用过高及Druid连接池配置不当的问题。通过增加`socketTimeout`参数，优化Druid配置，解决了线程阻塞，提升了系统性能。
摘要由CSDN通过智能技术生成

springboot系统，访问另一微服务接口时报超时。以下是问题排查过程。

[root@localhost xx-service]# top -Hp 25158

top - 10:39:20 up 47 days, 24 min,  4 users,  load average: 3.20, 3.42, 3.30
Threads: 105 total,   1 running, 104 sleeping,   0 stopped,   0 zombie
%Cpu(s): 56.7 us,  0.2 sy,  0.0 ni, 43.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  7814412 total,   550664 free,  4066692 used,  3197056 buff/cache
KiB Swap:  7995388 total,  7818704 free,   176684 used.  3388156 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND                                                                                                                                                                   
25164 root      20   0 4728956   1.1g  24668 R 52.5 14.8   1026:30 java                                                                                                                                                                      
25160 root      20   0 4728956   1.1g  24668 S 44.5 14.8 810:05.29 java                                                                                                                                                                      
25161 root      20   0 4728956   1.1g  24668 S 43.5 14.8 809:54.96 java                                                                                                                                                                      
25162 root      20   0 4728956   1.1g  24668 S 42.5 14.8 810:01.85 java                                                                                                                                                                      
25163 root      20   0 4728956   1.1g  24668 S 41.9 14.8 810:10.74 java                                                                                                                                                                      
25158 root      20   0 4728956   1.1g  24668 S  0.0 14.8   0:00.00 java                                                                                                                                                                      
25159 root      20   0 4728956   1.1g  24668 S  0.0 14.8   0:12.39 java                                                                                                                                                                      
25165 root      20   0 4728956   1.1g  24668 S  0.0 14.8   0:02.37 java                                                                                                                                                                      
25166 root      20   0 4728956   1.1g  24668 S  0.0 14.8   0:00.69 java                                                                                                                                                                      
25167 root      20   0 4728956   1.1g  24668 S  0.0 14.8   0:00.00 java
最低0.47元/天 解锁文章
earthhour
关注
专栏目录
登录接口压测响应慢频繁GC问题排查
cheetahlover的博客
06-03 3037
登录接口压测响应慢GC问题排查 2020.5.22 最近项目组针对几个较重要的接口进行了几十个小时的压测，发现登录接口的压测呈现了一种响应慢且越来越慢的趋势，CPU 也居高不下 压测情况 查看CPU占用情况如图所示： 找到对应服务包是鉴权服务(auth)： 持续运行3小时的CPU占用曲线图： 结论：sc-auth包中的登录接口，占用CPU较高，需要优化。 排查思路 业务场景很简单，账号密码鉴权登录接口。 先排查为什么CPU占用率高 从top命令的结果发现。pid为15082的
CPU飙高，频繁GC，怎么排查？
ai_goodStudent的博客
01-15 2360
本文转自 处理过线上问题的同学基本上都会遇到系统突然运行缓慢，CPU 100%，以及Full GC次数过多的问题。当然，这些问题的最终导致的直观现象就是系统运行缓慢，并且有大量的报警。 本文主要针对系统运行缓慢这一问题，提供该问题的排查思路，从而定位出问题的代码点，进而提供解决该问题的思路。 对于线上系统突然产生的运行缓慢问题，如果该问题导致线上系统不可用，那么首先需要做的就是，...
一次JVM GC长暂停的排查过程
最新发布
weixin_40441243的博客
08-17 28
背景在高并发下，Java程序的GC问题属于很典型的一类问题，带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」，由于GC期间都存在Stop The World问题，因此很容易导致服务超时，引发性能问题。事情最初是线上某应用垃圾收集出现Full GC异常的现象，应用中个别实例Full GC时间特别长，持...
内存泄漏导致GC超时
舒航的博客
07-16 820
最近忙着做新的项目，主要是负载对老系统进行重构，但是现在每天大概会收到上百条老系统生产环境的GC超时告警，生产环境是GC时长超过2秒会告警，而且随着时间的推移，部分实例的GC时长已经接近3秒，一个是天天收到告警比较烦，二个是比较好奇为什么会出现这么频繁的GC告警。系统的话大概是一个日均百万级别呼叫量的呼叫中心，查看了一下生产环境的部署情况，产生GC告警的服务大概部署了40个实例，默认Parallel Old老年代垃圾回收器目前老年代大小600M左右，按道理来说是不应该产生如此多的GC告警的，一个生产环境对一
由一次fullgc引起的RPC调用超时
clz1314521的专栏
04-22 165
公司的联机RPC服务是一个类似Dubbo的服务，默认是的垃圾回收器是CMS。一天上游系统说发现多笔调用我们RPC服务超时。于是根据对方提供信息查看日志，发现请求虽然在合理时间处理完了。但是开始处理时间和上游业务系统请求时间存在时间差，相差10秒左右。 于是查看服务日志，发现有一个节点日志有30秒左右没有输出日志。然后查下gc日志，发现了这个时间点发生了一次30秒左右的fullgc。进而分析了历史fullgc记录，发现服务10天左右发生一次fullgc，每次时间在15秒。因为堆内存设置了4G，这个f
gc的原因 频繁full_「原创」JVM01 | GC这么好，做了什么频繁引起服务超时？
weixin_39570777的博客
12-22 331
前言 这是 JVM 系列文章的第一篇。说明一下 GC 的重要性。故障描述 某年某月某日 上午，线上发生故障，经过排查，发现某核心服务 Dubbo 接口超时。故障根源 查看该服务监控指标，发现该服务 FullGC 次数过于频繁，简直要飞上天了。那也难怪接口会超时了。那么为啥 FullGC 次数太多会造成接口超时呢？因为 GC 停顿。 FullGC 时会产生GC停顿，也叫 stop the world...
线上问题排查：接口超时
田维常
02-11 526
你好，我是田哥不知道大家过年过得肿么样反正我今年春节回家还是学到了一些技能，比如打打麻将之类的，学费还是缴了不少的这周已经返工了，该收心了。这不，最近就看到了一个非常厉害的关于“接口超时”问题排查的帖子，从应用排查到内核级别。虽然看到后面的时候我已经有点跟不上了，但是对于整个问题排查的过程还是比较清晰的。（细节不重要，排查思路，方向值得学习）虽然很难，但是还是啃下去了，这其中体现出来的就是我所追求...
一次Full GC导致CPU飙升的排查过程
汐日南莘的博客
04-10 2416
一次FULL GC导致CPU飙升，系统卡顿的问题排查过程，JVM, FULL GC
记一次生产频繁发生FullGC问题
m0_71777195的博客
03-17 538
因为最近这个接口调用量是翻倍了，所以我就去检查了下慢SQL，发现确实是有较多的慢SQL，所以我就缩减了查询的时间范围，但是效果并不好。经过上面问题的排查，造成hooks大对象的原因找到了，就是每次调用接口的时候，都会往hooks里面put一个对象。过了一会发现，这个服务fullGC是有问题的，太频繁了，这个应该是导致接口超时的根本问题，因为时间也是对的上的。对比一下，就不难发现，fullGC数量是从3月15号晚上9点开始增加的，也是这个接口对外开放的时间。2、根据dump文件，分析出堆内对象的分布情况。
频繁GC导致OOM内存溢出的问题排查
没啥简介
08-28 2214
频繁GC导致OOM内存溢出的问题排查1.问题发现2. 导出内存dump3.用mat分析dump下载mat配置mat运行mat4. 分析5. 解决方案 1.问题发现 日志中打印如下，发现频繁GC并导致OOM [2021-08-25 15:14:33, 948] [ERROR] [] [] [DubboServerHandler-74.0.2.41:11306-thread-488]- org.apache.dubbo.rpc.filter.ExceptionFilter$ExceptionListener.o
记一次 CMS GC导致 FULL GC 时间开销很大的排查
Agly_Charlie的博客
12-22 2066
记一次 CMS GC导致 FULL GC 时间开销很大的排查背景定位分析过程第一次尝试解决方案CMS GC收集器分析了解CMS收集原理优缺点分析总结分析根因解决方案 背景 服务接入注册中心后，就会有实例健康检查，通过ip+port的方式访问接口，检查实例是否健康，某日有个实例出现了告警。检查发现是当时接口超时异常了，触发告警。 短暂的时间后，服务又正常恢复了，接口正常响应。观察日志没有异常问题。 定位分析过程 这个健康接口是个简单的返回，没有经过DB、缓存等。所以超时问题出现在服务本身。 查看CAT、
记一次生产环境频繁耗时GC导致的周期性响应缓慢问题
qq_27156945的博客
05-14 1395
记一次生产环境频繁耗时GC导致的周期性响应缓慢问题1.问题来源与背景2.问题查询与定位2.1 日志中心查询2.2 容器日志查询3.问题排查3.1 网络排查3.2 日志观察4.总结 1.问题来源与背景 服务使用K8s集群部署，重要的服务采用多节点负载的形式搭建。出问题的节点持续运行时间将近半年。某一天的早上收到预警信息，说k8s某节点服务不可用，大家立马都紧张起来了。 2.问题查询与定位 2.1 日志中心查询 错误日志： 日志中显示7点多的时候 频繁出现访问超时的现象 。 耗时日志： 耗时日志中也显示7
记一次matespace导致的FGC导致接口性能尖刺
山月记
01-24 601
0. 背景 自己服务一个核心接口的TP99有性能尖刺，开始的排查之旅。 先用skywalking定位了下执行慢的请求，发现依赖的数据库、redis组件均是快速返回。时间都占用’spingmvc’本身。 这就有点难了，性能尖刺一般怀疑db慢查询。目前确实没有。该接口QPS挺高的，想着是不是线程不够用呀。用 jstat看了下线程情况，发现tomcat的线程还是够用的。不过还是主动增大了线程数量，且增加了几个节点副本。发现并无效果。 排查进入困难之后，想着是不是有GC的STW导致请求尖刺。于是查了机器上的gc l
你一定不能错过，高并发下Java程序的GC问题排查，又让我涨姿势了
2401_83945851的博客
03-31 470
通过上面这个案例，可以看到YGC问题其实比较难排查。相比FGC或者OOM，YGC的日志很简单，只知道新生代内存的变化和耗时，同时dump出来的堆内存必须要仔细排查才行。另外，如果不清楚YGC的流程，排查起来会更加困难。这里，我对YGC相关的知识点再做下梳理，方便大家更全面的理解YGC。
线上FullGC频繁排查-druid
热门推荐
Rocky的博客
04-11 4万+
线上FullGC频繁的排查问题
Spring Cloud Gateway下的GC停顿排查之旅
架构师小秘圈
07-15 634
01 背景在微服务架构体系流行的当下，Spring Cloud全家桶已经是大多数团队的首选，我们也不例外，并且选择了Spring Cloud Gateway作为了业务网关，进行了一些通用能力的开发，如鉴权、路由等等。作为一个成熟的框架，我们已经使用了很长时间都没有出现问题，表现十分稳定。然而最近突然出现短时间内的5xx告警，起先没引起注意，认为是网络的问题，但是后来发现每隔一段时间（一两个星期...
严重Full GC导致系统卡死
kankan_s的专栏
08-05 577
严重的Full GC导致系统直接卡死是一个常见的性能问题，通常是由于Full GC导致的长时间停顿引起的。当发生Full GC时，系统的所有线程都会被挂起，直到Full GC完成，这可能导致系统出现较长时间的停顿，造成系统直接卡死或响应极慢。同时，使用监控工具实时监测系统的GC情况，帮助定位问题，并根据情况调整相关参数，最终达到减少Full GC的频率和降低停顿时间的目标。大对象可能导致Full GC的频繁发生，因为它们的回收需要更多的时间。如果系统的堆内存设置不足，可能会导致频繁的Full GC。
cpu高 thread vm_GC task thread#0 (ParallelGC) 占用cpu过高
weixin_42634811的博客
12-23 7057
最近在查线上应用cpu过高时遇到一个问题，根据线程号追踪发现是gc线程占用大量的cpu。top -p 7794top - 15:31:22 up 883 days, 35 min, 1 user, load average: 0.23, 0.37, 0.72Tasks: 21 total, 0 running, 21 sleeping, 0 stopped, 0 zombieC...
接口请求频次太频繁导致gc full 异常
06-07
这个问题可能是由于过多的接口请求导致服务器负载过高，从而导致了gc full 异常。解决这个问题的方法可以从以下几个方面入手： 1. 优化代码。可以通过对代码进行优化，尽量减少无用的接口请求，避免请求过多导致服务器负载过高。 2. 增加服务器资源。可以通过增加服务器的硬件资源，如内存、CPU等，来提升服务器的性能，从而缓解gc full 异常。 3. 限制接口请求频次。可以通过限制接口请求的频次，来避免请求过多导致服务器负载过高。例如，可以设置请求的时间间隔，或者设置请求的次数限制等。 4. 使用分布式系统。可以通过使用分布式系统来分摊服务器的负载，从而提升服务器的性能，避免gc full 异常。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值