[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bind9-users
Subject:    Re: Solaris 8/Bind 9 Processor/Memory Leak
From:       sdmatott+bind () uchicago ! edu
Date:       2002-06-27 12:35:40
[Download RAW message or body]



Trey,

We collect data on our servers with Orca which in turns uses the SE Toolkit to gather \
it's info.  

Hate to mince words being susch a newbie on this list, but I must say your 3% claim \
is bit controversial.  I have seen system where what you say is seemingly true (freed \
memory is not cleared until it is needed) but I've also seen Solaris systems (most \
notable our 2ndary name servers, which were suffering from the bind9 unbounded cache \
memory leak) where killing an offending job immediately frees a large chunk of \
memory.  I've also seen Solaris systems which have been up and running, doing all \
kinds of work (apache, dhcpd, bind, mrtg, cricket, etc.) for many months and still \
have more than 50% real memory free.  So it does not seem so evident to me that \
Solaris systems should typically have only 3% real memory free.

Looking at vmstat and or Orca graphs some more, I am fairly confident that what we \
are seeing is the kernel gobbling up more ram.

This evidenced by an increasing kernel 'memory page count' see:
http://hotrod.uchicago.edu/orca/o_unicron_pp_kernel,__free_pages,__pagestotl_-_pp_kernel_-_free_pages,__pagestotl.html


As well as the kernel cpu time trend (upwards, now at 60% after ~3 days uptime) \
mentioned in my previous email.

All of this I feel must have something to do with the fact that this is our primary \
nameserver, seeing as how we are running 4 2ndaries on the same OS level on the same \
Hardware on the same build of bind9 w/o incident.

I will try the kernel patch.

Thanks,
Scott Matott sXe
-----
Scott Matott sXe
Networking Specialist
Data Network Operations
Voice and Data Networking
The University of Chicago


[prev in list] [next in list] [prev in thread] [next in thread]