码迷,mamicode.com
首页 > 其他好文 > 详细

rabbitmq binary/other_system内存占用很高

时间:2016-12-10 16:25:39      阅读:1475      评论:0      收藏:0      [点我收藏+]

标签:内存   use   ges   控制   in-memory   dex   客户端   sse   style   

最近有台服务器的MQ应用占用内存比较偏高,如下:

技术分享

但是看控制台本身内存中消息积压并不多,

技术分享

 

查看rabbtmqctl发现,binary data和other data占据了绝大部分的内存,如下:

{memory,
[{total,124441400},
{connection_readers,5548680},
{connection_writers,605560},
{connection_channels,2798608},
{connection_other,7775480},
{queue_procs,23561696},
{queue_slave_procs,0},
{plugins,489128},
{other_proc,14147408},
{mnesia,2040288},
{mgmt_db,9741144},
{msg_index,1946696},
{other_ets,2006528},
{binary,420491264},
{code,20160575},
{atom,711569},
{other_system,323416776}]},

binary(Memory used by shared binary data in the Erlang VM. In-memory message bodies show up here.)代表的是内存中的消息以及其他一些被queue或者exchange引用的元数据,但是在控制台里面有没有任何体现。

other_system:

Other memory used by Erlang. One contributor to this value is the number of available file descriptors。

看mq日志,发现服务器负载高导致响应慢或者OOM被killed之后,虽然进程本身还在,但收不到有些客户端的心跳,类似如下:

Missed heartbeats from client, timeout: 10s
Missed heartbeats from client, timeout: 10s
Missed heartbeats from client, timeout: 10s
Missed heartbeats from client, timeout: 10s
Missed heartbeats from client, timeout: 10s

跟应用的原开发者确认了下,有些客户端在异常后会不断的尝试重新连接MQ服务器,但是连接都建立了,但是随后心跳就异常了。

照理来说,MQ强制断开客户端连接后,相关的socket和内存占用会随之释放,但是出现异常的时候内存占用一直都很高、而且一两个小时后也没有下降到正常水平。

重启两个java应用后,MQ内存占用就立刻下来了,但是连接数和消费者数量和原来都一样。

这现象似乎和我们原来mysql出现的异常一样,服务端在某些地方可能存在非最常用特性被极为频繁的使用后,可能导致内存存在泄露的情况。

因为之前出现过两三次行情初始化和成交回报丢失的情况,所以趁着这次测试环境的异常大概找到了出现问题的规律,后续会在深入研究下rabbitMQ的binary和other_system里面到底是什么数据,这就又涉及到要分析erlang VM的内存dump才能精确确定了。

rabbitmq binary/other_system内存占用很高

标签:内存   use   ges   控制   in-memory   dex   客户端   sse   style   

原文地址:http://www.cnblogs.com/zhjh256/p/6155725.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!