Memory usage on 9.5.0rc1 authoritive only server

JINMEI Tatuya / 神明達哉 Jinmei_Tatuya at isc.org
Tue May 20 07:04:44 UTC 2008


At Mon, 19 May 2008 19:58:56 -0700,
Jason Fesler <jfesler at yahoo-inc.com> wrote:
> I'm testing bind 9.50rc1 (and 9.4.2) to compare against our current  
> bind version (don't laugh!).  bind8 loads our zones (roughly 20,000  
> zones, and about 1.1 million records) in 350 megs of ram; bind 9.4.2  
> in 550 megs of ram.
> 
> The troublesome spot seems to be setting up 9.5.0rc1 with the same  
> configs as the bind 9.4.2 setup.   Once it is done loading, close to  
> 10 gigs of memory is claimed by named, before serving a single query.
> 
> 27363 jfesler   16   0 9793m 7.6g 1528 S    0 98.0   3:14.14 named
> 
> This is running on RHEL4, on a 64 bit box, with 8 gigs of ram, with  
> bind built using:
> 
>   CFLAGS='-DFD_SETSIZE=4096 -g'  LDFLAGS="-static -g"  ./configure -- 
> prefix=mumble  --disable-threads
> 
> Any suggestions on how to reduce the memory usage?

I have no specific idea at the moment, but would like to see some more
details:
- is the number of zones and/or total number of records tightly
  related to the huge memory footprint?  For example, if you reduce
  the number of zones to 10,000, will the memory footprint also be a
  half or so?
- do you enable (and use) statistics-channels?  If so, does the
  memory footprint change if you disable it?
- can you enable statistics-channels and show the "memory contexts"
  table available in the embedded http server?  You can do that, for
  example, by adding the following lines to named.conf

  statistics-channels {
        inet 127.0.0.1 port 5380 allow { 127.0.0.1; };
  };

  and type in http://[127.0.0.1]:5380 on your web browser's address
  bar.  (Note that you need libxml2 installed in your build
  environment to use this feature)

  But before doing that, you may also want to apply the attached patch
  since your server has so many zones, which may cause another trouble
  with statistics-channels.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.





More information about the bind-users mailing list