On 2008.01.28. 19:21, JINMEI Tatuya / 神明達哉 wrote:
At Mon, 28 Jan 2008 17:10:28 +0100,
Attila Nagy <[EMAIL PROTECTED]> wrote:

If you have time, could you rebuild named as follows

% STD_CDEFINES='-DLRU_DEBUG' ./configure; make

and try again?  This won't solve the problem, but provide more
detailed log messages tracking the memory usage of the cache.  Make
sure threads are disabled (this debug feature is currently
thread-unsafe and trigger an assertion failure when used with multiple
threads).
Without threading I don't see this effect, the memory usage stops at a sane limit and it's size can be affected by setting the max-cache-size option.

I don't think you would gain anything usable with that, am I right?

Right.  Can you try a simpler patch that focuses on the memory usage
status and works with threads?  If so, I'll write one and send it to
you.
Of course. The machines are diskless, so writing larger log files directly is not an easy task. (syslog is ok)

Thanks.

ps: I have an other problem. I've recently switched from a last year 6-STABLE to 7-STABLE and got pretty bad results on the same machine with the same bind (9.4).
The graphs are here:
http://picasaweb.google.com/nagy.attila/20080129Fbsd6vs7Bind

The interesting part (from when the comments are valid) starts at around the half of the picture. You can see that on FreeBSD 6, the CPU load is pretty much good, but on 7, both the userspace and the kernelspace activity grows significantly.
I've used libthr on 6, and it is the default on 7 too. bind is threaded.
I use ISC_INTERNAL_MALLOC, but the effect is the same without it.

I've cc-ed the freebsd-performance, I guess there are several other ppl, who is interested in bind performance on this OS.
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to