recursive-clients queue size & clean-up

[KSP]

Not to discount anyone else's findings -- obviously everyone's environment
and needs are unique.  I've found BIND 9 to perform quite admirably in my
neck of the woods.  27 recursive servers running BIND 9.2.3, each handling
around 5 million queries daily, cache sizes in the 400-500MB range.  All
have been performing without a single failure since the day we installed
9.2.3.  Just providing another perspective.

Regards to all,

ksp

On Tue, 17 Aug 2004, Steinar Haug wrote:

> [Ladislav Vobr]
>
> |   Does each slot in the recursive-client queue being clean up after the
> |   timeout expire, if there is no response?  Or some slots are being
> |   occupied longer, it seems to me that when I reach this limit there is no
> |   really way back to stabilize bind, all cpu will be used and even if I
> |   leave it over night when the traffic sometimes goes as little as 300-400
> |   req/sec it will not recover and still the messages keeps coming from
> |   time to time, cpu is very high (abnormal to the number of incoming
> |   requests) and number of requests logged to the query.log file is almost
> |   just half of what the box is really suppose to receive, (looks like bind
> |   or os dropping the traffic).
> |   There is no weird traffic, maybe there was a weird spike, but it should
> |   recover. When I stop and start  service resumes, cpu drops, traffic
> |   comes back to normal rate, not almost like half rate as it was during
> |   the problem, and recursive-client queue is not overflowed.
>
> We have seen similar problems. Our current conclusion is that BIND9 is
> not very good as a recursive name server, and that it probably has bugs
> involving large cache sizes and/or high query rates. We are currently
> evaluating Nominum CNS, which so far seems to perform *much* better.
> Nominum CNS is not free, of course...
>
> Steinar Haug, Nethelp consulting, sthaug at nethelp.no
>
>