BIND 9.x caching Performance under heavy loads

[J Sloan]

roy.mongiovi at bellsouth.com wrote:
>We had the same problem: bind runs fine for a day, then slows down and
>stops processing incoming packets.  Our servers are dual pentium,
>hyperthreading enabled, 8 gig RAM, running Redhat (originally AS 2.1,
>now 3.0).  We run bind "-n 2", which seems to give the best performance
>even with hyperthreading enabled.
>
>Our servers are quite busy.  The symptoms we see is that CPU usage
>climbs steadily, although memory usage does not.  Eventually we get to
>the point where we aren't receiving incoming packets fast enough to
>avoid dropping them.  Restarting bind fixes the problem.  If we restart
>every 24 hours, we don't see the problem.
>
>We had tried some of the config changes recommended here without
>effect.  Limiting the cache size and/or turning off cache cleaning
>changed the memory footprint but didn't prevent bind from having
>problems after running for 24 hours.
>
>I was also worried about the comment that the internal memory allocator
>is slow in a multi-CPU environment,  but benchmarking in the lab
>actually shows its performance to be better (more consistent) than
>using system malloc.  We're currently in the process of testing bind
>9.2.5, compiled with ISC_MEM_USE_INTERNAL_MALLOC.  No configuration
>changes have been made: we're using the default cache cleaning interval
>and unlimited cache size.  The internal malloc version has been running
>for a week now without a restart, which would have been completely
>impossible for the system malloc version.  I'm cautiously optimistic.
>
>Is this a linux only problem?  Bind runs on so many systems, how could
>a problem like this run under the radar for so long?  How do we get to
>the bottom of this so it gets fixed a better way?
>Roy Mongiovi
>
>  
It could be a redhat specific problem. We have 750 domains, and are 
using 6 views (byzantine internal network/firewall configuration) We ran 
the dns on redhat servers for some years, and found that we needed to 
set up a cron job to keep restarting bind, in order to keep things 
running. Some months ago we moved to suse linux, and have not needed to 
kickstart bind once since then. It runs well, doesn't misbehave, and we 
don't need to babysit it anymore.

Vendor specific library versions, kernel features, bind compile options 
all enter into it.

Joe