<div dir="ltr"><div><div>Hi Joshua,<br><br></div><div>Does this happen with `<span class="">rates_mode` set to `none` and tuned `collect_statistics_interval`? Like in <a href="https://bugs.launchpad.net/fuel/+bug/1510835">https://bugs.launchpad.net/fuel/+bug/1510835</a><br><br>High connection/channel churn during upgrade can cause such issues.<br><br></span></div><div>BTW, soon-to-be-released rabbitmq 3.6.3 contains several improvements related to management plugin statistics handling. And almost every version before that also contained some related fixes. And I think that upstream devs response will have some mention of upgrade =)<br><br>Best,<br></div></div>Alexey<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 5, 2016 at 8:02 PM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi ops and dev-folks,<br>
<br>
We over at godaddy (running rabbitmq with openstack) have been hitting a issue that has been causing the `rabbit_mgmt_db` consuming nearly all the processes memory (after a given amount of time),<br>
<br>
We've been thinking that this bug (or bugs?) may have existed for a while and our dual-version-path (where we upgrade the control plane and then slowly/eventually upgrade the compute nodes to the same version) has somehow triggered this memory leaking bug/issue since it has happened most prominently on our cloud which was running nova-compute at kilo and the other services at liberty (thus using the versioned objects code path more frequently due to needing translations of objects).<br>
<br>
The rabbit we are running is 3.4.0 on CentOS Linux release 7.2.1511 with kernel 3.10.0-327.4.4.el7.x86_64 (do note that upgrading to 3.6.2 seems to make the issue go away),<br>
<br>
# rpm -qa | grep rabbit<br>
<br>
rabbitmq-server-3.4.0-1.noarch<br>
<br>
The logs that seem relevant:<br>
<br>
```<br>
**********************************************************<br>
*** Publishers will be blocked until this alarm clears ***<br>
**********************************************************<br>
<br>
=INFO REPORT==== 1-Jul-2016::16:37:46 ===<br>
accepting AMQP connection <0.23638.342> (<a href="http://127.0.0.1:51932" rel="noreferrer" target="_blank">127.0.0.1:51932</a> -> <a href="http://127.0.0.1:5671" rel="noreferrer" target="_blank">127.0.0.1:5671</a>)<br>
<br>
=INFO REPORT==== 1-Jul-2016::16:37:47 ===<br>
vm_memory_high_watermark clear. Memory used:29910180640 allowed:47126781542<br>
```<br>
<br>
This happens quite often, the crashes have been affecting our cloud over the weekend (which made some dev/ops not so happy especially due to the july 4th mini-vacation),<br>
<br>
Looking to see if anyone else has seen anything similar?<br>
<br>
For those interested this is the upstream bug/mail that I'm also seeing about getting confirmation from the upstream users/devs (which also has erlang crash dumps attached/linked),<br>
<br>
<a href="https://groups.google.com/forum/#!topic/rabbitmq-users/FeBK7iXUcLg" rel="noreferrer" target="_blank">https://groups.google.com/forum/#!topic/rabbitmq-users/FeBK7iXUcLg</a><br>
<br>
Thanks,<br>
<br>
-Josh<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Best,<div>Alexey</div></div></div>
</div></div>