On Tue, Sep 13, 2011 at 1:49 AM, Berkley, Simeon < sberkley at mcclatchyinteractive.com> wrote:

We've been getting an average of 40+/day of these messages from the caching nameserver process on one of our Xymon/Devmon servers:

named[N]: sockmgr 0xN: maximum number of FD events (64) received

This is a known condition (seems to be more common on Solaris) that you shouldn't need to worry about. You can get rid of the message by recompiling BIND, if you're so inclined.

It's related to the way BIND asks the OS for any sockets with available data. BIND uses epoll_wait() to fill a buffer of sockets with data, but it gives epoll_wait() a maximum number of sockets to return, so as to avoid buffer overflow. If the number of sockets with data is higher than the complied maximum (64 by default), BIND logs the message, handles what's returned from epoll_wait() and then loops around again. No lost data is indicated by this.

I have tried reproducing the problem by making a large amount of DNS lookups as simultaneously as possible, but with no luck.

Have you tried using "queryperf" from the BIND source?

The xymonnet status only lists 42 failed DNS lookups out of 797 calls to dnsresolve. Any suggestions on how to find out what specific process is causing named to make periodic high demands for sockets?

Enable query logging and find out what queried domains are highest during the interval. This might give you a hint.

If you're only using BIND as a local caching nameserver, you could consider instead using nscd, the name service caching daemon. For most applications, this is a more lightweight caching resolver. It's not suitable for everyone, but it might be just fine for your purpose, and you would no longer see the error messages.

Cheers Jeremy