线上服务OOM解决记录

 

     最近线上运行的两个服务都出现了oom的情况，具体的报错在于线程池创建线程时 内存不够用导致服务假死。 实际追查过程中才发现问题根本不是内存泄露，而是对于部分参数的设置存在问题。因此记录一下查找问题的过程。

    1,第一时间发现线上部分请求出现超时不回包的问题，发现服务里面存在oom的情况，  查看代码的部署记录，  服务线上部署了5个节点，并且已经正常运行了2个月，其它4个节点正常运行。从nginx上，将服务节点放下来，然后分析问题。

    2,dump出内存堆栈信息，通过jhat分析堆栈信息，发现内存当中存在大量的vertx  web框架的Context对象，初步怀疑是vertx web框架的内存泄露导致的问题。（因为这个诊断导致走了弯路）

  怀疑1 ：  vertx web框架存在问题 

   3, 对vertx web框架做了压测，发现vertx web没有存在内存泄露的问题。

   4, 查看了vertx web框架中出现内存泄露的上线问信息。发现一个问题点，  vertx web的work线程队列是与socket绑定的，怀疑可能是nginx反向代理的时候，是开启了keepavliede， 可能会导致同一时间的所有请求都发送到一个work线程上，导致内存溢出。

   怀疑2 ：  怀疑vertx web框架的work线程分配有问题，同一个socket大量请求会堵塞线程队列。（从实际上看，这种怀疑是站不住脚的，以内http协议，即使开通了keepalive，一个socket也是一个一个请求-应答，不会同时传递多个请求过来）。