... | ... | @@ -22,6 +22,16 @@ The other major change implemented in BIND 9.18 was the replacement of the old i |
|
|
|
|
|
The internal memory allocator kept pools of memory for later reuse and would never free up the reserved memory. The jemalloc memory allocator is much better suited to the memory usage patterns that BIND 9 exhibits and is able to be both fast and memory efficient.
|
|
|
|
|
|
### Resolver Benchmarks
|
|
|
|
|
|
Below are some basic graphs comparing memory usage in BIND 9.11, 9.16, 9.18, and 9.19 (aka `main`).
|
|
|
|
|
|
As you can see, 9.18 and 9.19 memory usage is in the same ballpark as 9.11, but the latency has improved greatly. The 9.16 memory usage is double, as described above (because it uses double the number of worker threads).
|
|
|
|
|
|
![all-resmon.memory.current-docker](uploads/0130242517994173bf12df6c7d9785f6/all-resmon.memory.current-docker.png)
|
|
|
![all-latency-since_0-until_60-2](uploads/bcbd74704b6cce50fcdf29ac131d50d0/all-latency-since_0-until_60-2.png) ![all-latency-since_60-until_120](uploads/7767f7276982a4eda11806cb5130c69f/all-latency-since_60-until_120.png)
|
|
|
|
|
|
|
|
|
## Limiting memory use
|
|
|
|
|
|
The configuration statement [`max-cache-size`](https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-max-cache-size) only affects the DNS cache and ADB (address database). All other memory uses remain unconstrained. This means setting the `max-cache-size` to 100% will eventually allow cache+ADB to consume all system memory and nothing will remain for other uses. This will subsequently trigger [Out-Of-Memory Reaper](https://www.baeldung.com/linux/memory-overcommitment-oom-killer) finding your BIND 9 process and killing it without mercy.
|
... | ... | @@ -138,16 +148,6 @@ jeprof \ |
|
|
|
|
|
More options can be found in [jeprof](https://manpages.ubuntu.com/manpages/impish/man1/jeprof.1.html) manual page. These must be interpreted with knowledge of the BIND 9 internals. That said, if you are reporting what you think is a memory issue, attaching output of the `jeprof` will certainly help.
|
|
|
|
|
|
## Graphs
|
|
|
|
|
|
### Resolver Benchmarks
|
|
|
|
|
|
Below are some basic graphs comparing memory usage in BIND 9.11, 9.16, 9.18, and 9.19 (aka `main`).
|
|
|
|
|
|
As you can see, 9.18 and 9.19 memory usage is in the same ballpark as 9.11, but the latency has improved greatly. The 9.16 memory usage is double, as described above (because it uses double the number of worker threads).
|
|
|
|
|
|
![all-latency-since_0-until_60-2](uploads/bcbd74704b6cce50fcdf29ac131d50d0/all-latency-since_0-until_60-2.png) ![all-latency-since_60-until_120](uploads/7767f7276982a4eda11806cb5130c69f/all-latency-since_60-until_120.png) ![all-resmon.memory.current-docker](uploads/0130242517994173bf12df6c7d9785f6/all-resmon.memory.current-docker.png)
|
|
|
|
|
|
### Catalog Zones Memory Profiling
|
|
|
|
|
|
The output of `jeprof` can look like this (this is how the memory looks like after 1 minute `dnsperf` run):
|
... | ... | |