TThreadedSelectorServer介绍及Direct Memory OOM分析

一、TThreadedSelectorServer线程模型:

该服务会启动1个AcceptThread, 2个SelectorThread(默认为2个,可设置),一个woker线程池(池的大小可设置),

    一个AcceptThread执行accept操作,将accept到的Transport交给SelectorThread线程, AcceptThread中有个balance均衡器分配到SelectorThread;

    SelectorThread执行read,write操作,read到一个FrameBuffer(封装了方法名,参数,参数类型等数据,和读取写入,调用方法的操作)交给WorkerProcess线程池执行方法调用。

二、SelectorThread中FrameBuffer读取的过程

    每个SelectorThread线程使用FrameBuffer来读取数据。

org.apache.thrift.server.AbstractNonblockingServer.FrameBuffer:

    private boolean internalRead() {
      try {
        if (trans_.read(buffer_) < 0) {
          return false;
        }
        return true;
      } catch (IOException e) {
        LOGGER.warn("Got an IOException in internalRead!", e);
        return false;
      }
    }

代码中trans 为 TNonblockingSocket对象,

org.apache.thrift.transport.TNonblockingSocket:

  public int read(ByteBuffer buffer) throws IOException {
    return socketChannel_.read(buffer);
  }

实际上就是,从socketChannel中读取数据到FrameBuffer的buffer_ (堆内存) 变量中。

socketChannel的read方法中参数传的就是FrameBuffer的buffer_变量。

public int read(ByteBuffer var1)  // var1 即为FrameBuffer的buffer_变量

socketChannel在读取数据到FrameBuffer.buffer_的过程中,使用了sun.nio.ch.Util 和 sun.nio.ch.IOUtil 类来分配临时的直接内存,来实现数据的读取。

   sun.nio.ch.Util 类中持有一个线程内的环形缓存区,元素为分配的DirectByteBuffer,每次进行read和write时先从该缓存中拿DirectByteBuffer,条件是其中的DirectByteBuffer的size大于或等于需要的size。

    如果没有满足条件的元素,则创建新的DirectByteBuffer,新的使用完后再放回环形缓存区,如果此时缓存区已满则,则释放该DirectByteBuffer:

sun.nio.ch.Util:  

小结:

    Frame读取数据分两步: 先读取frame的size大小,再读取整个frame的数据

  1. 读取frameSize(4个字节):   先分配4个字节的堆内存,然后从socketChannel中读取4个字节的数据,过程中从环形缓冲区中产生了或复用了一个字节长度大于等于4的直接内存。
  2. 读取整个frame数据:  先分配(4 + frameSize)大小的堆内存,接着将frameSize(4个字节)这个int值放入分配的堆内存中,然后从socketChannel中读取一个字节长度为frameSize的数据,同样从socketChannel中读取,过程中从环形缓冲区中产生了或复用了一个字节长度大于等于frameSize的直接内存。

三、java.lang.OutOfMemoryError: Direct buffer memory 分析

 监控分析工具介绍:

        1. 调整JVM启动参数,如下:

                -Dcom.sun.management.jmxremote.port=9988 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -XX:+PrintGC -XX:+HeapDumpBeforeFullGC -XX:+HeapDumpAfterFullGC

            开启JMX服务,可实现远程通过jconsole.exe 和 jvisualvm.exe 来监控JVM的性能参数,其中jconsole可看到堆外内存的使用情况(使用了BufferPoolMXBean);

            开启了JVM做full gc前后做一次dump操作,用于分析堆内存的使用。

        2.另外使用Oracle官网上找到的MonBuffers 类来实时监控堆外内存的使用, 代码见附录;

        3. Memory Analysis工具用于分析dump文件;

        3.tcpdump,wireshake分别用于捕获和分析Thrift服务接收到的字节流。

OOM问题分析过程:

    在监控的过程中,发现某个时间点堆外内存急剧上升达到1个多G,

    此时jvm做了一次full gc并做了dump操作:

    用Memory Analysis 对 java_pid27220.hprof.2 dump文件进行分析

    发现在SelectorThread中一个大的字节数组, 长度为1195725860字节,根据对代码的分析,这个字节数组中的数据正是从直接内存读取出来的,这和直接内存激增吻合。

    接下来分析这个大的byte[]中的内容:

发现是一个http的get请求数据,就此猜测可能由于Thrfit服务收到http get请求导致内存激增,

重新启动一个Thrift服务,通过浏览器发送一个http get请求,复现了这个问题

并且最后直接内存的字节数也为1195725860和堆中的byte[]长度吻合。

将1195725860减去4等于1195725856,转成16进制等于0x47455420, 

通过tcpdump和wireshake分析Thrfit服务收到的http get请求字节包

这个4个字节吻合,证实直接内存激增是由于Thrfit收到http get包导致的。

    那为什么会出现OOM呢,我们的JVM参数中有 -XX:MaxDirectMemorySize=2048M, 直接内存是2G。

当同一个SelectorThread收到多次http get请求会复用环形缓存区中的DirectByteBuffer,所以不会导致直接内存的OOM,但是我们默认是2个SelectorThread,则当2个SelectorThread都收到http get请求则,直接内存会达到1195725860×2=2391451720 > 2G

总结:

    这次的OOM问题是由于Thrift服务收到HTTP get请求导致, 这应该算Thrift的一个漏洞吧,至于解决方法,Thrfit好像有限制包长度的参数,有待继续研究。

