On 2020-04-17 06:45, sth...@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 _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users