Re: BIND 9.2.3 and zone transfers larger than 64MB

>>>>> "Mark" == 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 = 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 = 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 = seen the problem go away by going back to
Mark> BIND 8? Simply saying that the = 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.