首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    RocketMQ与Dubbo相爱相杀引起的FullGC

    仓库代码 https://github.com/infuq/MQ-Dubbo-FullGC 如果需要运行上述代码,还需要部署Zookeeper和RocketMQ环境....同时观察MQConsumer的控制台, 会有FullGC产生,而且很多次. 大体流程就是上面描述. 发现的表象是老年代一直在增长,伴随着发生了FullGC,那么原因是什么?...由于Dubbo接口调用超时,阻塞住了MQ消费消息的线程,而MQ生产者一直在生产消息,可消费消息的速度太慢(由于Dubbo调用超时间接导致),最终消息都被放在老年代堆空间中,引起频繁FullGC....org.apache.rocketmq.client.impl.consumer.ConsumeMessageConcurrentlyService 存放消息的队列是一个无界队列,也就是说,只要消息生产者生产消息的速度比消费者消费消息的速度快很多很多,最终一定会发生FullGC...RocketMQ和Dubbo, 导致FullGC的原因以及造成FullGC的地方还有很多,接下来的文章也会一一列举出来. 针对这篇文章,也会抽个时间录播一个视频演示给大家看.

    34210

    FullGC没及时处理,差点造成P0事故

    JVM_FullGC和pod重启告警都消失 14:00,把之前停止的定时任务启动 服务不稳定状态时堆内存及GC情况 故障原因 出现占用大内存的操作,导致FullGC频繁。...容器重启pod FullGC时会STW,此时所有请求都会阻塞。 FullGC耗时超过30s,pod就会重启。异常期间FullGC耗时都超过120s了。...按配置的规则,容器会重启该pod FullGC超过30s,则容器会将pod重启 为什么会触发FullGC 出现了耗内存的操作。...只是串行查询TableStore,虽然会耗内存,但如果正在执行的pod没有其它在执行的耗内存操作,是不会触发FullGC的。 这也可能是当前应用偶发出现重启的原因。...待解决的问题 FullGC耗时过长的原因及解决办法 相关阅读: 千丈之堤,以蝼蚁之穴溃:一个慢SQL引发的雪崩

    47230

    记一次JVM FullGC引发严重线上事故的定位、分析、解决过程!

    “ 这篇文章给大家聊一次线上生产系统事故的解决经历,其背后代表的是线上生产系统的JVM FullGC可能引发的严重故障。...最后结合系统A自身的日志,以及系统A的JVM FullGC进行垃圾回收的日志,我们才算是搞清楚了具体的故障原因。...要等JVM FullGC结束之后,工作线程才会恢复运作。 我们来看下面那个代码片段: 但是这种系统A的莫名宕机是不正确的,因为如果没有JVM FullGC,本来上面那个if语句是不会成立的。...结果因为出现了JVM FullGC卡顿了几十秒,导致莫名其妙就触发了if判断的执行,系统A莫名其妙就退出宕机了。...我们只要在代码里加入一些东西,监控一下上述代码中是否发生了JVM FullGC。 如果发生了JVM FullGC,就自动延长expireTime就可以了。

    1.4K11

    记一次FullGC的排查经历--从日志到业务代码

    某天突然收到一台实例(即一个Java应用)产生FullGC日志的报警,如上图红色标记的服务,FullGC的日志信息如下: 2020-07-25T14:55:07.481+0800: 155286.031...,并且由于应用虽然STW,但是请求确还是在堆积,导致一直在持续FullGC,没有自愈 普通CMS老年代回收过程如下图所示。...(PS:其实这里是可以有优化的空间的,例如某种机制发现服务在进行FullGC时就将其主动从注册中心中摘掉,然后待其FullGC完毕自愈后再加入到注册中心接受请求,整个过程自动完成无需人工干涉) 原因排查...问题自然要一跟到底,接下开始进行排查 为什么会FullGC?...gc日志在跟我说话 第一次FullGC发生在2020-07-25 14:51:58,观察之前的日志可以发现历史上CMS并发回收一般都会将堆内存稳定在3608329K->1344447K,从3.6G左右回收到

    48631
    领券