[rabbitmq-discuss] Per-Connection Flow Control - RMQ 2.8.1
DawgTool
dawgtool at aol.com
Wed Apr 25 15:41:57 BST 2012
Hi Matthias,
I haven't run these same tests on 2.7.1 yet, since its our production
machines (which are currently stable... enough).
The spiking and the locking is not unusual? ;)
Maybe the large gaps between queue memory and actual memory is not
unusual also? ;)
Maybe the flat queue sizes for several seconds while hundreds of
thousands of records are added and purged? ;)
All joking aside.... =)
When RabbitMQ is cleaning its index/journals and data files, the queues
are all locked. Cleansing a queue could take several seconds/minutes
depending on the volume. The current flow control {200,50} hides a lot
of this, since you will not reach a large enough volume to cause a long
enough 'purge' to notice.
On my test machine, all the non-persistent messages were dropped to disk
(causing a lock) around 4GB every time. On smaller systems, its usually
around 1.5 to 2GB. This happens regardless of any settings on rabbitmq
or mnesia (unless I missed something).
A work around I have tried which works (up until the 'purge'), was to
mount the mnesia directory on a RAM disk and change the message to be
persistent (instead of non). This fixed the 4GB lock, since everything
is on disk as its received (with a slight delay).
Thanks
On 4/25/12 7:12 AM, Matthias Radestock wrote:
> On 23/04/12 14:54, DawgTool wrote:
>> Here are some stats on a few runs, modifying the flow control limits.
>> Attached is some graphs I created to show the memory consumption.
>
> I cannot see anything particularly unusual in those graphs.
>
> The original problem you reported was that you saw lower rates in
> 2.8.1 than previous releases. Simon previously asked
> <quote>
> Do you have a message rate for your use case that leads to *stable*
> memory use in 2.7.1 but which cannot be maintained by 2.8.1?
> </quote>
>
>
> Regards,
>
> Matthias.
More information about the rabbitmq-discuss
mailing list