[rabbitmq-discuss] Questions about limit alarm and report in the log file

Jerry Kuch jerryk at vmware.com
Mon Mar 12 15:48:09 GMT 2012

Hi, Andrea:

When you see the former, it might not be a bad idea to take a peek with
lsof, or similar, and see just what the file descriptors for Rabbit
correspond to.  Remember, they're not all going to correspond to sockets,
as Rabbit has various files it deals with during operation.  Using ulimit
or editing limits.conf to change what your OS is making available to Rabbit 
is also something to keep in mind if you're finding yourself regularly
running low on fd's.

If things are working normally you'll see the alarm set when you hit a limit,
and clear when that warning condition remits, say after something is closed.

How many connections is your broker maintaining when you see these?  Rabbit
will use a file descriptor for each connection, but also tries to leave them
open until it finds a reason to close them, for example, it starts approaching
a limit as you see here.

Best regards,

----- Original Message -----
From: "Andrea Rosa (HP Cloud Services)" <andrea.rosa at hp.com>
To: rabbitmq-discuss at lists.rabbitmq.com
Sent: Monday, March 12, 2012 8:14:02 AM
Subject: [rabbitmq-discuss] Questions about limit alarm and report in the	log file


I've got some questions about the limit alarms report in the log file, some entries are not clear to me.

1 this line is reported in the log files when we are close to the file handles or memory limit?: 
Limiting to approx 3996 file handles (3594 sockets)

Memory limit set to 38749MB.

2 why there is this difference between the file handles and the number of sockets?

3 the following entries mean that we hit the limit for file_descriptor? Why we have a set and a clear?
    alarm_handler: {set,{file_descriptor_limit,[]}}

    alarm_handler: {clear,file_descriptor_limit} 


rabbitmq-discuss mailing list
rabbitmq-discuss at lists.rabbitmq.com

More information about the rabbitmq-discuss mailing list