支付网站建设费入什么科目,建立网店,一旦开战最危险的城市,促销网站怎么做最近在做一次系统整体优化,发现系统存在GC时长过长及JVM内存溢出的问题,记录一下优化的过程 面试的时候我们都被问过如何处理生产问题#xff0c;尤其是线上oom或者GC调优的问题更是必问#xff0c;所以到底应该如何发现解决这些问题呢#xff0c;用真实的场景实操#xff… 最近在做一次系统整体优化,发现系统存在GC时长过长及JVM内存溢出的问题,记录一下优化的过程 面试的时候我们都被问过如何处理生产问题尤其是线上oom或者GC调优的问题更是必问所以到底应该如何发现解决这些问题呢用真实的场景实操更具有说服性。
一如何发现
1.发现经过如下首先pass服务的pod不停自动触发重启因为pass配置系统health接口访问超时通过系统的grafana监控发现二点异常1.GC时间大量超时40s2.堆内存达到24G也是我们配置最大的内存触发OOM 监控如下:
所以我们可以梳理出以下链路 二如何优化
1,我们dump系统的在业务低谷期的内存情况看看业务的低谷期时系统中是否存在不合理的大对象如果有肯定是要优化掉的因为业务高峰期会肯定分配一些局部变量大对象需要给他们腾空间可以理解先优化最简单的再优化运行中产生的结果还真的发现在这个GoodsSetNormalGoodsCache类的中cache对象存了一个近1200W(并且随业务持续增长)的内存大对象用于全局skc分站点上下架的缓存信息 dump如下: 1.巧用redis优化大对象
优化策略大家很容易想到将map由JVM内存移入redis的hash结构中存储面试过很多人都说把oom的对象直接剔除其实很多时候我们处理的场景是不允许删除如果直接移除可以解决问题我相信大部分开发就不会加载部分大对象进入内存加载进去必然是为了快速查询全量数据)存储结构如下图:
但是实际上线后生产环境中又遇到新的问题,这个keyQPS很高达到几万qps因为业务逻辑增量任务需要不停且大量的查询skc在不同站点的上下架信息必然也导致这个key是一个热key 如图注意这里的元素个数是900w因为在做初始化
当然系统中出现热key不是问题问题在于redis也是个大key导致数据产生倾斜最高的节点和最低的节点相差一个G的数据并且我们联系运维同学重平衡也无法生效于是我们思考应该如何从开发角度解决这个问题究其根本原因是key太大存储的数据太多那么我们的场景并没有统计功能也就是说这个key我们可以拆开降低单个key的大小QPS自然也就降低下去了。 如图 优化后重新写入数据我们可以清晰看出倾斜的数据节点恢复正常了 2.巧用布隆过滤器优化大对象
上面我们dump了系统空闲水位的大对象也进行优化了那么代码运行时产生的局部大对象我们的优化思路时什么呢正好我们的代码中有一个很大的set存储商品集可以理解为一些条件的skc集合全量的skc用于商品更新的时候和上一次数据进行对比产生增量你可以理解为一个集合数据要更新那么更新后产生了哪些新增的数据我们怎么知道呢肯定是存了一份之前的历史数据那这个数据就装在set现在的问题是需要更新的商品集很多所以set也很多导致set的大对象的频繁创建和回收触发GC压力很大
我们的优化思路是1.首先这个set不是用于常驻查询换句话说就不是热key用于临时操作那么放在redis就得不偿失了当然了也是可以做到2.这个set的作用主要用于存储全量进行判断是否存在但是问题在于内存开销大有没有一种结构可以内存占用小又可以判断元素是否存在这个容器就是即布隆过滤器
我们利用guava的布隆过滤器写个简单的程序说明优化流程以及内存占用对比
public class BloomFilterUtils {/*** builderBloomFilter** param size 长度* param fpp 误判率* return*/public static BloomFilterString builderBloomFilter(int size, double fpp) {BloomFilterString bf BloomFilter.create(Funnels.stringFunnel(Charset.defaultCharset()), size, fpp);return bf;}public static void main(String[] args) {HashSetString set new HashSet();ArrayListString list new ArrayList();//存储1000w元素误判率百万分一即10个误判BloomFilterString bf BloomFilter.create(Funnels.stringFunnel(Charset.defaultCharset()), 1000 * 10000, 0.0000001d);for (int i 0; i 1000 * 10000; i) {String skc UUID.randomUUID().toString();set.add(skc);list.add(skc);bf.put(skc);}System.out.println(布隆内存占用 RamUsageEstimator.humanSizeOf(bf));System.out.println(set 内存占用: RamUsageEstimator.humanSizeOf(set));System.out.println(list 内存占用: RamUsageEstimator.humanSizeOf(list));}
}运行结果
可以看出1000w-skc字符串模拟skc的存储set占用最高因为要记录额外的信息hashcode用于判重list结构其次而布隆仅仅为35分之一受误判率影响当然业务场景要允许存在个别误判
三总结
昨晚上述优化后我们成功将gc时间降低到5s内
对于jvm大对象的优化我们要在于要明确大对象为什么会产生结合业务和相关技术采取最优的方式既优化了大对象也不损失性能甚至还能提速而不是八股文中的直接移除一刀切 2oom或者gc时间增长的问题并不是出现问题才排查修复我们更应该关注和监控系统空闲时水位线不要让内存慢慢的泄漏从而导致出现压死骆驼的最后一个稻草时我们才能发现那样就太慢了
