case-内存溢出

目录

 

一、事件背景

二、分析过程

三、紧急处理措施

四、发现问题及后续TODO

---

 

一、事件背景

多个服务突发连接超时报警，迅速查看报警原因发现是因为一个rpc服务的所有接口请求都超时了。

二、分析过程

发生事故这个服务不是由本人负责而是帮助组内其他小伙伴排查的问题。虽然不是我负责的服务但是由于是组内的服务并且经常会和这个服务打交道所以运行状况基本了解。）注：由于该文章是事后一个月写的所以部分指标和证据已经找不到了，大家自己想象一下吧。有些图片涉及到公司机密所以也屏蔽了。

1.首先怀疑可能QPS突然升高导致

喵了一眼qps，发现整体QPS和接口QPS都很正常，同比环比都很正常。

【此处应该有图】

2.怀疑感觉可能是GC搞得鬼或者是网络原因

查看服务的GC情况，发现老年代利用率都在同一时间内迅速增大然后触发CMS开始回收老年代，STW时间过长导致请求都超时了。

与此同时内存溢出的报警也报了出来。这时服务负责人有点慌了，要求重启服务。由于服务的内存在gc之后会降下去而且此时因为服务器比较多所以还能勉强的对外提供服务贸然重启可能会导致其他服务器压力更大，所以我提出了在观察一下的建议。

【此处应该有图】

3.分析一下Dump

发现其实这个服务并没有指定-XX:+HeapDumpOnOutOfMemoryError参数，一脸懵逼。让同事对一台机器进行dump的同时我去搜集其他信息。

4.怀疑最近上线了那种不可描述的代码

看了一下发版记录服务最近都没有发版。

5.分析一下内存溢出异常

去服务器看了一下内存溢出的报错并简单统计了一下内存溢出的堆栈信息和上下文日志，发现了有价值的信息：

 

惊人的发现多达60+次的内存溢出竟然是调用同一个接口对同一个资源的操作引起的。定位到该资源发现这是一个10M大的图片。看了一下业务代码服务器会下载该图片并进行处理处理过程总经过多次转换然后膨胀为自身的2-3倍。然后又统计了一下所有针对该资源的操作在同一时刻内竟然有几千次请求。基本确定原因。然而此时dump居然还没完事。

【此处应该有图，自己想象】

【此处应该有图，但是涉密】

三、紧急处理措施

之前提到了同事提出马上重启服务器，但是由于当时还能勉强对外提供服务，我建议先观察一下，如果盲目的重启可能会导致其他服务的压力更大，导致当前负责的服务产生更严重的后果。

既然查到了原因那就比较好处理了。查找接口调用方，确定非调用方核心业务而且使用率较低，确认禁止调用后产生影响可控。之后将该调用方加入黑名单直接拒绝服务。保证核心业务稳定。随后服务各项指标开始稳定。

四、发现问题及后续TODO

1.同一个资源同一时刻上千次调用

首先作为一个基础服务提供者，没有进行限流和降级这些基础的保障是不对的。这些都是后续需要完善的。

2.为什么这么大的图片读入内存

经过后续排查确定调用方没有对图片进行压缩导致图片过大。而且发现服务端虽然限制了图片大小，但是图片的大小限制逻辑有问题，而且限制范围过大是10M。应该接口应先调用API判断文件大小而不是将文件下载下来在内存中计算大小。

3.这接口的服务参数明显有问题

具体的接口服务参数应该根据设置的最大图片大小和接口可并发处理数量来计算确定而不是凭感觉给一个数值。如果服务参数是根据正确的方法计算的那么在大量请求来袭处理能力不足会直接拒绝请求，而不会影响服务其他接口的稳定性。

4.为啥没有dump

JVM启动参数加入-XX:+HeapDumpOnOutOfMemoryError以便在发生问题时可以快速拿到dump进行分析。

 

 

----------------------------------------------------

欢迎大家提出指导性的意见