named out of swap on NetBSD/amd64

Greg Choules gregchoules+bindusers at googlemail.com
Wed Feb 15 18:56:24 UTC 2023


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 "named_dump.db" in named's working
directory. Grep for NXDOMAIN in that file.

Cheers, Greg

On Tue, 14 Feb 2023 at 15:29, Jan Schaumann via bind-users <
bind-users at lists.isc.org> wrote:

> Jan Schaumann via bind-users <bind-users at lists.isc.org> wrote:
> > Greg Choules <gregchoules+bindusers at googlemail.com> 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 did not help, but
> setting an explicit 'max-cache-size' does seem to.
>
> The queries I'm doing right now are all unique
> second-level domain queries, so no caching takes
> place, while at the same time the cache grows
> proportionally with the queries.
>
> 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 default 'max-cache-size' is 90% of
> physical memory, but it seems that didn't work out
> here.  Might it be that on NetBSD, bind doesn't
> correctly determine the physical memory amount?
>
> -Jan
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230215/e338d4a5/attachment.htm>


More information about the bind-users mailing list