记一次内存溢出的分析经历——使用thrift-低调大师

记一次内存溢出的分析经历——使用thrift

2018-03-06 552

背景：

有一个项目做一个系统，分客户端和服务端，客户端用c++写的，用来收集信息然后传给服务端（客户端的数量还是比较多的，正常的有几千个），

服务端用Java写的（带管理页面），属于RPC模式，中间的通信框架使用的是thrift。

thrift很多优点就不多说了，它是facebook的开源的rpc框架，主要是它能够跨语言，序列化速度快，但是他有个不讨喜的地方就是它必须用自己IDL来定义接口

thrift版本：0.9.2.

问题定位与分析

步骤一.初步分析

客户端无法连接服务端，查看服务器的端口开启状况，服务端口并没有开启。于是启动服务端，启动几秒后，服务端崩溃，重复启动，服务端依旧在启动几秒后崩溃。

步骤二.查看服务端日志分析

分析得知是因为java.lang.OutOfMemoryError: Java heap space（堆内存溢出）导致的服务崩溃。

客户端搜集的主机信息，主机策略都是放在缓存中，可能是因为缓存较大造成的，但是通过日志可以看出是因为Thrift服务抛出的堆内存溢出异常与缓存大小无关。

步骤三.再次分析服务端日志

可以发现每次抛出异常的时候都会伴随着几十个客户端在向服务端发送日志，往往在发送几十条日志之后，服务崩溃。可以假设是不是堆内存设置的太小了？

查看启动参数配置，最大堆内存为256MB。修改启动配置，启动的时候分配更多的堆内存，改成java -server -Xms512m -Xmx768m。

结果是，能坚持多一点的时间，依旧会内存溢出服务崩溃。得出结论，一味的扩大内存是没有用的。

**为了证明结论是正确的，做了这样的实验：**
> 内存设置为256MB，在公司服务器上部署了服务端，使用Java VisualVM远程监控服务器堆内存。
>
> 模拟客户现场，注册3000个客户端，使用300个线程同时发送日志。
>
> 结果和想象的一样，没有出现内存溢出的情况，如下图：

> 上图是Java VisualVM远程监控，在压力测试的情况下，没有出现内存溢出的情况，256MB的内存肯定够用的。

步骤四.回到thrift源码中，查找关键问题

服务端采用的是Thrift框架中TThreadedSelectorServer这个类，这是一个NIO的服务。下图是thrift处理请求的模型：

**说明：**
>一个AcceptThread执行accept客户端请求操作，将accept到的Transport交给SelectorThread线程，
>
>AcceptThread中有个balance均衡器分配到SelectorThread；SelectorThread执行read，write操作，
>
>read到一个FrameBuffer（封装了方法名，参数，参数类型等数据，和读取写入，调用方法的操作）交给WorkerProcess线程池执行方法调用。
>
>**内存溢出就是在read一个FrameBuffer产生的。**

步骤五.细致一点描述thrift处理过程

>1.服务端服务启动后，会listen()一直监听客户端的请求，当收到请求accept()后，交给线程池去处理这个请求
>
>2.处理的方式是：首先获取客户端的编码协议getProtocol（），然后根据协议选取指定的工具进行反序列化，接着交给业务类处理process（）
>
>3.process的顺序是，**先申请临时缓存读取这个请求数据**，处理请求数据，执行业务代码，写响应数据,**最后清除临时缓存**
>
> **总结：thrift服务端处理请求的时候，会先反序列化数据，接着申请临时缓存读取请求数据，然后执行业务并返回响应数据，最后请求临时缓存。**
>
> 所以压力测试的时候，thrift性能很高，而且内存占用不高，是因为它有自负载调节，使用NIO模式缓存，并使用线程池处理业务，每次处理完请求之后及时清除缓存。

步骤六.研读FrameBuffer的read方法代码

