BIND 9.2.3 and zone transfers larger than 64MB

Mark Hennessy mhennessy at cloud9.net
Fri Aug 27 16:24:23 UTC 2004


I found this URL:
http://lists.freebsd.org/pipermail/freebsd-questions/2004-April/043919.ht=
ml

Just keep following the thread "Increase max data segment size?" as the
sender answers his own questions.=20

--
 Mark Hennessy

-----Original Message-----
From: Vinny Abello [mailto:vinny at tellurian.com]=20
Sent: Friday, August 27, 2004 12:22 PM
To: Mark Hennessy; bind-users at isc.org
Subject: RE: BIND 9.2.3 and zone transfers larger than 64MB=20

I've encountered out of memory errors on FreeBSD 4.10 also right at =
512MB.=20
It's something in the OS that needs to be adjusted. If you know how or=20
anyone else does offhand (or a link that tells you) I'd appreciate it as =

well. I'm still learning a lot about FreeBSD and have this problem with =
a=20
memory hogging app, but I currently don't run it so I sort of forgot =
about=20
this. :) I know this isn't a FreeBSD list so feel free to reply off list =
if=20
someone has the info on how to change it. Thanks!

At 11:23 AM 8/27/2004, Mark Hennessy wrote:
>Thanks for responding.  It looks like named has hit a memory use =
ceiling =3D
>on
>my machine at around 512MB.  It looks like the FreeBSD 4.10 kernel on =
=3D
>this
>machine may have a default per-process limit of 512MB.
>
>--
>  Mark Hennessy
>=3D20
>-----Original Message-----
>From: Jim Reid [mailto:jim at rfc1035.com]=3D20
>Sent: Friday, August 27, 2004 11:15 AM
>To: Mark Hennessy
>Cc: bind-users at isc.org
>Subject: Re: BIND 9.2.3 and zone transfers larger than 64MB=3D20
>
> >>>>> "Mark" =3D3D=3D3D Mark Hennessy <mhennessy at cloud9.net> writes:
>
>
>     Mark> When the process dies, I get the following: Aug 27 09:30:47
>     Mark> <host> /kernel: pid 83125 (named), uid 0: exited on =3D3D =
signal
>     Mark> 11 (core dumped)
>
>Signal 11 is a segmentation violation. This usually means the process
>has tried to access something outside its address space or dereferenced
>a NULL pointer. The most likely scenario for that is the name server is
>asking the OS for more RAM/VM and the OS is saying no.
>
>     Mark> This problem has not happened before this particular zone
>     Mark> file started =3D3D to get around 64MB and larger.  It does =
not
>     Mark> look like a memory problem with the server, it has over 1 GB
>     Mark> of RAM to play with.
>
>You're focusing on the amount of RAM, which is wrong. You should be
>concentrating on the amount of RAM and VM that the OS is allowing the
>name server to use. These are different things. Just because you have
>1 GB of RAM doesn't mean the name server gets to use all or even most
>of that.
>
>     Mark> Why would I be given advice to move back to BIND 8 from
>     Mark> others who have =3D3D seen the problem go away by going back =
to
>     Mark> BIND 8?  Simply saying that the =3D3D machine does not have
>     Mark> sufficient memory doesn't make any sense.
>
>It makes perfect sense. The name server is even logging the fact it's
>out of memory. You seem to be confusing the physical RAM in the box
>with the RAM/VM that the OS will let the name server use. Compare the
>size of the name server process with the OS-enforced resource limits.
>ISTR some BSD-based systems have an abitrary default limit of 64Mb of
>data space for a process. This is nowhere near enough for a
>non-trivial name server. Your name server may well be inheriting these
>defaults.
>
>BTW, BIND9 can use twice as much RAM/VM as BIND8 when it loads a zone.
>This may be significant when the zone that's loaded is large. The
>reason for this is BIND9 creates a new data structure when it reloads
>a zone. Once the zone load completes, the red-black tree for the old
>copy of the zone is discarded. So there's a transient interval when
>BIND9 has two copies of the zone in memory at once. BIND8 uses a
>different technique for reloading zones. It loads the new copy over
>the top of the existing zone which is evil, though it saves RAM/VM.


Vinny Abello
Network Engineer
Server Management
vinny at tellurian.com
(973)300-9211 x 125
(973)940-6125 (Direct)
PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0  E935 5325 FBCB 0100 977A

Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com (888)TELLURIAN

There are 10 kinds of people in the world. Those who understand binary =
and=20
those that don't.





More information about the bind-users mailing list