BIND 9.x caching Performance under heavy loads

[Kelsey Cummings]

On Wed, Mar 30, 2005 at 11:47:35PM +0000, Bernhard Schmidt wrote:
> On 2005-03-25, Kelsey Cummings <kgc at sonic.net> wrote:
> 
> >> Also, if you have a uniprocessor system, you might want to test the
> >> patch I recently posted to enable better BIND9 statistics.
> > The systems are all P4 CPUs with HT enabled. 
> >
> > While the comments are appreciated they don't address the specific problems
> > which is bind going into a 100% CPU spin for no apparent reason after a long
> > period of stable operation.  During this time it's still answering reqeusts
> > but with delays in the 10-30 second range.
> 
> JFTR, I have a similar problem, with BIND 9.3.1 threaded running on a
> Dual Xeon 2.8Ghz with 4GB RAM on SLES9 (Linux 2.6.5-something). The box
> is not very much loaded (about 100-400qps depending on daytime), but has
> to carry a big RBL which pumps up memory usage to 500M after startup and
> has query logging enabled. It does both authorative and resolver (old
> setup)

I'd recomend moving that RBL zone into rbldnsd if at all possible and
either targeting it with a forwarding zone or have the queriers ask it
directly.  Bind can't hold a candle to the speed and footprint of
rbldnsd when dealing with huge rbl zones.

Case in point - I've got a pair of dual PIII-800's serving upwards of 3.7k
qps with < 10% CPU usage.  This server has most all freely availble rbl
(and other) zones loaded using 265MB.  Bind, on the same box, with a couple
tiny zones and rbl-plus is using 1G, ~25% CPU on each CPU, and only handling
~600qps.

-- 
Kelsey Cummings - kgc at sonic.net           sonic.net, inc.
System Architect                          2260 Apollo Way
707.522.1000 (Voice)                      Santa Rosa, CA 95407
707.547.2199 (Fax)                        http://www.sonic.net/
Fingerprint = D5F9 667F 5D32 7347 0B79  8DB7 2B42 86B6 4E2C 3896