[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: max-cache-size doesn't work with 9.5.0b1
- To: Attila Nagy <bra_(_at_)_fsn_(_dot_)_hu>
- Subject: Re: max-cache-size doesn't work with 9.5.0b1
- From: JINMEI Tatuya / 神明達哉 <Jinmei_Tatuya_(_at_)_isc_(_dot_)_org>
- Date: Tue, 19 Feb 2008 20:30:07 -0700
- Cc: freebsd-performance_(_at_)_freebsd_(_dot_)_org, bind-users_(_at_)_isc_(_dot_)_org
At Tue, 19 Feb 2008 14:59:15 +0100,
Attila Nagy <bra_(_at_)_fsn_(_dot_)_hu> wrote:
> > Okay, then please try this patch with '-n 1' (note: this patch doesn't
> > contain the memory statistics hack via the HTTP interface, but I don't
> > we don't need it for this test).
> (max-cache-size still 32M)
Hmm, then the mutex locks dynamically generated are also irrelevant.
I've also tried to reproduce the problem in a similar environment
(BIND 9.5.0b1 with threads on FreeBSD 7.0RC1/AMD64, cache-only
configuration, using a real query sample), unsuccessfully. One
significant difference is that I disabled SMP in the kernel (it was
very unstable with the SMP support for some unknown reason), but I
doubt this is the key for the difference of the named behavior.
BTW, is this reproduceable on FreeBSD 6.x? If so, then I'd like to
see what happens if you specify some small value of datasize
(e.g. 512MB) and have named abort when malloc() fails with the "X"
_malloc_options. (This option doesn't seem to work for FreeBSD 7.x,
at least at the moment).
Some other questions:
- can we see your named.conf? If you specify non-default
configuration options, that might be the reason for, or related to,
- does your named produce lot of log messages? If so, it might also
be a reason (simply because it relies on standard libraries).
freebsd-performance_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-performance-unsubscribe_(_at_)_freebsd_(_dot_)_org"
Visit your host, monkey.org