[rabbitmq-discuss] async thread pool

[Aman Gupta]

Over the past few days, we ran into issues during peak hours where
messages delivery was lagging severely (sometimes for up to two
minutes). During this time, the beam process is using 100% cpu. An
strace of the beam process and its async threads showed erlang was
spending most of its time in the futex system call, and doing network
i/o only very occasionally.

We changed the rabbitmq-server script to use -A0 instead and so far it
is working much better. strace shows the process spends most of its
time in epoll_wait and we are no longer having latency issues.

I'm curious as to what the reasoning behind the 30 threads was.. the
number seems a bit arbitrary, and possibly excessive as a default
setting.

  Aman

On Wed, Sep 24, 2008 at 4:12 AM, Ben Hood <0x6e6562 at gmail.com> wrote:
> Aman,
>
> On Wed, Sep 24, 2008 at 5:53 AM, Aman Gupta <rabbitmq at tmm1.net> wrote:
>>  +A size:
>>  Sets the number of threads in async thread pool, valid range is
>> 0-1024. Default is 0.
>>
>> The default is 0, why does rabbit use 30?
>
> Having more than 0 lets you do IO in parallel (socket IO, mnesia,
> journalling, logging). But why 30? I think it's just a just a number
> that you can calibrate for your own system.
>
> HTH,
>
> Ben
>