又抓了一个导致频繁GC的鬼--数组动态扩容 (club.perfma.com)

【简介】

系统一直在做cms gc,但是老生代一直不降下去,但是执行一次jmap -histo:live之后,也就是主动触发一次full gc之后,通过jstat -gcutil来看老生代一下就降下去了,初看下理论上不太可能,因为full gc也会对old做回收。

点击查看全文 >>

@PerfMa社区 2020-04-24 16:05分享 / 0个评论
赞过的人: IT技术博客大学习 PerfMa社区
要不要再学学下面的文章?
一个导致JVM物理内存消耗大的Bug (club.perfma.com)
发现一个系统老是被OS Kill掉,是内存泄露导致的。在查的过程中,阴差阳错地发现了JVM另外的一个Bug。这个Bug可能会导致大量物理内存被使用,我们已经反馈给了社区,并得到快速反馈,预计在OpenJDK8最新版中发布(JDK11中也存在这个问题)。
by @PerfMa社区 2020-05-22 10:48 分享 查看详情
类初始化死锁导致线程被打爆!打爆!爆! (club.perfma.com)
我们线上的现象是发现非常多的线程都卡死在同一个地方,也不是在做类加载,如果是死循环,那cpu肯定上去了,但是cpu并没有上去,因此比较诡异
by @PerfMa社区 2020-05-07 14:38 分享 查看详情
聊一个可能有惊喜的System GC知识点 (club.perfma.com)
有个系统一启动怎么就发生了System GC(从GC日志里看到了GC Cause是System GC),按照我的经验,这十有八九是堆外内存不够所致,但是启动就不够,这似乎不太可能,于是我又说是不是自己调用了,搜了下没有地方调。
by @PerfMa社区 2020-04-28 10:22 分享 查看详情
从一起GC血案谈到反射原理 (club.perfma.com)
首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 FullGc,已达到回收不再被使用的类对象的目的。具体问题请参考接下来的内容,更好的了解反射的实现原理。
by @PerfMa社区 2020-04-09 10:18 分享 查看详情
JDK的sql设计不合理导致的驱动类初始化死锁问题 (club.perfma.com)
当我们一个系统既需要mysql驱动,也需要oracle驱动的时候,在并发加载初始化这些驱动类的过程中产生死锁的可能性非常大,下面是一个模拟的例子,对于Thread2的实现其实是jdk里java.sql.DriverService的逻辑,也是我们第一次调用java.sql.DriverManager.registerDriver注册一个驱动实例要走的逻辑(jdk1.6下),不过这篇文章是使用我们生产环境的一个系统的线程dump和内存dump为基础进行分析展开的。
by @PerfMa社区 2020-03-31 10:32 分享 查看详情
类初始化导致死锁 (club.perfma.com)
本文要说的是之前在生产环境上碰到,是类初始化导致的死锁,恩,你没看错,确实是类初始化导致的死锁,本文将这个问题描述的场景更加通用化了。
by @PerfMa社区 2020-03-26 10:22 分享 查看详情
K8s 集群节点在线率达到 99.9% 以上,扩容效率提升 50%,我们做了这 3 个深度改造 (yq.aliyun.com)
2019 年阿里巴巴核心系统 100% 以云原生方式上云,完美地支撑了 双11 大促。这次上云的姿势很不一般,不仅是拥抱了 Kubernetes,而且还以拥抱 Kubernetes 为契机进行了一系列对运维体系的深度改造。
by @可耐芊小仙女 2019-12-04 14:59 分享 查看详情
分库分表就能无限扩容吗,解释得太好了! (mp.weixin.qq.com)
像我这样的菜鸟,总会有各种疑问,刚开始是对 JDK API 的疑问,对 NIO 的疑问,对 JVM 的疑问,当工作几年后,对服务的可用性,可扩展性也有了新的疑问,什么疑问呢?其实是老生常谈的话题:服务的扩容问题。
by @zhisheng_blog 2019-11-05 21:14 分享 查看详情
Javascript数组操作 | 晚晴幽草轩 (www.jeffjade.com)
使用JS也算有段时日,然对于数组的使用,总局限于很初级水平,且每每使用总要查下API,或者写个小Demo测试下才算放心,一来二去,浪费不少时间;思虑下,堪能如此继续之?当狠心深学下方是正道。
by @muyakexi619 2019-08-21 16:56 分享 查看详情
MaxCompute 费用暴涨之存储压缩率降低导致SQL输入量变大 (yq.aliyun.com)
我们先明确MaxCompute SQL后付费的计费公式:一条SQL执行的费用=扫描输入量 ️ SQL复杂度 ️ 0.3(¥/GB)。变量主要是输入量和复杂度,如果SQL没有变更的情况下复杂度度也没有变化,那么费用上涨主要原因就是输入量增加,因此我们侧重从输入量去排查是什么环节导致来了输入量的增加。
by @可耐芊小仙女 2019-07-08 15:39 分享 查看详情