[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bind-users
Subject:    Re: Socket buffer space?
From:       Havard Eidnes <he () uninett ! no>
Date:       2018-12-11 16:46:10
Message-ID: 20181211.174610.2231167293995784975.he () uninett ! no
[Download RAW message or body]

>> I don't suppose there exists a configuration option in BIND which
>> corresponds to Unbound's so-rcvbuf: and so-sndbuf: configuration
>> options?
>
> There is only `./configure --with-tuning=large` which enables
> more sockets and bigger socket buffers.

Hmm, I already have that, but I wonder, how big is "bigger"?  Well,
looks like the answer is that BIND tries to probe for the biggest it
can be allowed to set on startup, by starting with a large value and
approximately halfing it successively if I read the code right.  BIND
doesn't log what setting it is using, though...

However, it appears that BIND applies this same setting to each and
every UDP socket BIND creates, ref. lib/isc/unix/socket.c's
opensocket() function, which is probably not required.  I would have
thought it would be sufficient to set it on those sockets which serve
port 53, and not on those temporary sockets BIND creates to talk to
other name servers in the process of doing recursion.  On a system
which doesn't overcommit resources, this is responsible for needless
waste.

> (I thought I also needed to set some sysctls too, so that
> BIND's request for bigger buffers was actually honoured by the
> kernel.)

Right, in my case that would be

kern.sbmax


It seems the probing for "maximum allowed value" appeared with one of
the early BIND 9.10 releases, as well as the extra settings for
`--with-tuning=large`; older versions used 32K "statically".


Regards,

- Håvard
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
[prev in list] [next in list] [prev in thread] [next in thread]