[rabbitmq-discuss] RabbitMQ configuration

[Matthew Sackman]

Hi Roaan,

On Thu, May 13, 2010 at 06:57:19AM +0200, Roaan Vos wrote:
> We've been having problems with RabbitMQ just "hanging".
> This is with the default installation, i.e no configuration.

It's likely you've run out of memory and Rabbit's raised the
channel.flow flag, preventing you from publishing more messages to it.
Check the logs for memory high watermark warnings. This issue is fixed
with the new persister branch as messages can be sent to disk and
forgotten from RAM.

> Can any one help with a configuration file or point me to where I can find
> information on how to configure RabbitMQ.

There's not a great deal you can do to fix this issue other than
compiling from source with the new persister branch (bug21673), or
installing much more memory.

> We're running RabbitMQ 1.7.2 on a single node on Windows 2008 Server.

Windows is a bad idea because there is no 64-bit Erlang available. As
such, it doesn't matter how much RAM you have installed, only 2GB will
be available to Rabbit. If you need to use Windows then your only
solution will be to use the new persister branch (but compiling under
Windows is involved to say the least - you'll need to start with
cygwin). Really we'd recommend a Linux server here.

That said, all my assumptions may be totally wrong - how many messages
(and what size) are you buffering in Rabbit? Are you correctly acking
messages when you're consuming them?

> Also we're aiming on having about 10 thousand clients (connections) each
> with their own queue. (Using Topics)
> Is this feasable?

Connections - yes. You will probably need to raise the process limit -
about a million should be fine. Under non-Windows this would involve
putting SERVER_START_ARGS="+P 1048576" into the rabbitmq.conf file
(which normally lives under /etc/rabbitmq). However, because of lack of
features of Windows BAT files, there is no such .conf file, so you need
to set the environment variable RABBITMQ_SERVER_START_ARGS and set the
value to "+P 1048576". That should do the trick.

Topic exchanges are inefficient in our current implementation. It's not
normally necessary to use them either - unless your domain of routing
keys really is unbounded. Can you describe more about your use case and
we should be able to advise you further.

Matthew