URGENT, PLEASE READ: 9.5.0-P1 now available

[JINMEI Tatuya / 神明達哉]

At 10 Jul 2008 12:44:29 +0100,
Chris Thompson <cet1 at hermes.cam.ac.uk> wrote:
 
> >Also, for those who can try beta versions in the operational
> >environment, I'd like you to try it to see whether the problem still
> >happens with them.
> 
> It would help if you could go into more detail about the differences
> in socket handling in 9.4.2-P1 vs 9.4.3b2. I see that there has already

9.4.2-P1 uses the select system call to handle incoming responses,
which has a hard limitation of supportable number of sockets (in many
cases, 1024).

9.4.3b2 uses newer, more scalable APIs, that is, kqueue for BSDs,
epoll for Linux and /dev/poll for Solaris.  It also purges outstanding
queries that hopelessly take time to complete to handle newer queries.

In either case, the system's default of maximum number of open files
can be a severe limitation, so it's necessary to set it to a
reasonably large value.  I'd recommend a minimum of 1024 for P1s, and
a minimum of 4096 for beta.

> been one report of the same or similar problem against 9.4.3b2 on a 
> Linux system.

If you mean this one,

http://marc.info/?l=bind-users&m=121568664205541&w=2

I suspect the reason is the default limit of open files (1024) is too
small for this pretty busy server.  I recommended to increase it to
4096 in my response, and believe it should work.
 
> I have been wondering whether the problem is in fact an effective 256
> file descriptor limit, despite the larger resource limit settings. The
> named binary is a 32-bit executable, not a 64-bit one (default BIND make
> on these Opteron processors). Has anyone tried a 64-bit one?

If the limitation is 256 for your system, that will be a problem of
course.

---
JINMEI, Tatuya