RE: BIND 9.2.3 and zone transfers larger than 64MB

This is a discussion on RE: BIND 9.2.3 and zone transfers larger than 64MB within the Bind Users forums, part of the DNS and Related Forums category; I found this URL: http://lists.freebsd.org/pipermail/f...ril/043919.ht= ml Just keep following the thread "...


Go Back   Usenet Forums > DNS and Related Forums > Bind Users

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 08-27-2004
Mark Hennessy
 
Posts: n/a
Default RE: BIND 9.2.3 and zone transfers larger than 64MB

I found this URL:
http://lists.freebsd.org/pipermail/f...ril/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@tellurian.com]=20
Sent: Friday, August 27, 2004 12:22 PM
To: Mark Hennessy; bind-users@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@rfc1035.com]=3D20
>Sent: Friday, August 27, 2004 11:15 AM
>To: Mark Hennessy
>Cc: bind-users@isc.org
>Subject: Re: BIND 9.2.3 and zone transfers larger than 64MB=3D20
>
> >>>>> "Mark" =3D3D=3D3D Mark Hennessy <mhennessy@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@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.




Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 05:20 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0