Bind 8.1.2 in.named memory leak in Solaris 7

[Douglas, Earl]

I'm running BIND 8.1.2 on all my DNS servers, I was unaware that there is
memory leaks.
Although I have not had any DNS issues with this version of BIND.

How do I determine how much memory in.named is using (Solaris 2.6)???



thanx

Earl D


PLI 1999



-----Original Message-----
From: jstewart at algonquin.carleton.ca
[mailto:jstewart at algonquin.carleton.ca]
Sent: Friday, October 08, 1999 10:57 AM
To: comp-protocols-dns-bind at moderators.uu.net
Subject: Re: Bind 8.1.2 in.named memory leak in Solaris 7



In <14483.939389314 at kludge.mpn.cp.philips.com> Jim Reid
<jim at mpn.cp.philips.com> writes:

>>>>>> "Joaquim" == Joaquim Eudes Mendes Gomide <jgomide at bancobrasil.com.br>
writes:

>    Joaquim> I got an article on Sunsolve that says: "The DNS process
>    Joaquim> 4in.named4 continually consumes memory until no
>    Joaquim> memory is available. At this point in.named terminates
>    Joaquim> leaving a possibly large core file."  Is this problem a
>    Joaquim> Bind 8.1.2 or a Solaris version of Bind bug? The same
>    Joaquim> article says that there is no work around, too.  Does the
>    Joaquim> Bind 8.2 solves this problem?

>The article is a little bit misleading. It gives the impression that
>name servers guzzle memory until the system runs out and then named
>crashes and dumps core. This isn't quite true. It is true that the
>name server will die if it cannot get more memory from the OS. However
>that should be a rare event. And if your system can't let the name
>server process have more memory, then you have to contend with more
>serious underlying problems. [Like a grossly overloaded computer or a
>woefully inadequate local DNS infrastructure.]

>The size of a name server process grows as it receives queries. These
>make named cache more and more data as it looks up names and sends
>queries to other name servers. However the size of the process tends
>to stabilise after the name server has been running for a few
>days. Old entries get expired from the cache and the lookup patterns
>from local resolvers tend to request the same names.

>This "problem" is the way name servers work. They take more memory
>from the OS as they need to cache resource records. In general this
>doesn't grow without limit. I believe that BIND9 will behave more
>gracefully when named's memory allocation requests fail. However this
>isn't due to be released until next year and it may be a year after
>that before vendors ship it with their OS releases.

>FWIW the name server on a Solaris box here has been running for a few
>weeks now and it only uses 1.5M of VM. This isn't a noticeable load on
>the system and is nowhere near the resource limits of the OS.

   That's a good overview of how a dns name server should be working,
however
there really is a big memory leak in the 8.1.2 version of bind that ships
with Solaris 7.  After migrating our primary dns server to Solaris 7 we 
were finding that it took less than a day to grow to more than 50MB in size!
A cron job which checks the size of the in.named process was restarting the
daemon at least once a day.  I worked around that problem by installing the 
8.2.1 version of bind.  It now takes several weeks before it hits that 
level of memory consumption.
-- 
John Stewart -- Computing and Communications Services, Carleton University
Internet: jstewart at ccs.carleton.ca                       613-520-2600x3707
"Why are so many people trying to get ahead when they already have one?"


******************************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement contract.
******************************************************************************************


-- HTML Attachment decoded to text by Listar --

 RE: Bind 8.1.2 in.named memory leak in Solaris 7



I'm running BIND 8.1.2 on all my DNS servers, I was unaware that there is
memory leaks. 
Although I have not had any DNS issues with this version of BIND. 

How do I determine how much memory in.named is using (Solaris 2.6)??? 



thanx 

Earl D 


PLI 1999 



-----Original Message----- 
From: jstewart at algonquin.carleton.ca 
[mailto:jstewart at algonquin.carleton.ca[1]] 
Sent: Friday, October 08, 1999 10:57 AM 
To: comp-protocols-dns-bind at moderators.uu.net 
Subject: Re: Bind 8.1.2 in.named memory leak in Solaris 7 



In <14483.939389314 at kludge.mpn.cp.philips.com> Jim Reid
<jim at mpn.cp.philips.com> writes: 

>>>>>>"Joaquim" == Joaquim Eudes Mendes Gomide <jgomide at bancobrasil.com.br>
writes: 

>    Joaquim> I got an article on Sunsolve that says: "The DNS process 
>    Joaquim> 4in.named4 continually consumes memory until no 
>    Joaquim> memory is available. At this point in.named terminates 
>    Joaquim> leaving a possibly large core file."  Is this problem a 
>    Joaquim> Bind 8.1.2 or a Solaris version of Bind bug? The same 
>    Joaquim> article says that there is no work around, too.  Does the 
>    Joaquim> Bind 8.2 solves this problem? 

>The article is a little bit misleading. It gives the impression that 
>name servers guzzle memory until the system runs out and then named 
>crashes and dumps core. This isn't quite true. It is true that the 
>name server will die if it cannot get more memory from the OS. However 
>that should be a rare event. And if your system can't let the name 
>server process have more memory, then you have to contend with more 
>serious underlying problems. [Like a grossly overloaded computer or a 
>woefully inadequate local DNS infrastructure.] 

>The size of a name server process grows as it receives queries. These 
>make named cache more and more data as it looks up names and sends 
>queries to other name servers. However the size of the process tends 
>to stabilise after the name server has been running for a few 
>days. Old entries get expired from the cache and the lookup patterns 
>from local resolvers tend to request the same names. 

>This "problem" is the way name servers work. They take more memory 
>from the OS as they need to cache resource records. In general this 
>doesn't grow without limit. I believe that BIND9 will behave more 
>gracefully when named's memory allocation requests fail. However this 
>isn't due to be released until next year and it may be a year after 
>that before vendors ship it with their OS releases. 

>FWIW the name server on a Solaris box here has been running for a few 
>weeks now and it only uses 1.5M of VM. This isn't a noticeable load on 
>the system and is nowhere near the resource limits of the OS. 

   That's a good overview of how a dns name server should be working,
however
there really is a big memory leak in the 8.1.2 version of bind that ships 
with Solaris 7.  After migrating our primary dns server to Solaris 7 we 
were finding that it took less than a day to grow to more than 50MB in size!

A cron job which checks the size of the in.named process was restarting the 
daemon at least once a day.  I worked around that problem by installing the 
8.2.1 version of bind.  It now takes several weeks before it hits that 
level of memory consumption. 
-- 
John Stewart -- Computing and Communications Services, Carleton University 
Internet: jstewart at ccs.carleton.ca                       613-520-2600x3707 
"Why are so many people trying to get ahead when they already have one?" 

*****************************************************************************
˜#*************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized.

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement contract.
*****************************************************************************
*************


--- Links ---
   1 mailto:jstewart at algonquin.carleton.ca