[rabbitmq-discuss] Disconnecting vs failure of a disk node and reconnecting a new one...?

[Francesco Mazzoli]

Hi Navigateur,
At Fri, 6 Jul 2012 14:13:32 -0700 (PDT),
Navigateur  wrote:
> Hi Francesco, thanks for your answer (howcome it isn't showing up in this
> google group)?

Sadly Google groups does not do 2-way mirroring of mailing lists - you can't
reply to the Google groups address. We advise to avoid the Google groups
interface anyway, since it is unreliable and outside our control.

> Can you give me an example of a durable resource creation/deletion operation
> that would benefit from a RAM node (so that I know what that means)?

Creating a queue/exchange/queue binding/vhost, stuff like that.

> If I do have a lot of these, then would I benefit from using the 3rd
> (non-wep-app) machine as a RAM node, along with the 2 (relevant web app
> containing) disc nodes?

I really can't predict this (and I don't have much experience in the difference
of performance between RAM and disc). The only reliable way for you to know is
to set up a test environment and measure.

> Also, how do I approximately calculate the maximum disk space the disc nodes
> may possibly need in the very worst case scenario, say when there are 1 Mb/s
> of messages?

I'm not sure what you are asking here - the maximum disc space needed will be
roughly the size of the messages that are being persisted. The maximum *number*
(not size) of messages that can be persisted is tied to memory anyway - there is
a 160 bytes overhead for each message persisted, which gives you > 26 million
messages with 4GB in memory. If that's not good enough, you can get around that
by using the `toke' plugin, which uses tokyocabinet as a message store.

Just to throw some additional information in that you might need, the
`vm_memory_high_watermark' and `disc_free_limit' environmental variables
regulate respectively the limit after which messages start to be persisted to
disc, and the amount of disc space that rabbit can use before starting to block
producers connections. See http://www.rabbitmq.com/configure.html for more info
on configuring rabbit.

--
Francesco * Often in error, never in doubt