Too many open files (not only BIND 9.5.0-P1)
Shumon Huque
shuque at isc.upenn.edu
Fri Jul 11 20:05:48 UTC 2008
On Fri, Jul 11, 2008 at 10:54:47AM +0100, Stacey Jonathan Marshall wrote:
> JINMEI Tatuya / ???? wrote:
> > At 09 Jul 2008 21:44:47 +0100,
> > Chris Thompson <cet1 at hermes.cam.ac.uk> wrote:
> >
> >
> >> I have observed two occurrences of this with BIND 9.4.2-P1 running under
> >> Solaris 10_x86 even though plimit(1) clearly shows the named process
> >> has both soft and hard limits on file descriptors set to 65536:
> >>
> >> Jul 9 20:29:09 recdns0.csx.cam.ac.uk named[18018]: [ID 873579 local7.error]
> >> general: error: socket: too many open file descriptors
> >> Jul 9 20:29:25 recdns0.csx.cam.ac.uk last message repeated 758 times
> >>
> >> # plimit 18018
> >> 18018: /usr/local/BIND/bind/sbin/named -u namesrvr -c ../etc/named.conf
> >> resource current maximum
> >> [...]
> >> nofiles(descriptors) 65536 65536
> >>
> >
> > What's the value of FD_SETSIZE? Someone else reported that there's a
> > system that has FD_SETSIZE defaulting to 256.
> >
> > I'd also like to know that how many sockets were actually opened when
> > you saw the 'too many open file descriptors' errors.
> >
> > ---
> > JINMEI, Tatuya
> >
> >
> /include/sys/types.h has it set to 256 under Solaris. That does appear
> to be the value that lib/isc/unix/socket.c would use.
How so? On my Solaris 10 systems, it looks like <unistd.h> eventually
calls <sys/select.h> which sets FD_SETSIZE to 1024 (or 65536 in LP64):
/*
* Select uses bit masks of file descriptors in longs.
* These macros manipulate such bit fields.
* FD_SETSIZE may be defined by the user, but the default here
* should be >= NOFILE (param.h).
*/
#ifndef FD_SETSIZE
#ifdef _LP64
#define FD_SETSIZE 65536
#else
#define FD_SETSIZE 1024
#endif /* _LP64 */
[...]
I've upgraded 2 of our campus caching resolvers to 9.4.2-P1. So far
no problems. I've seen upwards of 500 open file descriptors but the
number fluctuates signficantly and on average is far below that.
I am concerned about upgrading my primary resolver though, which
is higher traffic. If I exceed 1024, what is the recommended action?
Redefine FD_SETSIZE upwards and recompile? Recompiling in 64-bit
sounds scarier.
--Shumon.
More information about the bind-users
mailing list