• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

记一次 JVM OOM 实战优化

互联网 diligentman 4周前 (01-30) 17次浏览

刚接手的服务,正常稳定运行了很长一段时间,在大家伙收拾东西准备回家过年时,突然就抽风了。

接口失败率居高不下?

看日志!

GC overhead limit exceeded

java.lang.OutOfMemoryError:GC overhead limit exceeded

看一下JVM堆栈

sudo jmap -h流量交易eap port

eg:sudo jmap -heap 9999

很明显,是内存不够了。

我当时的第一想法就是,应该是内存泄漏!我的思路如下:

1、先入为主,因为之前处理过一次因内存泄漏导致的JVM OOM问题,所以当时高度怀疑内存泄漏。

2、导出JVM堆数据,分析、定位问题。

3、fix bug,重新部署,finish!

我按照这个思路,分析堆栈后,发现堆中有大量对象,这些对象还没来得及回收,其他线程又在申请内存,从而导致了OOM。造成问题的直接原因是业务请求量增加了,而现有的机器资源不够用。至于间接原因,下一篇文章再详细描述。

在揭开问题的谜底后,回过头想一想,如果当时能够仔细分析一下问题,或许问题会被更快解决。

事后反思:服务已经稳定正常运行了一段时间,且一个月内未修改代码和更新服务。如果是代码有问题,那么问题极大可能会在新代码上线后的几天内出现。基于这一点,基本可以排除代码问题。

线上服务出现问题,首要的任务就是尽快恢复服务可用。如果下次出现类似问题,我会选择流程一,而非流程二。

造成服务不可用的直接原因是服务请求量上升,而根本原因是由于下游服务负载过高,导致微服务调用超时,从而引起连锁反应。

下图呈现了用户发起请求到响应完成的大致流程。

为何使用image base64传输图片?

1、历史原因。

2、开发相对简单。

该如何优化?

1、提高feign请求的超时时间。

2、提高机器配置。

3、将image base64放到请求体中,减少因feign框架对参数进行拼接带来的内存开销。


程序员灯塔
转载请注明原文链接:记一次 JVM OOM 实战优化
喜欢 (0)