Greg Choules wrote:
> Point taken. Unique does not necessarily mean non-existent and *something*
> will end up in cache. So restricting your max-cache-size would seem to be
> the thing for you. If it were my server, I would monitor just how much RAM
> is getting used in total and adjust max-cache-
Point taken. Unique does not necessarily mean non-existent and *something*
will end up in cache. So restricting your max-cache-size would seem to be
the thing for you. If it were my server, I would monitor just how much RAM
is getting used in total and adjust max-cache-size to allow BIND to use as
Greg Choules wrote:
> Since the queries are unique the responses should be NXDOMAIN
Well, _some_ of them will be NXDOMAIN, many others
will be NOERROR or NODATA etc., no? But yes, they all
ended up contributing to the cache growing, and it
seems that 90% of physical memory all in use by bind
wa
Hi Jan.
Since the queries are unique the responses should be NXDOMAIN, which *will*
be cached and therefore consume memory. This is why I was curious what you
are hitting it with.
You can see these cache entries if you dump it using "rndc dump -cache".
This produces a file (by default) called "name
Michal Nowak wrote:
> In your named log you may see a "max-cache-size" calculation like the one
> below (I don't have "max-cache-size" set in the config explicitly, implicit
> value of "90%" is used):
>
> 'max-cache-size 90%' - setting to 1729MB (out of 1922MB)
Good call - I do see that:
'm
On 14/02/2023 16:09, Jan Schaumann via bind-users wrote:
I'm guessing that without a set 'max-cache-size', this
continues to grow until there is no more memory space
left, we start swapping, and eventually get OOM
killed.
https://bind9.readthedocs.io/en/v9_18_11/reference.html
claims that the de
Jan Schaumann via bind-users wrote:
> Greg Choules wrote:
> > - Are you stuck on 9.16.30 for some reason? If not, grab the latest 9.18
> > package. It will be less memory hungry generally and contain fixes for
> > recent issues.
>
> Yeah, will give that a try.
Upgrading to 9.18.11 by itself di
Greg Choules wrote:
> There could be SO many things going on here. I have a few questions:
All good questions, thanks! :-)
> - Do you mean 200 QPS or 200,000 QPS?
Actually only around 200. I'm effectively looping
over a list of names and calling res_query(3).
> 200 QPS is background noise an
"John W. Blue via bind-users" wrote:
> At the risk of stating the obvious .. have you tried 9.16.37 or 9.18.11?
I haven't yet, but will give that a try.
Thanks!
-Jan
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this soft
Hi Jan.
There could be SO many things going on here. I have a few questions:
- Do you mean 200 QPS or 200,000 QPS? I was wondering if a "k" had missed
the print. If it's really 200, this box (not necessarily just BIND) sounds
very ill. 200 QPS is background noise and (depending what's going on)
sho
...@lists.isc.org] On Behalf Of Jan
Schaumann via bind-users
Sent: Saturday, February 11, 2023 7:14 PM
To: bind-users@lists.isc.org
Subject: named out of swap on NetBSD/amd64
Hi,
I have a local caching resolver running bind 9.16.30 on NetBSD/amd64 9.3.
I'm currently hitting it on localhost
Hi,
I have a local caching resolver running bind 9.16.30
on NetBSD/amd64 9.3.
I'm currently hitting it on localhost with
approximately 200 qps, and it reliably gets killed
after approximately 3 hours with "out of swap"
messages in dmesg.
The system in question is a Xen VPS with 6 GB RAM and
256
12 matches
Mail list logo
