Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 2/16/22 17:15, Borja Marcos wrote: Now I have 9.11.36, 9.16.24 and 9.18.0 What I have noticed with 9.18.0, which is running on the heaviest loaded server, is less memory footprint. I started it on Monday and according to top it’s taking 486 MB (SIZE) - 375 MB (RES). And the memory pressure is much less. It’a working fine but in ISCs tradition of squeezing bad practices it will give you errors for misconfigured domains. I have had to add some “server” clauses disabling cookies and all that. I am updating the server running 9.16.24 to .25. Let’s see how it goes. Running 9.16.24 it takes 1462 MB (size) - 1233 MB (res). I restarted named on 17th January. The load is not exactly the same. They are both part of an anyast pool, but one of them gets more email server requests while the other one receives mostly customer queries. Awesome feedback! Thanks, Borja :-). Keen to hear what you see re: 9.16.25. Mark. -- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
> On 16 Feb 2022, at 10:53, Mark Tinka wrote: > > Hi all. > > Just coming back to this... > > I notice that the release notes for 9.16.25 say the memory leak issue on > FreeBSD is now fixed: > > * > > On FreeBSD, TCP connections leaked a small amount of heap memory, leading to > an eventual out-of-memory problem. This has been fixed in: > > https://gitlab.isc.org/isc-projects/bind9/-/issues/3051 > > * > > If anyone was running/testing this train prior to this update on FreeBSD as a > resolver, have you seen the problem go away? > > I know Borja was testing, but haven't heard from him in a while :-). I’m here ;) > We are still happily running 9.11.36 on our busiest resolvers, with no issue. Now I have 9.11.36, 9.16.24 and 9.18.0 What I have noticed with 9.18.0, which is running on the heaviest loaded server, is less memory footprint. I started it on Monday and according to top it’s taking 486 MB (SIZE) - 375 MB (RES). And the memory pressure is much less. It’a working fine but in ISCs tradition of squeezing bad practices it will give you errors for misconfigured domains. I have had to add some “server” clauses disabling cookies and all that. I am updating the server running 9.16.24 to .25. Let’s see how it goes. Running 9.16.24 it takes 1462 MB (size) - 1233 MB (res). I restarted named on 17th January. The load is not exactly the same. They are both part of an anyast pool, but one of them gets more email server requests while the other one receives mostly customer queries. Borja. -- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
Hi all. Just coming back to this... I notice that the release notes for 9.16.25 say the memory leak issue on FreeBSD is now fixed: * On FreeBSD, TCP connections leaked a small amount of heap memory, leading to an eventual out-of-memory problem. This has been fixed in: https://gitlab.isc.org/isc-projects/bind9/-/issues/3051 * If anyone was running/testing this train prior to this update on FreeBSD as a resolver, have you seen the problem go away? I know Borja was testing, but haven't heard from him in a while :-). We are still happily running 9.11.36 on our busiest resolvers, with no issue. 9.16. 25 is working fine for our authoritative servers. 9.18 is too new for us. We have no issue keeping 9.11.36 well beyond its EoL date on our resolvers, if it means 9.16 needs further improvements for that use-case. Thanks. Mark.-- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/13/21 09:40, Ondřej Surý wrote: Hi, if you have reliable reproducer, please fill an issue at https://gitlab.isc.org/isc-projects/bind9/-/issues While this mailing list is monitored by the BIND 9 team, it’s more practical to have an issue filled by a person experiencing the problem where we can interact directly and ask additional questions. Scraping the information from the mailing list chatter is very impractical. Michael said he had filed an issue. I'd asked where I can find it so we run off of that: https://www.mail-archive.com/bind-users@lists.isc.org/msg30953.html Or do I need to file an entirely separate one from what Michael submitted? Mark. ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
> On 13 Sep 2021, at 09:40, Ondřej Surý wrote: > > Hi, > > if you have reliable reproducer, please fill an issue at > https://gitlab.isc.org/isc-projects/bind9/-/issues > > While this mailing list is monitored by the BIND 9 team, it’s more practical > to have an issue filled by > a person experiencing the problem where we can interact directly and ask > additional questions. > Scraping the information from the mailing list chatter is very impractical. Thanks, I understand. Right now I don’t have anything solid. As I said, I have not experienced Mark’s serious issue. But trying to assign a bogus address to an unnumbered interface I wasn’t using *seems* to reduce the growth in memory footprint. I said *seems*, so again nothing solid. If I can I will set up a spare non production server and run a stress test with OARC’s tools and some sample data sets. In that case make sure I will report what I find. Borja. ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
Hi, if you have reliable reproducer, please fill an issue at https://gitlab.isc.org/isc-projects/bind9/-/issues While this mailing list is monitored by the BIND 9 team, it’s more practical to have an issue filled by a person experiencing the problem where we can interact directly and ask additional questions. Scraping the information from the mailing list chatter is very impractical. Thanks, -- Ondřej Surý (He/Him) ond...@isc.org > On 13. 9. 2021, at 9:12, Borja Marcos wrote: > > 2- Adding a bogus 127.10.whatever to the spare Ethernet interface I am not > using, per a previous comment on > this thread about a memory leak due to interfaces with no addresses. ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/13/21 09:12, Borja Marcos wrote:
2- Adding a bogus 127.10.whatever to the spare Ethernet interface I am not
using, per a previous comment on
this thread about a memory leak due to interfaces with no addresses.
This issue does need to get fixed. Assigning random, unused IP addresses
to interfaces to avoid a memory leak is messy.
So now I have two recursives running FreeBSD 13, one with libuv 1.41, the other
one with 1.42. The behavior
seems to be similar, I had a slow growing memory usage when there was no IP
address assigned to the spare, unused
Ethernet interface...
Will be good to check with you at the end of the week to see how it's going.
(even though I didn’t put a listen-on { any; }; clause.
This is weird. If you are not listening on all interfaces, why would
BIND care about an interface that has no IP address, then?
Mark.
___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
> On 10 Sep 2021, at 13:30, Mark Tinka wrote:
>
>
>
> On 9/10/21 12:35, sth...@nethelp.no wrote:
>
>> Freebsd 12.2-STABLE here with servers running BIND 9.16.15, 9.16.18
>> and 9.16.20, all using libuv 1.41.0, all installed from ports. Typical
>> query load from around 3k qps to around 14k qps. No sign of any memory
>> leak.
>
> Would be interesting to hear your experiences when/if you do move to
> FreeBSD-13.0.
>
> Still going nice and stable with 9.11.
I haven’t noticed any of that, although the memory footprint seems to be lower
after doing a couple of things.
1- Updating libuv to 1.42 on one of the servers
2- Adding a bogus 127.10.whatever to the spare Ethernet interface I am not
using, per a previous comment on
this thread about a memory leak due to interfaces with no addresses.
So now I have two recursives running FreeBSD 13, one with libuv 1.41, the other
one with 1.42. The behavior
seems to be similar, I had a slow growing memory usage when there was no IP
address assigned to the spare, unused
Ethernet interface (even though I didn’t put a listen-on { any; }; clause.
Borja.
___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/10/21 12:35, sth...@nethelp.no wrote: Freebsd 12.2-STABLE here with servers running BIND 9.16.15, 9.16.18 and 9.16.20, all using libuv 1.41.0, all installed from ports. Typical query load from around 3k qps to around 14k qps. No sign of any memory leak. Would be interesting to hear your experiences when/if you do move to FreeBSD-13.0. Still going nice and stable with 9.11. Mark. ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
>> 2.5 days in, and 9.11 is still running good, with no crashing. >> >> Safe to say that this memory leak is definitely an issue with 9.16. > > Which version of libuv are you using? I am running 1.41 and the latest is > 1.42. > > I haven’t seen that behavior and my recursives handle about 100,000 requests > per minute. Freebsd 12.2-STABLE here with servers running BIND 9.16.15, 9.16.18 and 9.16.20, all using libuv 1.41.0, all installed from ports. Typical query load from around 3k qps to around 14k qps. No sign of any memory leak. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/10/21 10:29, Borja Marcos wrote: Which version of libuv are you using? I am running 1.41 and the latest is 1.42. I'm running libuv-1.41.0. I haven’t seen that behavior and my recursives handle about 100,000 requests per minute. Just in case I have updated libuv on one of them. I see 1.42.0 was released 4 days ago. Also, did you install bind 9.16 from ports or from a package? From ports, which options did you enable? From ports with default options: - DNSTAP - DOCS - IDN - JSON - MANPAGES - TCP_FASTOPEN - DLZ_FILESYSTEM Mark. ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
> On 9 Sep 2021, at 06:59, Mark Tinka wrote: > > 2.5 days in, and 9.11 is still running good, with no crashing. > > Safe to say that this memory leak is definitely an issue with 9.16. Which version of libuv are you using? I am running 1.41 and the latest is 1.42. I haven’t seen that behavior and my recursives handle about 100,000 requests per minute. Just in case I have updated libuv on one of them. Also, did you install bind 9.16 from ports or from a package? From ports, which options did you enable? Cheers, Borja. ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
2.5 days in, and 9.11 is still running good, with no crashing. Safe to say that this memory leak is definitely an issue with 9.16. Mark. On 9/6/21 19:30, Mark Tinka wrote: So I've decided to downgrade our busiest resolvers to bind911-9.11.35. Mark. ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
So I've decided to downgrade our busiest resolvers to bind911-9.11.35. Mark. ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
I'm seriously considering going back to BIND-9.11. Mark. ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/3/21 07:17, Mark Tinka wrote: Let me monitor and report back. Thanks. So since running the updated interface changes from Friday, BIND died again due running out swap space, earlier today. Seems like it may be more than how BIND is listening on various interfaces. Are you able to share a link to the PR you created? Perhaps some have commented... Mark. ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/3/21 01:55, Michael Sinatra wrote:
'listen-on any;' is the default for v4, so you should actually be
listening on 127.0.0.1 in addition to everything else (since all of
your listen-on's for v4 appear to be commented out). You *should* be
able to remove 'listen-on-v6 { ::1; };' and just leave the
'listen-on-v6 { any; };' in place. Doing a 'sockstat | grep named'
on FreeBSD should confirm this once you restart named (pretty sure you
already knew that, but I thought I'd mention it for completeness).
With "listen-on { 127.0.0.1; };" commented out, BIND will listen only
on the main IPv4 interfaces, and exclude just the localhost.
I've changed it to the below, now:
// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
// listen-on { 127.0.0.1; };
listen-on { any; };
// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver. To give access to the network, specify
// an IPv6 address, or the keyword "any".
// listen-on-v6 { ::1; };
listen-on-v6 { any; };
It is now listening on all interfaces, both IPv4 and IPv6 localhost
addresses, as well as the IPv6 link-local addresses.
I've also removed the 'max-cache-size' setting, which should default
BIND to 90% of physical RAM.
Let me monitor and report back. Thanks.
Mark.
___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/2/21 2:59 PM, Mark Tinka wrote:
On 9/2/21 23:51, Michael Sinatra wrote:
I have noticed this also and have opened a (similar but different)
issue, but it's a bit weird how it manifests itself.
On your freebsd installation, make sure that all of your interfaces
are configured and that bind can listen on them. (They don't
necessarily need to be up; they just need to be configured.)
Also, 'listen-on[-v6] any;' is more likely to prevent this kind of
memory leaking than having it listen on explicit addresses. But the
way I can (more) reliably reproduce it is to have a 'listen-on'
statement that references a non-existent interface/address.
I think this is a libuv problem, but I have been really short on time
to troubleshoot. But in the meantime, I would check on your
'listen-on' statements and make sure there aren't any stray addresses
in there.
What we have on all of our name servers is the below:
// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
// listen-on { 127.0.0.1; };
// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver. To give access to the network, specify
// an IPv6 address, or the keyword "any".
listen-on-v6 { ::1; };
It *feels* like the above ^^ could be the culprit. 'listen-on any'
ought to listen on the loopback interface in addition to all other
configured ethernets and loopbacks. OTOH, the libuv-based versions of
BIND (e.g. >=9.16.x) appear to get kind of weird/confused with certain
types of listen-on statements.
listen-on-v6 { any; };
We are running dual-stack on all name servers, and both IPv4 and IPv6
reachability is confirmed solid.
On IPv4, we are listening on just the main interface. On IPv6, we are
listening on both the localhost and the main interface. Not sure if this
matters.
For local resolution on each name server, it refers to localhost for
both IPv4 and IPv6 in '/etc/resolv.conf'. Given our configuration, it's
using ::1 for local resolution, whenever that may be required, since
127.0.0.1 has nothing listening on it. Thanks.
'listen-on any;' is the default for v4, so you should actually be
listening on 127.0.0.1 in addition to everything else (since all of your
listen-on's for v4 appear to be commented out). You *should* be able to
remove 'listen-on-v6{ ::1; };' and just leave the 'listen-on-v6{
any; };' in place. Doing a 'sockstat | grep named' on FreeBSD should
confirm this once you restart named (pretty sure you already knew that,
but I thought I'd mention it for completeness).
michael
___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/2/21 23:51, Michael Sinatra wrote:
I have noticed this also and have opened a (similar but different)
issue, but it's a bit weird how it manifests itself.
On your freebsd installation, make sure that all of your interfaces
are configured and that bind can listen on them. (They don't
necessarily need to be up; they just need to be configured.)
Also, 'listen-on[-v6] any;' is more likely to prevent this kind of
memory leaking than having it listen on explicit addresses. But the
way I can (more) reliably reproduce it is to have a 'listen-on'
statement that references a non-existent interface/address.
I think this is a libuv problem, but I have been really short on time
to troubleshoot. But in the meantime, I would check on your
'listen-on' statements and make sure there aren't any stray addresses
in there.
What we have on all of our name servers is the below:
// If named is being used only as a local resolver, this is a safe default.
// For named to be accessible to the network, comment this option, specify
// the proper IP address, or delete this option.
// listen-on { 127.0.0.1; };
// If you have IPv6 enabled on this system, uncomment this option for
// use as a local resolver. To give access to the network, specify
// an IPv6 address, or the keyword "any".
listen-on-v6 { ::1; };
listen-on-v6 { any; };
We are running dual-stack on all name servers, and both IPv4 and IPv6
reachability is confirmed solid.
On IPv4, we are listening on just the main interface. On IPv6, we are
listening on both the localhost and the main interface. Not sure if this
matters.
For local resolution on each name server, it refers to localhost for
both IPv4 and IPv6 in '/etc/resolv.conf'. Given our configuration, it's
using ::1 for local resolution, whenever that may be required, since
127.0.0.1 has nothing listening on it. Thanks.
Mark.
___
Please 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/2/21 2:35 PM, Mark Tinka wrote: Not sure if this issue offers some clue: https://gitlab.isc.org/isc-projects/bind9/-/issues/2575 I see its maintainer just closed it 11hrs ago... I have noticed this also and have opened a (similar but different) issue, but it's a bit weird how it manifests itself. On your freebsd installation, make sure that all of your interfaces are configured and that bind can listen on them. (They don't necessarily need to be up; they just need to be configured.) Also, 'listen-on[-v6] any;' is more likely to prevent this kind of memory leaking than having it listen on explicit addresses. But the way I can (more) reliably reproduce it is to have a 'listen-on' statement that references a non-existent interface/address. I think this is a libuv problem, but I have been really short on time to troubleshoot. But in the meantime, I would check on your 'listen-on' statements and make sure there aren't any stray addresses in there. michael ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
Not sure if this issue offers some clue: https://gitlab.isc.org/isc-projects/bind9/-/issues/2575 I see its maintainer just closed it 11hrs ago... Mark. ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 9/2/21 16:30, Michal Nowak wrote: Mark, what's the exact BIND 9.16 version which is crashing for you? I started off with 9.16.19 several weeks ago (coming from 9.11), and that was crashing. I upgraded to 9.16.20 last week, and it's crashing too. Why do you say that the reason for crashing is BIND running out of swap? How did you found out? Aug 29 10:56:36 ns-01-emg kernel: pid 59549 (named), jid 0, uid 53, was killed: out of swap space Note that BIND 9.16.19 was tripping over a misplaced assert, see https://downloads.isc.org/isc/bind9/9.16.20/doc/arm/html/notes.html#notes-for-bind-9-16-20. Yes, I saw this and assumed that is what was causing my problem. But alas, given how busy the log files are on a high-load resolver, it was by pure luck that I managed to view the logs at the exact time BIND crashed, last week. Mark. ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 'max-cache-size' Value on FreeBSD-13.0
On 02/09/2021 13:29, Mark Tinka wrote: Hi all. Ever since we moved from BIND-9.11 to BIND-9.16, we've been experiencing 'named' crashing after 24hrs - 36hrs on high-load resolver-only servers, running on FreeBSD-13.0. We found that the reason for this was due to BIND running out of swap space. An increase in swap space by creating a 4GB swap file did not help. So we are now playing with the 'max-cache-size' value in BIND. The system has 15GB of physical RAM. Limiting BIND to 13GB of memory does not work; 'named' still crashes due to a lack of swap space. We have then switched to % values, and it's still crashing for the same reason at 90% and now 80%. We are now testing 70%. Anyone have some idea of how we can get this under control? Is there a possibility that BIND is not properly understanding how much physical RAM is available to FreeBSD, and just burns through it anyway, tripping swap space in the process? I can't think of any reason why BIND would keep burning RAM if it has been told to limit its demand to a certain value or %. All help appreciated. Thanks. Mark. Mark, what's the exact BIND 9.16 version which is crashing for you? Why do you say that the reason for crashing is BIND running out of swap? How did you found out? Note that BIND 9.16.19 was tripping over a misplaced assert, see https://downloads.isc.org/isc/bind9/9.16.20/doc/arm/html/notes.html#notes-for-bind-9-16-20. Michal ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 'max-cache-size' Value on FreeBSD-13.0
Hi all. Ever since we moved from BIND-9.11 to BIND-9.16, we've been experiencing 'named' crashing after 24hrs - 36hrs on high-load resolver-only servers, running on FreeBSD-13.0. We found that the reason for this was due to BIND running out of swap space. An increase in swap space by creating a 4GB swap file did not help. So we are now playing with the 'max-cache-size' value in BIND. The system has 15GB of physical RAM. Limiting BIND to 13GB of memory does not work; 'named' still crashes due to a lack of swap space. We have then switched to % values, and it's still crashing for the same reason at 90% and now 80%. We are now testing 70%. Anyone have some idea of how we can get this under control? Is there a possibility that BIND is not properly understanding how much physical RAM is available to FreeBSD, and just burns through it anyway, tripping swap space in the process? I can't think of any reason why BIND would keep burning RAM if it has been told to limit its demand to a certain value or %. All help appreciated. Thanks. Mark. ___ Please 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