可以排除掉没有及时清除缓存的可能，方向明确，极大的可能是在申请NIO缓存的时候出现了问题，回到thrift框架，查看FrameBuffer的read方法代码：

 
         public 
         boolean 
         read() {　　　　　　　　 
         // try to read the frame size completely  
        
         if 
         (
         this
         .state_ == AbstractNonblockingServer.FrameBufferState.READING_FRAME_SIZE) { 
        
         if 
         (!
         this
         .internalRead()) { 
        
         return 
         false
         ; 
        
         } 
        
         // if the frame size has been read completely, then prepare to read the actual time 
        
         if 
         (
         this
         .buffer_.remaining() != 
         0
         ) { 
        
         return 
         true
         ; 
        
         } 
        
         int 
         frameSize = 
         this
         .buffer_.getInt(
         0
         ); 
        
         if 
         (frameSize <= 
         0
         ) { 
        
         this
         .LOGGER.error(
         "Read an invalid frame size of " 
         + frameSize + 
         ". Are you using TFramedTransport on the client side?"
         ); 
        
         return 
         false
         ; 
        
         } 
        
         // if this frame will always be too large for this server, log the error and close the connection.

 
         if 
         ((
         long
         )frameSize > AbstractNonblockingServer.
         this
         .MAX_READ_BUFFER_BYTES) { 
        
         this
         .LOGGER.error(
         "Read a frame size of " 
         + frameSize + 
         ", which is bigger than the maximum allowable buffer size for ALL connections."
         ); 
        
         return 
         false
         ; 
        
         } 
        
         if 
         (AbstractNonblockingServer.
         this
         .readBufferBytesAllocated.get() + (
         long
         )frameSize > AbstractNonblockingServer.
         this
         .MAX_READ_BUFFER_BYTES) { 
        
         return 
         true
         ; 
        
         } 
        
         AbstractNonblockingServer.
         this
         .readBufferBytesAllocated.addAndGet((
         long
         )(frameSize + 
         4
         )); 
        
         this
         .buffer_ = ByteBuffer.allocate(frameSize + 
         4
         ); 
        
         this
         .buffer_.putInt(frameSize); 
        
         this
         .state_ = AbstractNonblockingServer.FrameBufferState.READING_FRAME; 
        
         } 
        
         if 
         (
         this
         .state_ == AbstractNonblockingServer.FrameBufferState.READING_FRAME) { 
        
         if 
         (!
         this
         .internalRead()) { 
        
         return 
         false
         ; 
        
         } 
         else 
         { 
        
         if 
         (
         this
         .buffer_.remaining() == 
         0
         ) { 
        
         this
         .selectionKey_.interestOps(
         0
         ); 
        
         this
         .state_ = AbstractNonblockingServer.FrameBufferState.READ_FRAME_COMPLETE; 
        
         } 
        
         return 
         true
         ; 
        
         } 
        
         } 
         else 
         { 
        
         this
         .LOGGER.error(
         "Read was called but state is invalid (" 
         + 
         this
         .state_ + 
         ")"
         ); 
        
         return 
         false
         ; 
        
         } 
        
         }

**说明：**
>MAX_READ_BUFFER_BYTES这个值即为对读取的包的长度限制，如果超过长度限制，就不会再读了/
>
>这个MAX_READ_BUFFER_BYTES是多少呢，thrift代码中给出了答案：

 
         public 
         abstract 
         static 
         class 
         AbstractNonblockingServerArgs<T 
         extends 
         AbstractNonblockingServer.AbstractNonblockingServerArgs<T>> 
         extends 
         AbstractServerArgs<T> {<br>　　　　　 
        
         public 
         long 
         maxReadBufferBytes = 9223372036854775807L; 
        
         public 
         AbstractNonblockingServerArgs(TNonblockingServerTransport transport) { 
        
         super
         (transport); 
        
         this
         .transportFactory(
         new 
         Factory()); 
        
         } 
        
         }

>从上面源码可以看出，默认值居然给到了long的最大值9223372036854775807L。

所以thrift的开发者是觉得使用thrift程序员不够觉得内存不够用吗，这个换算下来就是1045576TB，这个太夸张了，这等于没有限制啊，所以肯定不能用默认值的。

步骤七.通信数据抓包分析

需要可靠的证据证明一个客户端通信的数据包的大小。

这个是我抓到包最大的长度，最大一个包长度只有215B，所以需要限制一下读取大小

步骤八：踏破铁鞋无觅处

在论坛中，看到有人用http请求thrift服务端出现了内存溢出的情况，所以我抱着试试看的心态，在浏览器中发起了http请求，

果不其然，出现了内存溢出的错误，和客户现场出现的问题一摸一样。这个读取内存的时候数量过大，超过了256MB。
> 很明显的一个问题，正常的一个HTTP请求不会有256MB的，考虑到thrift在处理请求的时候有反序列化这个操作。
>
> 可以做出假设是不是反序列化的问题，不是thrift IDL定义的不能正常的反序列化？
>
> 验证这个假设，我用Java socket写了一个tcp客户端，向thrift服务端发送请求，果不其然！java.lang.OutOfMemoryError: Java heap space。
> 这个假设是正确的,客户端请求数据不是用thrift IDL定义的话，无法正常序列化，序列化出来的数据会异常的大！大到超过1个G的都有。

