[Unbound-users] unbound occasionally does not answer

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Aaron,

After offlist talk with Attila, we found the issue.  The UDP receive
buffer size was insufficient.  In svn trunk there is a new option,
so-rcvbuf: 4m and that fixes it.

Most smaller installations won't need it, and for larger installations
if netstat -su shows rcv buffer trouble, it can alleviate that.  The
default setting is still to use the operating system defaults.

Best regards,
   Wouter

On 09/18/2009 07:43 PM, Aaron Hopkins wrote:
> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkq8jAkACgkQkDLqNwOhpPg2pgCfQ8zAAYvG5yWm4/CbaFeMffeB
eA0AnA30K5ZE+WLMXkStbBBAZrAZgh+/
=Bidl
-----END PGP SIGNATURE-----