[rabbitmq-discuss] Possible memory leak in the management plugin

[Simon MacMullen]

On 15/07/2014 9:29PM, Pavel wrote:
> Simon MacMullen-2 wrote
>> >If running this test is not a huge effort for you, it might also be worth
>> >doing so against a nightly build - nightly builds disable detailed message
>> >stats by default, which should save a great deal of memory in your case.
> Running test is trivial, it's just the environment that needs to be setup.

Cool!

> That said, wouldn't it be same as running 3.3.4 with
> {rabbitmq_management_agent, [{force_fine_statistics, false}]} setting? We've
> been using it in production since the issue with aggregated_stats table
> growth was first discovered and the purpose of this test is to prove that
> it's fixed now, so we can turn the detailed stats ON again.

No, it's not the same.

All released versions only give you a single switch, 
force_fine_statistics (not very well named) which switches all message 
rate statistics on and off.

The next release will rename this as follows:

   {force_fine_statistics, false} -> {rates_mode, none}
   {force_fine_statistics, true}  -> {rates_mode, detailed}

but will also have a new option (which will be the default):

   {rates_mode, basic}

In this mode management will display global message rates as well as 
rates for individual channels / exchanges / queues, but not for 
combinations of those objects. So for example you'll be able to see that 
a queue is accepting 5000 msg/s and delivering 6000 msg/s, but you won't 
be able to see which exchanges those messages came from and which 
channels those messages went to; i.e. the pane labelled "Message rates 
breakdown" in the web UI.

I think those detailed message rates are fairly rarely-used (in fact I 
suspect a lot of people don't realise they exist), so it makes sense to 
disable them by default. The upside is a large saving of RAM for use 
cases like yours, and some saving of CPU.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, Pivotal