Re: BIND 9.6.1-P3 using more resources?

2010-01-24 Thread Chris Thompson

On Friday, I wrote:


We upgraded our main recursive nameservers (validating, via dlv.isc.org)
from 9.6.1-P2 to 9.6.1-P3 a couple of days ago. CPU (and possibly memory)
consumption have been quite a bit larger since then, and more worryingly,
seems to be gradually increasing.

I have looked for a co-incidental change in the query pattern that might
explain this, without success so far. If anyone else has seen a similar
effect as a result of upgrading, please let me know.


I have found the cause, and it was not the upgrade to 9.6.1-P3 (so apologies
for introducing any FUD about that) or a significant change to the query
load.

It was the result of adding -m record to the named argument list. I had
put this in the startup script for when named was next restarted, and
then half forgotten about it. I had in any case convinced myself that
it was a trivial-cost option. Well, that turns out not to be the case ...

(Using -m record was motivated by a unfreed-memory-at-shutdown abort
that we observed with 9.6.1-P1 -- and not since -- and reported on
bind9-bugs as RT #20675.)

--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: BIND 9.6.1-P3 using more resources?

2010-01-24 Thread Mark Andrews

In message prayer.1.3.2.1001241549090@hermes-2.csi.cam.ac.uk, Chris Thomp
son writes:
 On Friday, I wrote:
 
 We upgraded our main recursive nameservers (validating, via dlv.isc.org)
 from 9.6.1-P2 to 9.6.1-P3 a couple of days ago. CPU (and possibly memory)
 consumption have been quite a bit larger since then, and more worryingly,
 seems to be gradually increasing.
 
 I have looked for a co-incidental change in the query pattern that might
 explain this, without success so far. If anyone else has seen a similar
 effect as a result of upgrading, please let me know.
 
 I have found the cause, and it was not the upgrade to 9.6.1-P3 (so apologies
 for introducing any FUD about that) or a significant change to the query
 load.
 
 It was the result of adding -m record to the named argument list. I had
 put this in the startup script for when named was next restarted, and
 then half forgotten about it. I had in any case convinced myself that
 it was a trivial-cost option. Well, that turns out not to be the case ...

It costs a ~16 bytes per memory allocation to perform the accounting
in a 32 bit build.  ~24 bytes in a 64 bit build.  Plus some computing
time.

struct debuglink {
ISC_LINK(debuglink_t)   link;
const void *ptr[DEBUGLIST_COUNT];
unsigned intsize[DEBUGLIST_COUNT];
const char *file[DEBUGLIST_COUNT];
unsigned intline[DEBUGLIST_COUNT];
unsigned intcount;
};

With this we know where the memory that leaks was allocated and a
starting point to find the defect.

Mark
 (Using -m record was motivated by a unfreed-memory-at-shutdown abort
 that we observed with 9.6.1-P1 -- and not since -- and reported on
 bind9-bugs as RT #20675.)
 
 -- 
 Chris Thompson
 Email: c...@cam.ac.uk
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users