On Mon, 4 Feb 2008, Alexander Motin wrote:
Kris Kennaway wrote:
You can look at the raw output from pmcstat, which is a collection of
instruction pointers that you can feed to e.g. addr2line to find out
exactly where in those functions the events are occurring. This will often
help to track
>
> Please try this patch.
>
> Mark
Revised.
Index: lib/isc/mem.c
===
RCS file: /proj/cvs/prod/bind9/lib/isc/mem.c,v
retrieving revision 1.140
diff -u -r1.140 mem.c
--- lib/isc/mem.c 18 Jan 2008 23:46:58
ys grew behind
> max-cache-size very quickly.
>
> Here is the log:
> http://people.fsn.hu/~bra/freebsd/bind950-memory-20080203/bind950b1
> the memory usage (RSS, reported by top) in megabytes:
> 19:10:37 466
> 19:11:20 522
> 19:11:5
Kris Kennaway wrote:
You can look at the raw output from pmcstat, which is a collection of
instruction pointers that you can feed to e.g. addr2line to find out
exactly where in those functions the events are occurring. This will
often help to track down the precise causes.
Thanks to the hint
Dag-Erling Smørgrav wrote:
Julian Elischer <[EMAIL PROTECTED]> writes:
Robert Watson <[EMAIL PROTECTED]> writes:
be a good time to try to revalidate that. Basically, the goal would
be to make the pcpu cache FIFO as much as possible as that maximizes
the chances that the newly allocated object
doesn't seem to
happen. (BTW: did it always occur when you first found the problem?)
Yes, if bind was built with threads, the memory usage always grew behind
max-cache-size very quickly.
Here is the log:
http://people.fsn.hu/~bra/freebsd/bind950-memory-20080203/bind950b1
the memory usage
Julian Elischer <[EMAIL PROTECTED]> writes:
> Robert Watson <[EMAIL PROTECTED]> writes:
> > be a good time to try to revalidate that. Basically, the goal would
> > be to make the pcpu cache FIFO as much as possible as that maximizes
> > the chances that the newly allocated object already has lines
