Tuning BIND 8

[Kevin Darcy]

You could play with the cleaning interval, with the maximum negative caching
TTL, and/or with the lameness TTL, but I don't know that these will squeeze out
much performance, if any (are you trying to optimize for CPU utilization or for
memory? -- you didn't specify). One thing to avoid with BIND 8 is setting
resource limits: if the limit is reached, BIND 8 doesn't gracefully
optimize/purge stuff in order to stay under the limit -- instead it crashes and
burns. In fact, I'm not sure why resource limits are even implemented in
BIND 8. Perhaps so that folks can run BIND on a box which is shared with some
other, far-more-important, mission-critical function which cannot tolerate to
be resource-starved at all (???) That seems like a dumb deployment choice to
begin with.

BIND 9 gives you more knobs to tweak, tuning-wise, and, more importantly it
will give you multi-threading if you have a multiprocessor box. You'll
definitely want to upgrade to Solaris 8 to take advantage of that, though. It
will also (I haven't heard any progress on this lately) gracefully deal with
resource limits, although that's always going to be a tradeoff -- if you set a
memory limit, for example, then when it hits that limit, it'll have to expend
more CPU to deal with it.

There's not much to tune with respect to resolver caches, since most things
referred to as "resolvers" are actually "stub resolvers" which don't cache.
(And don't get me started on Solaris' "nscd". Grrrr. The best way to
"tune" that puppy IMO is to disable it completely)

As for caching "farms", I've never really dealt with such a thing, because our
caching boxes are spread out strategically throughout the enterprise. I
subscribe more to the "cache as locally as possible" philosophy than the "build
a huge centralized farm" philosophy. But opinions differ *greatly* in this
area.


- Kevin

DD wrote:

> Hi group,
>
> I've just inherited some very large caching resolvers  (ISP setting) and I'm
> wondering what y'all do for tuning. Apparently the last tuning that was
> done was 18 months ago, and the customer base has grown 100% since
> then.  The boxes are getting hit pretty hard, what kinds of things can I
> do to ensure speedy resolution? The named.conf is pretty standard, and
> the resolvers are not authoritative, just caching. solaris 26 OS.
> (company would like to migrate to solaris 8 soon)
> Can I play with the cache of a resolver? To what benefit?
> Are there any lesser known options for named.conf that could improve
> performance?
> Does anyone here use a "server farm"? How sucessful? What platform?
>
> Thanks in Advance for the tips.
>
> DD