-----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-----