At Fri, 04 Apr 2008 16:34:42 +0200,
Attila Nagy <[EMAIL PROTECTED]> wrote:
> No effect, the process grows happily. I don't have a core dump.
Hmm, sorry, then I have no further idea of chasing the problem. A few
points that may help:
- can you show the diff you applied to bin/named/main.c when yo
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
* JINMEI Tatuya / 神明達哉:
> Then the named process will eventually abort itself with a core dump
> due to malloc failure. Please show us the stack trace at that point.
> Hopefully it will reveal the malloc call that keeps consuming memory.
I've successfully used a backtrace()-instrumented malloc()
At Thu, 03 Apr 2008 17:22:38 +0200,
Attila Nagy <[EMAIL PROTECTED]> wrote:
> Sorry again for the long delay, I've got other work to do, and our 9.4
> servers work fine (at least on FreeBSD 6, though, see the other
> -performance- problem)...
No problem, I understand testing a beta version canno
Sorry again for the long delay, I've got other work to do, and our 9.4
servers work fine (at least on FreeBSD 6, though, see the other
-performance- problem)...
On 02/20/08 04:30, JINMEI Tatuya / 神明達哉 wrote:
At Tue, 19 Feb 2008 14:59:15 +0100,
Attila Nagy <[EMAIL PROTECTED]> wrote:
Okay,
At Tue, 19 Feb 2008 20:30:07 -0700,
JINMEI Tatuya <[EMAIL PROTECTED]> wrote:
> 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.
At Tue, 19 Feb 2008 14:59:15 +0100,
Attila Nagy <[EMAIL PROTECTED]> 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)
On 02/13/08 21:44, 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).
Sorry for the delay, here are the logs:
Feb 19 13:51:29 cns00a named[45171]: database: inf
At Wed, 13 Feb 2008 13:06:58 +0100,
Attila Nagy <[EMAIL PROTECTED]> wrote:
> Of course. See the bindn1 files at the same location. (only the memory
> section included)
> The effect is pretty much the same.
Okay, then please try this patch with '-n 1' (note: this patch doesn't
contain the memory
On 02/12/08 18:55, JINMEI Tatuya / 神明達哉 wrote:
At Tue, 12 Feb 2008 18:10:12 +0100,
Attila Nagy <[EMAIL PROTECTED]> wrote:
Then named will listen on [your_ip_address]:some_port, and you can
browse internal statistics by accessing
http://[your_ip_address]:some_port with your browser. When you
On 02/06/08 04:57, JINMEI Tatuya / 神明達哉 wrote:
One other usual suspect is BIND9's "acache" if you enable it and the
server also acts as a (busy) authoritative server. Is this the case
for you? (But again, it should also cause the same problem for 9.4.2,
so I don't think this is the reason, eith
On 02/04/08 01:31, Mark Andrews wrote:
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/i
On 2008.02.04. 20:36, JINMEI Tatuya / 神明達哉 wrote:
At Sun, 03 Feb 2008 20:24:25 +0100,
Attila Nagy <[EMAIL PROTECTED]> wrote:
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-memo
At Sun, 03 Feb 2008 20:24:25 +0100,
Attila Nagy <[EMAIL PROTECTED]> wrote:
> 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 (RSS,
>
> 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
> On 2008.01.30. 3:28, JINMEI Tatuya / ç¥æéå wrote:
> > Okay, please use the attached patch (applicable to 9.5.0b1, and also
> > to 9.5.0b2 when it's published). Build it with:
> > % STD_CDEFINES='-DLRU_DEBUG2=2' ./configure --enable-threads
> > (or set STD_CDEFINES using setenv if you use
On 2008.01.30. 3:28, JINMEI Tatuya / 神明達哉 wrote:
Okay, please use the attached patch (applicable to 9.5.0b1, and also
to 9.5.0b2 when it's published). Build it with:
% STD_CDEFINES='-DLRU_DEBUG2=2' ./configure --enable-threads
(or set STD_CDEFINES using setenv if you use a csh variant)
The log
On 2008.01.30. 3:28, JINMEI Tatuya / 神明達哉 wrote:
At Tue, 29 Jan 2008 11:40:39 +0100,
Attila Nagy <[EMAIL PROTECTED]> wrote:
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 y
At Tue, 29 Jan 2008 11:40:39 +0100,
Attila Nagy <[EMAIL PROTECTED]> wrote:
> >> 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 w
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
de
20 matches
Mail list logo
