[zeromq-dev] Even more fun with accept

Steven McCoy steven.mccoy at miru.hk
Thu Apr 30 02:48:35 CEST 2009

One would suggest it is an administrative error to let the application
run out of file descriptors, i.e. simply raise the limit and restart.

However as a method of copying with the situation the only viable
solution would be to implement a back-off period when the socket limit
is reached by error, along with suitable error to the console for the
administrator to see.

In order to allow the administrator to manage resources though there
would need to be some mechanism to determine the number of descriptors
in use by zeromq.


2009/4/30 Erich Heine <sophacles at gmail.com>:
> Hi all,
> I would suggest a twofold approach. First off, the process should know its
> maxfd value (in linux its a call to getrlimit, but i can't remember if that
> is posix compliant). If the number of open sockets is at maxfd, try to
> setrlimit maxfd to a higher number. As long as the soft limit is not set to
> the hard limit, this will work.
> Second, once at the hard limit for maxfd don't try to accept until open fds
> is less than maxfd.
> In Linux and the BSD maxfd is a kernel parameter that can be tweaked
> somewhat at runtime, and somewhat at compile time, so there is a necessary
> component of sysadmin cooperation.
> I really don't know if the above approach will work or not, just that it is
> what I would try first.
> Regards,
> Erich
> On Wed, Apr 29, 2009 at 11:27 AM, Martin Sustrik <sustrik at fastmq.com> wrote:
>> Hi,
>> I was just told that when EMFILE or ENFILE error (the socket limit is
>> exceeded) is returned from accept the connection isn't purged from the
>> listening queue.
>> The consequence is that polling on the listening socket signalises that
>> there's a pending connection, however, there's no way to accept it
>> unless some sockets are closed in the meantime.
>> Such behaviour results in a busy loop desperately trying to accept the
>> connection, ultimately getting the CPU load to 100%.
>> Any tips how to solve the problem?
>> Martin
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list