一、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:
1
2
3
4
5
6
7
8
9
10
11
|
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:
1
2
3
|
public
int
read(ByteBuffer buffer)
throws
IOException {
return
socketChannel_.read(buffer);
}
|
实际上就是,从socketChannel中读取数据到FrameBuffer的buffer_ (堆内存) 变量中。
socketChannel的read方法中参数传的就是FrameBuffer的buffer_变量。
1
|
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的数据
- 读取frameSize(4个字节): 先分配4个字节的堆内存,然后从socketChannel中读取4个字节的数据,过程中从环形缓冲区中产生了或复用了一个字节长度大于等于4的直接内存。
- 读取整个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文件;
4. 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进制等于0×47455420,
通过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 类:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
|
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
);
}
}
}
|