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 "...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
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. |