unable to obtain neither an IPv4 nor an IPv6 dispatch

[Cathy Almond]

On 24/07/2014 01:35, Matthew Calder wrote:
> At the moment I'm limited to using 2 UDP listeners per interface. When
> stress testing I can see that only 2 out of 4 CPUs are being used, I'm
> guessing because I'm limited to 2 listeners. Any suggestions for what
> could be limiting BIND from using a higher number of UDP listeners?

named will tell you in its startup logs how many workers it is running
(either from auto-detecting #cpus or from -n when running named).  It
will also tell you how many listeners per interface (default for 9.9 is
the same as the number of worker threads, but it's also controlled by -U
at start up).

The number of listeners per interface is also capped at the number of
worker threads.

>From BIND 9.10 we changed the default behaviour - it's this:

"If not specified, named will calculate a default value based on the
number of detected CPUs: 1 for 1 CPU, 2 for 2-4 CPUs, and the number of
detected CPUs divided by 2 for values higher than 4. If -n has been set
to a higher value than the number of detected CPUs, then -U may be
increased as high as that value, but no higher."

Also, working out what's going on is a bit of an 'art' because within
BIND, depending on how the OS works, you're probably going to get each
worker thread pegged to the same CPU most of the time (but not always),
but each worker thread itself is going to be running multiple tasks -
not just the listeners, so while it sometimes works out under stress
that we see the listener tasks always on the same threads and those
threads always on the same CPU, it's not guaranteed to split that way
(particularly if -n and -U are the same and/or -n is set larger than the
number of available CPUs).

Cathy