问题已解决,解决方案如下链接:

http://my.oschina.net/shipley/blog/467670

四、附录:

MonBuffers 类:

import java.io.File;

import java.lang.management.BufferPoolMXBean;

import java.lang.management.ManagementFactory;

import java.text.DateFormat;

import java.text.SimpleDateFormat;

import java.util.ArrayList;

import java.util.Date;

import java.util.List;

import java.util.Set;

import javax.management.MBeanServerConnection;

import javax.management.ObjectName;

import javax.management.remote.JMXConnector;

import javax.management.remote.JMXConnectorFactory;

import javax.management.remote.JMXServiceURL;

// Attach API

import com.sun.tools.attach.VirtualMachine;

/**

 * Simple tool to attach to running VM to report buffer pool usage.

 */

public class MonBuffers {

    static final String CONNECTOR_ADDRESS =

          "com.sun.management.jmxremote.localConnectorAddress";

    public static void main(String args[]) throws Exception {

        // attach to target VM to get connector address

        VirtualMachine vm = VirtualMachine.attach(args[0]);

        String connectorAddress = vm.getAgentProperties().getProperty(CONNECTOR_ADDRESS);

        if (connectorAddress == null) {

            // start management agent

            String agent = vm.getSystemProperties().getProperty("java.home") +

                    File.separator + "lib" + File.separator + "management-agent.jar";

            vm.loadAgent(agent);

            connectorAddress = vm.getAgentProperties().getProperty(CONNECTOR_ADDRESS);

            assert connectorAddress != null;

        }

        // connect to agent

        JMXServiceURL url = new JMXServiceURL(connectorAddress);

        JMXConnector c = JMXConnectorFactory.connect(url);

        MBeanServerConnection server = c.getMBeanServerConnection();

        // get the list of pools

        Set<ObjectName> mbeans = server.queryNames(

            new ObjectName("java.nio:type=BufferPool,*"), null);

        List<BufferPoolMXBean> pools = new ArrayList<BufferPoolMXBean>();

        for (ObjectName name: mbeans) {

            BufferPoolMXBean pool = ManagementFactory

                .newPlatformMXBeanProxy(server, name.toString(), BufferPoolMXBean.class);

            pools.add(pool);

        }

        // print headers

        for (BufferPoolMXBean pool: pools)

            System.out.format("         %18s             ", pool.getName());

        System.out.println();

        System.out.format("%20s", "timestamp");

        for (int i=0; i<pools.size(); i++)

            System.out.format("%6s %10s %10s  ",  "Count", "Capacity", "Memory");

        System.out.println();

        DateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

        // poll and print usage

        for (;;) {

            System.out.format("%10s", df.format(new Date()));

            for (BufferPoolMXBean pool: pools) {

                System.out.format("%6d %10d %10d  ", 

                    pool.getCount(), pool.getTotalCapacity(), pool.getMemoryUsed());

            }

            System.out.println();

            Thread.sleep(2000);

        }

    }

}

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏jianhuicode

js与android webview交互

0x01 js调用java代码 android webview中支持通过添加js接口 webview.addJavascriptInterface(new Js...

24150
来自专栏向治洪

ormlite介绍一

概述 ORMlite是类似hibernate的对象映射框架,主要面向java语言,同时,是时下最流行的android面向数据库的的编程工具。 官方网站:http...

22160
来自专栏pangguoming

Android Data Binding(数据绑定)用户指南

1)介绍 这篇文章介绍了如何使用Data Binding库来写声明的layouts文件,并且用最少的代码来绑定你的app逻辑和layouts文件。 Data B...

42980
来自专栏大内老A

ASP.NET MVC的View是如何被呈现出来的?[设计篇]

在前面的四篇文章中,我们介绍了各种ActionResult以及相关的请求响应机制,但是与“View的呈现”相关的ActionResult是ViewResult。...

37480
来自专栏码匠的流水账

聊聊spring cloud的RequestHeaderToRequestUriGatewayFilter

本文主要研究一下spring cloud的RequestHeaderToRequestUriGatewayFilter

11910
来自专栏pangguoming

完全掌握Android Data Binding

编辑推荐:稀土掘金,这是一个针对技术开发者的一个应用,你可以在掘金上获取最新最优质的技术干货,不仅仅是Android知识、前端、后端以至于产品和设计都有涉猎,想...

63870
来自专栏androidBlog

Android 常用工具类

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/gdutxiaoxu/article/de...

20110
来自专栏小樱的经验随笔

Codeforces 839E Mother of Dragons【__builtin_popcount()的使用】

E. Mother of Dragons time limit per test:2 seconds memory limit per test:256 meg...

27780
来自专栏开发技术

spring-boot-2.0.3不一样系列之源码篇 - springboot源码一,绝对有值得你看的地方

  上篇:spring-boot-2.0.3不一样系列之shiro - 搭建篇,实现了spring-boot与shiro的整合,效果大家也看到了,工程确实集成了...

55420
来自专栏郭霖

Android图片加载框架最全解析(二),从源码的角度理解Glide的执行流程

在本系列的上一篇文章中,我们学习了Glide的基本用法,体验了这个图片加载框架的强大功能,以及它非常简便的API。还没有看过上一篇文章的朋友,建议先去阅读 An...

724100

扫码关注云+社区

领取腾讯云代金券