max-cache-size doesn't work with 9.5.0b1
Attila Nagy
bra at fsn.hu
Fri Apr 4 14:34:42 UTC 2008
On 04/03/08 19:46, JINMEI Tatuya / 神明達哉 wrote:
> Hmm, this is odd in two points:
> 1. the "X" malloc option doesn't seem to work as expected. I expected
> a call to malloc() should trigger an assertion failure (within the
> malloc library) at a much earlier stage. Does it change if you try
> the alternative debugging approach I mentioned before? That is:
> - create a symbolic link from "/etc/malloc.conf" to "X":
> # ln -s X /etc/malloc.conf
> - start named with a moderate limitation of virtual memory size, e.g.
> # /usr/bin/limits -v 384m $path_to_named/named <command line options>
>
> 2. Whether it's related to this max-cache-size issue, the assertion
> failure in mem.c wasn't an expected result; this is likely to be a
> bug anyway. If the process dumped a core, can you show the
> stack backtrace of it?
> (gdb) thread apply all bt full
>
>
No effect, the process grows happily. I don't have a core dump.
> This means about 31 log messages per second. This may not be
> extremely frequent, but if some memory is lost for every log message,
> I guess it could be a reason for the growing memory at the hight rate
> we've seen.
>
> What if you change the channel setting from:
>
>
I've added this, so now the server doesn't log much (after start, noting):
category default { null; };
The memory usage still grows.
--
Attila Nagy e-mail: Attila.Nagy at fsn.hu
Free Software Network (FSN.HU) phone: +3630 306 6758
http://www.fsn.hu/
More information about the bind-users
mailing list