, Matt Corallo wrote:
Gah, I'm a blind fool. The original and post-config-restoration number quoted
here are correct, the 1024M stat was looking at the wrong process. Apologies
about that, it appears the max-cache-size knob does *not* change the total
memory usage of the process after a re
n the
host either way.
Matt
On 4/28/22 9:44 AM, Matt Corallo wrote:
And then I restarted it with the original setting and it jumped right up to ~300M, a bit higher than
it was before (though before it had been running for a bit). In any case it does look like the
max-cache-size setting drives m
ebugging that makes sense
here.
Matt
On 4/28/22 9:38 AM, Matt Corallo wrote:
Hmm, they all have max-cache-size set to 8M (see config snippets in OP) but still show the divergent
memory usage.
That said, I tried bumping one to 1024M on one of the smaller hosts and usage increased from ~270MB
to ~
working hours.
On 28. 4. 2022, at 17:26, Matt Corallo wrote:
On 4/27/22 9:19 AM, Petr Špaček wrote:
On 27. 04. 22 16:04, Matt Corallo wrote:
I run a number of BIND9 (9.16-27-1~deb11u1 - Debian Stable) secondaries with some large
zones (10s of DNSSEC-signed zones with ~100k records, not counting
On 4/27/22 9:19 AM, Petr Špaček wrote:
On 27. 04. 22 16:04, Matt Corallo wrote:
I run a number of BIND9 (9.16-27-1~deb11u1 - Debian Stable) secondaries with some large zones (10s
of DNSSEC-signed zones with ~100k records, not counting signatures, with a smattering of other
zones). Somewhat
Hi!
I run a number of BIND9 (9.16-27-1~deb11u1 - Debian Stable) secondaries with some large zones (10s
of DNSSEC-signed zones with ~100k records, not counting signatures, with a smattering of other
zones). Somewhat to my surprise, even with "recursion no" the memory usage of instances is highly
6 matches
Mail list logo
