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: [EMAIL PROTECTED]
Free Software Network (FSN.HU) phone: +3630 306 6758
http://www.fsn.hu/
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
