文档章节

[JVM]一次线上频繁GC的问题解决

o
 osc_fmg49rzg
发布于 2019/03/20 17:27
字数 833
阅读 23
收藏 0

精选30+云产品,助力企业轻松上云!>>>

起因:周末测试发现线上mq消息积压了十几万的消息,如下图所示

每个队列几万的消息,立即采取紧急措施,将队列下线重新上线。

处理积压消息的量,调用量起来了,很快消息积压解决了。开始事件复盘。

首先分析是否是消息消费能力跟不上消息产生原因,看入口消息,QPS是29.6

消息消费QPS如下

事后开始分析原因,发现队列积压有如下异常:

 

 

超时时间设置的很长,大致分析出消息处理线程等待下游接口超时,连接下游接口设置的超时时间很长,为什么下游接口如此多SocketTimeOut呢?

 然后查看具体的超时接口,调用的下游站点发生SocketTimeout

查看下游站点接口的Cat,发现调用时间极不规律,如下图所示

看日常的调用时间如下图所示,都不超过100ms的:

再看部分机器的GC内存回收,惊呆了,因为这个站点有几个月没有重新发过版本,发现GC如下图,压根没有年轻代的事,新申请的对象都需要在老年代申请,所以导致老年代一直回收。

找一台机器,把GC回收dump下来分析,使用mat查看,如下图所示:

一共七百多M空间,一个对象就占了640M空间,找到原因了,继续往下,看这个对象为什么会这么大,从GC Roots最短路径如下,解释下

Shallow Heap指的是对象本身占据的内存大小  Retained Heap = 本身本身占据内存大小 + 当前对象可直接或间接引用到的对象的大小总和,

换句话说,就是当前对象如果被回收,能够回收的内存大小。

继续看,第一步,查看谁引用了这个对象,找到自己代码中的类,

第二步,查看这个对象TaggedMetricRegistry都引用了谁,为什么会占用这么大的内存空间,如下图所示,

找到罪魁祸首了, 现在开始可以看下代码,如下所示:

发现 TaggedMetricRegistry继承自MetricRegistry,如下图

metrics是个Map,MetricRegistry的成员变量,继续回来看mat,看内部内存占用

如下图所示,发现Map的有几个Node节点尤其大,

追下去,继续

看到这个key,对应在代码中的位置,

 

开始代码分析,这个代码的作用是统计接口每次的执行时间,统计窗口是1分钟,问题就出现在这,因为这个函数的QPS非常高,在update的源码如下:

private final ConcurrentSkipListMap<Long, Long> measurements; 

@Override
public void update(long value) { if (count.incrementAndGet() % TRIM_THRESHOLD == 0) { trim(); } measurements.put(getTick(), value); }
private long getTick() {
for (; ; ) {
final long oldTick = lastTick.get();
final long tick = clock.getTick() * COLLISION_BUFFER;
// ensure the tick is strictly incrementing even if there are duplicate ticks
final long newTick = tick > oldTick ? tick : oldTick + 1;
if (lastTick.compareAndSet(oldTick, newTick)) {
return newTick;
}
}
private void trim() {
measurements.headMap(getTick() - window).clear();
}

 measurements是一个跳跃表,在1分钟有数据频繁产生的时候,会导致在一个时间窗口(1分钟)measurements极速增长,导致内存快速增长,所以产生频繁Yong GC,把这个Metric统计取消,问题Fixed。

o
粉丝 0
博文 500
码字总数 0
作品 0
私信 提问
加载中
请先登录后再评论。
【JVM】调优实战

文章目录 1.关于调优: 1.1调优的目的是什么? jdk1.8默认的垃圾收集器:新生代Parallel Scavenge 和 老年代Parallel Old,这种收集器的特点是并行,但是在垃圾收集时会阻塞工作线程。当阻塞...

lnazj
04/01
0
0
jvm故障排查FAQ

JVM故障排查FAQ 停机或延迟过长? • 有GC详细日志?先tail GC日志看最近GC的Cause,看不出来再用工具分析GC日志 • 无GC详细日志?jstat -gc(具体请查看man jstat) • java内存泄漏?分析h...

大王叫下
04/02
0
0
一个不合理的 JVM 参数设置引发的一场线上惨案。。。

凌晨3点,一阵急促的铃声把老王惊醒。。。 “老大,线上系统好像出问题了,频繁Full GC,系统一直处于卡顿状态。。。” 听到Full GC的那一刻,老王就已睡意全无,他知道,马上又要看到凌晨3...

微笑很纯洁
07/04
0
0
一个不合理的 JVM 参数设置引发的一场线上惨案。。。

凌晨3点,一阵急促的铃声把老王惊醒。。。 “老大,线上系统好像出问题了,频繁Full GC,系统一直处于卡顿状态。。。” 听到Full GC的那一刻,老王就已睡意全无,他知道,马上又要看到凌晨3...

osc_sju4uxml
前天
2
0
JVM学习笔记

JVM参数模板 “-Xms4096M -Xmx4096M -Xmn3072M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFaction=92......

只想混吃等死
2019/10/12
2
0

没有更多内容

加载失败,请刷新页面

加载更多

2020年中国数据存储容量最大单,杉岩数据中标2EB

【全球财经观察 | 新闻速递】这个是猛料!2020年中国数据存储容量第一单:2EB,被杉岩数据中标。具体为中标某省数据中心云存储资源池的2EB容量级分布式存储项目,由20万块磁盘打造的超级海量...

osc_n08oztl3
7分钟前
0
0
不看一下TOP20的云排名,你都不好意思说自己懂云

不看一下TOP20的云排名,你都不好意思说自己懂云 《2019年中国公有云厂商发展状况白皮书》 第二部分 2019年中国公有云厂商整体发展状况概述 既然TOP5排名、TOP10排名出现了新状况,那么2019年...

osc_p1q9onsn
8分钟前
0
0
maven标准settings文件【转载】

<?xml version="1.0" encoding="UTF-8"?> <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://......

LifeCode520
9分钟前
0
0
使用 export timeout = -1来免除ssh时间过长被强制下线的困扰

长时间连接ssh没有操作,可能会被强制下线,这时候,我们使用以下命令就可以免除次困扰: export timeout = -1,便不再会被强制下线了。 有的人写攻略说要写入conf配置文件里,这样确实不用每...

osc_sb30h1xb
10分钟前
0
0
实用性网站大全

本文阅读仅需三分钟,希望这篇帖子对您有帮助 大多数人不是一开始就是大神、大牛的,都是从菜鸟阶段过来的,所以咱们得沉得住气,低调沉稳的打磨,因为我很赞同郭德纲的那句话:没成功之前,...

osc_cdixgndu
12分钟前
0
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部