步骤九. 找到原因

某些客户端没有正常的序列化消息，导致服务端在处理请求的时候，序列化出来的数据特别大，读取该数据的时候出现的内存溢出。

查看维护记录，在别的客户那里也出现过内存溢出导致服务端崩溃的情况，通过重新安装客户端，就不再复现了。

所以可以确定，客户端存在着无法正常序列化消息的情况。考虑到，客户端量比较大，一个一个排除，再重新安装比较困难，工作量很大，所以可以从服务端的角度来解决问题，减少维护工作量。

最后可以确定解决方案了，真的是废了很大的劲，不过也是颇有收获

问题解决方案

非常简单

在构造TThreadedSelectorServer的时候，增加args.maxReadBufferBytes = 1*1024 * 1024L;也就是说修改maxReadBufferBytes的大小，设置为1MB。

客户端与服务端通过thrift通信的数据包，最大十几K，所以设置最大1MB，是足够的。代码部分修改完成，版本不做改变**
修改完毕后，这次进行了异常流测试，发送了http请求，使服务端无法正常序列化。

服务端处理结果如下：

thrift会抛出错误日志，并直接没有读这个消息，返回false,不处理这样的请求，将其视为错误请求。

3.国外有人对thrift一些server做了压力测试，如下图所示：

使用thrift中的TThreadedSelectorServer吞吐量达到18000以上
由于高性能，申请内存和清除内存的操作都是非常快的，平均3ms就处理了一个请求。
所以是推荐使用TThreadedSelectorServer

4.修改启动脚本，增大堆内存，分配单独的直接内存。

修改为java -server -Xms512m -Xmx768m -XX:MaxPermSize=256m -XX:NewSize=256m -XX:MaxNewSize=512m -XX:MaxDirectMemorySize=128M。

设置持久代最大值 MaxPermSize:256m

设置年轻代大小 NewSize:256m

年轻代最大值 MaxNewSize:512M

最大堆外内存（直接内存）MaxDirectMemorySize：128M

5.综合论坛中，StackOverflow一些同僚的意见，在使用TThreadedSelectorServer时，将读取内存限制设置为1MB，最为合适，正常流和异常流的情况下不会有内存溢出的风险。

之前启动脚本给服务端分配的堆内存过小，考虑到是NIO，所以在启动服务端的时候，有必要单独分配一个直接内存供NIO使用.修改启动参数。

增加堆内存大小直接内存，防止因为服务端缓存太大，导致thrift服务没有内存可申请，无法处理请求。

总结：

真的是一次非常酸爽的过程，特此发个博客记录一下，如果有说的不对的对方，欢迎批评斧正！如果觉得写的不错，欢迎给我点个推荐，您的一个推荐是我莫大的动力！

微信关注我们

原文链接：https://yq.aliyun.com/articles/644699

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

spring cloud-构建微服务架构的网关(API GateWay)

spring cloud-构建微服务架构的网关(API GateWay) 前言在我们前面的博客中讲到，当服务A需要调用服务B的时候，只需要从Eureka中获取B服务的注册实例，然后使用Feign来调用B的服务，使用Ribbon来实现负载均衡，但是，当我们同时向客户端暴漏多个服务的时候，客户端怎么调用我们暴漏的服务了，如果我们还想加入安全认证，权限控制，过滤器以及动态路由等特性了，那么就需要使用Zuul来实现API GateWay了，下面，我们先来看下Zuul怎么使用。一、加入Zuul的依赖 [html] view plain copy <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zuul</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</grou...

2018-03-07

691

1.基本介绍 Restful接口的调用，前端一般使用ajax调用，后端可以使用的方法比较多，本次介绍三种： 1.HttpURLConnection实现 2.HttpClient实现 3.Spring的RestTemplate 2.HttpURLConnection实现 1 @Controller 2 public class RestfulAction { 3 4 @Autowired 5 private UserService userService; 6 7 // 修改 8 @RequestMapping(value = "put/{param}", method = RequestMethod.PUT) 9 public @ResponseBody String put(@PathVariable String param) { 10 return "put:" + param; 11 } 12 13 // 新增 14 @RequestMapping(value = "post/{param}", method = RequestMethod.POST) 15 public ...

2018-03-07

681

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。