重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
这篇文章主要讲解了“如何优化JVM OOM”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“如何优化JVM OOM”吧!
创新互联是一家集网站建设,石狮企业网站建设,石狮品牌网站建设,网站定制,石狮网站建设报价,网络营销,网络优化,石狮网站推广为一体的创新建站企业,帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿,时刻以成就客户成长自我,坚持不断学习、思考、沉淀、净化自己,让我们为更多的企业打造出实用型网站。
刚接手的服务,正常稳定运行了很长一段时间,在大家伙收拾东西准备回家过年时,突然就抽风了。
接口失败率居高不下?
看日志!
GC overhead limit exceeded
java.lang.OutOfMemoryError:GC overhead limit exceeded
看一下JVM堆栈
sudo jmap -heap port
#eg:sudo jmap -heap 9999
很明显,是内存不够了。
我当时的第一想法就是,应该是内存泄漏!我的思路如下:
1、先入为主,因为之前处理过一次因内存泄漏导致的JVM OOM问题,所以当时高度怀疑内存泄漏。
2、导出JVM堆数据,分析、定位问题。
3、fix bug,重新部署,finish!
我按照这个思路,分析堆栈后,发现堆中有大量对象,这些对象还没来得及回收,其他线程又在申请内存,从而导致了OOM。造成问题的直接原因是业务请求量增加了,而现有的机器资源不够用。至于间接原因,下一篇文章再详细描述。
在揭开问题的谜底后,回过头想一想,如果当时能够仔细分析一下问题,或许问题会被更快解决。
事后反思:服务已经稳定正常运行了一段时间,且一个月内未修改代码和更新服务。如果是代码有问题,那么问题极大可能会在新代码上线后的几天内出现。基于这一点,基本可以排除代码问题。
线上服务出现问题,首要的任务就是尽快恢复服务可用。如果下次出现类似问题,我会选择流程一,而非流程二。
造成服务不可用的直接原因是服务请求量上升,而根本原因是由于下游服务负载过高,导致微服务调用超时,从而引起连锁反应。
下图呈现了用户发起请求到响应完成的大致流程。
业务服务接口和算法服务接口使用eureka作为服务注册中心,整体来说,这个服务采用相对简单的微服务架构。
服务接口搭配feign来请求算法服务接口。
@FeignClient(value = "image-service")
public interface ImageService {
@PostMapping(value = "/XXX")
String XXX(@RequestParam("img_base64") String imgBase64);
}
上面的代码在执行请求的时候,会将请求参数进行拼接。
image-service/xxx?img_base64=fjsfdgldfgrwdfdmgfdglwefsl
当eureka真正确定请求的服务地址后,又会再做一次拼接处理。
127.0.0.1:5000/xxx?img_base64=fjsfdgldfgrwdfdmgfdglwefsl
算法服务接口的处理时间与图片的大小正相关,图片越大,处理时间越长。由于处理图片是一个相对耗时的操作,接口会出现超时的情况。如果请求失败(超时),那么feign会进行重试。
图片base64字符串的长度与图片大小呈正相关关系,图片越大,base64字符串长度越长。一张306K的图片,转成base64格式后,字符串长度为429196。
因此处理一次正常的请求消耗的内存比较大。图片越大,算法处理时间越久,超时失败后,feign重试,重试之后又失败,导致一个恶性循环(幸好有超时次数限制,否则如此递归下去,后果不堪设想)。
如图是JVM OOM后拿到堆栈的数据,最大的图片base64的大小有5M。
jdk1.8 JVM参数PretenureSizeThreshold的默认值是2M。
当base64字符串超过2M时,会直接分配到老年代,这无疑加大了JVM老年代的内存压力,导致频繁Full GC。
为何使用image base64传输图片?
1、历史原因。
2、开发相对简单。
该如何优化?
1、提高feign请求的超时时间。
2、提高机器配置。
3、将image base64放到请求体中,减少因feign框架对参数进行拼接带来的内存开销。
感谢各位的阅读,以上就是“如何优化JVM OOM”的内容了,经过本文的学习后,相信大家对如何优化JVM OOM这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!