bind-9.4.0b2 throws SERVFAIL

JINMEI Tatuya / 神明達哉 jinmei at
Sat Oct 7 04:32:21 UTC 2006

>>>>> On Fri, 06 Oct 2006 11:58:57 +0200, 
>>>>> Marco Schumann <schumann at> said:

> thanks for your quick response... The config files can be seen at


> max-cache-size is defined as a global option, thus I think this is the
> overall limitation?

It depends on what you really mean by the overall limitation, but I
guess the answer is no.  Specifying max-cache-size as a global option
means the same limitation applies to every view separately.  (but in
any event I don't think this point matters much for the main problem)

> 2.8G were used by the whole process, an yes, as you
> can see in the configs, some of the zones are reverse zones of /16
> networks...

Hmm, it sounds strange.  Basically, an 'out of memory' error can
happen only when a malloc() call fails (regardless of the application
specific limitation such as max-cache-size, or of whether or not BIND9
uses 'internal-malloc').  So it would not happen for a process
consuming just 2.8G on a machine with 4GB memory and without any
system limit (especially when there is no other memory-eating
process).  Does your system really allow a process to consume memory
close to the physical limitation?

>> memory shortage can happen if memory is consumed faster than it's cleaned.

> Hmm, is the cleaning still too complicated? Or simply too slow?

There are some subtle points in the cleaning implementation that could
make this situation happen, e.g., the cleaning procedure itself needs
to allocate memory, so if it fails cleaning can be effectively
suspended.  Also, cleaning events can be interrupted by query
processing, so in theory (though very unlikely) cleaning can be slower
than the consumer.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei at

More information about the bind-users mailing list