BIND 9.x caching Performance under heavy loads
kgc at sonic.net
Thu Mar 31 21:01:58 UTC 2005
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
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
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
More information about the bind-users