<br/><br/>On Monday 8 July 2013 at 17:49, Matthias Radestock-3 [via RabbitMQ] wrote:
<br/><div class='shrinkable-quote'><br/>> Carl,
<br/>>
<br/>> thanks for the answers. A few follow-up questions...
<br/>>
<br/>> On 08/07/13 16:23, Carl Hörberg wrote:
<br/>> > On Monday 8 July 2013 at 12:19, Matthias Radestock wrote:
<br/>> > > - what entities do you want to monitor? You mention channels,
<br/>> > > consumers and declarations (presumably by that you mean exchanges,
<br/>> > > queues, and bindings). Any others?
<br/>> >
<br/>> >
<br/>> > That, plus connection count.
<br/>>
<br/>> Connection count is bounded by the available file descriptors, for which
<br/>> you can tune the limit in the O/S. I would have thought that is sufficient.
</div><br/>You're right, the global limit, but we monitor and limit individual vhost connections too. The only problem is if a user creates a lot of connections within 5 seconds, then we can't block new connections fast enough.
<br/><br/>And the way we block is suboptimal too, today we remove the password (or remove the vhost permission), but then they can't access the mgmt interface either, which confuses a lot of users.
<div class='shrinkable-quote'><br/>>
<br/>>
<br/>> > A global limit would be sufficient for the time being, just for
<br/>> > protection, so that the cluster doesn't dies before we can see who
<br/>> > has done what.
<br/>>
<br/>>
<br/>> So say rabbit enforced global limits for the numbers of channels,
<br/>> consumers, exchanges, queues and bindings. How would you go about
<br/>> picking the limits?
<br/>>
<br/>> There is nothing wrong with having lots of channels, or lots of
<br/>> consumers, or lots of exchanges, etc, etc. But if you set upper bounds
<br/>> on what rabbit can sustain for each one of them, then a rabbit which
<br/>> encounters mixed usage could still run out of memory.
</div><br/>True.. Most often it's not that complicated though. Often we can see that user uses a lot of resources, and then we contact that user and make sure that he's doing the right thing. Again, the problem we have is when customers by bugs or by other means creates a lot of something very very fast, faster than we can monitor.
<br/>>
<br/>>
<br/>> Furthermore, as you know, in the default configuration messages take up
<br/>> some residual memory even when paged to disk, which means there is less
<br/>> memory available for everything. This too makes it hard to choose any
<br/>> bounds which have a reasonable chance of working w/o being silly low.
<br/>>
<br/>True, i've seen the message index grow to many gigabytes, which is way we now monitor queue length too, but "fortunately" message queues can only grow with a couple of thousands messages per second, not millions, which is required to build a huge index.
<br/>>
<br/>>
<br/>> Since your main concern is memory exhaustion - and by that presumably
<br/>> you mean rabbit crashing because it cannot allocate any more memory,
<br/>> rather than just hitting the memory alarm and blocking publisher -
<br/>> perhaps a better - simpler and more versatile - behaviour would be for
<br/>> rabbit to block all channel, consumer and resource declarations when
<br/>> memory gets *really* tight.
<br/><br/>That would be a great solution! Or somehow "slow things down", so we have the chance to use the mgmt api and read the values before it's too late.
<div class='shrinkable-quote'><br/>>
<br/>>
<br/>>
<br/>> Regards,
<br/>>
<br/>> Matthias.
<br/>> _______________________________________________
<br/>> rabbitmq-discuss mailing list
<br/>> [hidden email] (/user/SendEmail.jtp?type=node&node=27904&i=0)
<br/>> <a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_top" rel="nofollow" link="external">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br/>>
<br/>>
<br/>> If you reply to this email, your message will be added to the discussion below: <a href="http://rabbitmq.1065348.n5.nabble.com/DOS-protection-tp27876p27904.html" target="_top" rel="nofollow" link="external">http://rabbitmq.1065348.n5.nabble.com/DOS-protection-tp27876p27904.html</a>
<br/>> To unsubscribe from DOS protection, click here (<a href="" target="_top" rel="nofollow" link="external">
<br/>> NAML (<a href="http://rabbitmq.1065348.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml" target="_top" rel="nofollow" link="external">http://rabbitmq.1065348.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml</a>)
</div><br/><br/><br/>
<br/><hr align="left" width="300" />
View this message in context: <a href="http://rabbitmq.1065348.n5.nabble.com/DOS-protection-tp27876p27906.html">Re: DOS protection</a><br/>
Sent from the <a href="http://rabbitmq.1065348.n5.nabble.com/">RabbitMQ mailing list archive</a> at Nabble.com.<br/>