Knowledge Base ISC Main Website Ask a Question/Contact ISC
Background info about 'maximum number of FD events' log messages
Author: Evan Hunt Reference Number: AA-00464 Views: 2011 Created: 2011-09-14 03:20 Last Updated: 2014-05-02 19:46 0 Rating/ Voters

maximum number of FD events means that when checking to see if any sockets are ready to be read from, there were more than 64 of them. As commented in the code, this isn't an error, but it is unexpectedly high. If the message is logged frequently and persists for a long period of time, then It may be that recompiling with a higher value of ISC_SOCKET_MAXEVENTS will make this message disappear.  But if there is another underlying problem that isn't diagnosed and addressed, the you may still reach the maximum number of events, no matter how high the limit is set.

On larger machines that have high query rates, increasing this setting can be done when you build the named binary by setting ISC_SOCKET_MAXEVENTS when invoking configure.  For example:

STD_CDEFINES='-DISC_SOCKET_MAXEVENTS=256' ./configure


These logs are not (directly) related to maximum number of file descriptors.  They mean that when the i/o watcher polled for events, more socket events were returned than the implementation normally
expects (which is 64).  This is not necessarily an error because the remaining events will be returned with the next poll, but it can indicate high socket traffic or activity.

Some busy servers may need to run with a higher limit, but if the problem persists after increasing ISC_SOCKET_MAXEVENTS and the message is being logged constantly, then there is most likely something else happening that you need to investigate - for example unusual traffic loads or specific queries or patterns of queries that are causing your nameserver to be overloaded and unable to service inbound queries (or replies from other authoritative servers) quickly enough.

You may want to check overall stability of the server - for example:

  • The ratio of server failures (SERVFAIL) that your server returns to the clients
  • The ratio of query replies to queries (compare both of these with what's 'normal' for your server)
  • Cache memory footprint
  • Cache hit ratio
  • UDP packet drops reported by the OS
  • Query response times
  • Recursive clients (recursive queries currently 'in progress')

We also recommend upgrading to one of the latest supported production versions of BIND.  Current versions of BIND include changes to cache management that provide greater performance resilience to some types of client query loads.

For further troubleshooting advice, also see: What to do with a misbehaving BIND server


© 2001-2016 Internet Systems Consortium

Please help us to improve the content of our knowledge base by letting us know below how we can improve this article.

If you have a technical question or problem on which you'd like help, please don't submit it here as article feedback.

For assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.

ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.

Feedback
  • There is no feedback for this article
Info Submit Feedback on this Article
Nickname: Your Email: Subject: Comment:
Enter the code below:
Quick Jump Menu