[Unbound-users] unbound occasionally does not answer

[Aaron Hopkins]

On Fri, 18 Sep 2009, W.C.A. Wijngaards wrote:

> By default, it polls every socket for 100 datagrams, but in
> your case that can be 8000 'not port 53' sockets.

It might be an interesting experiment to track the average and max amount of
time spent handling 53 vs not-53 sockets in one pass on a busy server.  This
will tell how long the socket would need to buffer incoming requests.

> If every 'not 53' socket has datagrams, this could take a long
> time to process them all.

If you can take up to 100 new requests per pass but process up to 8000
already-active requests per pass, this substantially favors processing
active requests over taking new ones.  If the goal is to always answer, even
with an error indicating unbound is overloaded, this probably isn't sane.

How about trying an upper-bound on the number of not-53 sockets that will be
processed in one pass?  This should put an upper bound on the amount of time
that unbound isn't taking at least some packets from port 53 and might be
easy to implement.

> If you set the value to 10000 : this causes unbound to perform
> more processing for the port 53 if it has lots of queries
> waiting.  Will probably cause unbound to empty the buffer that
> is being used, and this may help your dropped packets?

If you don't add a limit on how many non-53 sockets get processed per pass,
I suspect that the sane thing to do is set the default higher here.

What happens requests continue to come in faster than there are available
resources to process?  How do they get dropped?  Is there an upper limit on
the amount of RAM used to buffer them within unbound after they are
received?  I suspect this would potentially get triggered more often.

                                     -- Aaron