recursive-clients queue size & clean-up
KSP
ksp at att.com
Tue Aug 17 21:35:28 UTC 2004
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
>
>
More information about the bind-users
mailing list