[rabbitmq-discuss] [help] [beginner] server stops sending messages; publish (in transaction) hangs on commit
majek04 at gmail.com
Mon Feb 27 11:49:18 GMT 2012
On Mon, Feb 27, 2012 at 03:37, Alistair Bayley <alistair at abayley.org> wrote:
> On 25 February 2012 00:38, Simon MacMullen <simon at rabbitmq.com> wrote:
>>> OK. Can I have some guidance as to how much memory we should allocate?
>> This is a real how-long-is-a-piece-of-string question I'm afraid. 512M would
>> already be a significant step towards the comfort zone though.
> rabbitmqctl report shows a large number of channels (in the thousands)
> and memory usage seems to correlate with the large number of channels.
> I've left the server running and shut down each of the clients, and
> the channels have vanished from the report output, so I suspect a
> dodgy client here. We're using python kombu over ampqlib, so maybe
> kombu is doing something undesirable. A quick glance at the source
> shows that it has a channel pool, so maybe that's to blame. Anyway,
> more investigation required...
Right. This is definitely possible that channels are the main
thing that consumes memory.
> Once the number of channels is down to less than 10, the memory usage
> is around 32M, which seems fine to me. Maybe I don't need to allocate
> more, if I can solve this channels problem.
Yup, quite possible.
>>> Is there an
>>> option to get the server to return something that says that it is not
>>> accepting messages?
>> In ancient history we used to do this; there's a method in AMQP 0-9-1 called
>> channel.flow which the server should be able to use to tell a client to shut
>> up. In practice it was unreliable (client may not support it, or may take
>> too long to take notice of it).
> I will do some more testing. Maybe the immediate flag on basic_publish
> will do something useful. python amqplib is protocol version 0.8, so
> whatever I do must fit in with that.
Nope, "immediate" flag is a completely unrelated:
More information about the rabbitmq-discuss