BIND-9.16.1 memory leak?

[Michael Sinatra]

On 2020-04-17 06:45, sthaug at nethelp.no wrote:
> We have what appears to be a significant memory leak in BIND-9.16.1.
> 
> Environment:
>  FreeBSD 12.1-STABLE.
>  BIND-9.16.1 installed from packages.
>  Also uses libuv-1.35.0 installed from packages.
>  Authoritative only.
>  Around 800 zones of varying sizes. DNSSEC in use.

Additional datum, as I am seeing the same thing:

- FreeBSD 12.1-RELEASE-p3
- BIND-9.16.1 compiled from ports/poudriere via a local package build
server (no options changed, though, so it likely could have been
installed from the FreeBSD package repo).
- Authoritative only
- `rndc status` reports 1058 zones (69 automatic)
- Host is a VM with 16GiB allocated and 4 CPU cores
- named running for approx 2.5 weeks (wall-clock)

Current BIND status (from `top`):

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU
COMMAND
 1707 bind         14  52    0  5312M  5260M sigwai   2  34.4H   5.79% named

A recursive-only server, running the same versions of all software, on
an identically-provisioned VM, running for the same amount of wall-clock
time (approximately 2.5 weeks) looks like this:

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU
COMMAND
 1485 bind         14  52    0   927M   890M sigwai   3  89.6H  32.86% named

The recursive memory footprint looks normal.

Contrast that with a separate server:

- FreeBSD 11.3-RELEASE-p7
- BIND 9.14.11 compiled from ports/poudriere via a local package build
server (no options changed, though, so it likely could have been
installed from the FreeBSD package repo).
- Authoritative only + recursive only running in a separate jail
- Same configuration as above, only a bit busier
- Host is standalone with 96GiB RAM and 8 cores

In the `top` output below, both the jailed named processes are shown.
The busier one is the authoritative-only:

  PID USERNAME      THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU
COMMAND
  896 bind           18  52    0   956M   927M sigwai  0  99.2H  30.03%
named
 1584 bind           18  52    0  1171M  1080M sigwai  2 166.2H  13.47%
named

It definitely looks like a memory leak in 9.16.1 when configured as
authoritative-only.  The leak seems slow enough as to be manageable, but
the footprint does appear to growing monotonically (and is still
growing--by another 4M as I wrote this email).

michael