... | ... | @@ -48,4 +48,29 @@ smem provides less details, so if you want only "single" number run `smem -P nam |
|
|
There are couple of explanations why the numbers reported by the BIND 9 statistics channel might differ from the memory usage reported by the operating system.
|
|
|
|
|
|
External libraries - BIND 9 uses several external libraries - OpenSSL, libuv, libxml2, json-c and possibly others. All these also need memory from the operating system to operate. The difference should not be large, but it's also not negligible. If the difference between the used memory reported by the internal statistics channel and USS is large (on a busy server), then congratulations, you've found a leak in external library. (NOTE: BIND 9.19 - the development version - provides own memory context for OpenSSL, libuv and libxml2 if the library versions are recent enough.)
|
|
|
Memory fragmentation - there's quite a churn in the memory allocations and deallocations on the busy server, and memory gets fragmented - the default Linux allocator isn't particulary good with the BIND 9 memory usage patters. Using jemalloc is strongly recommended as it handles the memory fragmentation much better and is also faster. |
|
|
\ No newline at end of file |
|
|
Memory fragmentation - there's quite a churn in the memory allocations and deallocations on the busy server, and memory gets fragmented - the default Linux allocator isn't particulary good with the BIND 9 memory usage patters. Using jemalloc is strongly recommended as it handles the memory fragmentation much better and is also faster.
|
|
|
|
|
|
## Memory Profiling
|
|
|
|
|
|
When compiled (or even linked using `LD_PRELOAD`), `jemalloc` can produce **heap** snapshots based on triggers (time, size, ...). This can be later analysed using `jeprof` tool to see where did the memory went.
|
|
|
|
|
|
The very basics would be:
|
|
|
```
|
|
|
export MALLOC_CONF="abort_conf:true,prof:true,lg_prof_interval:19,lg_prof_sample:19,prof_prefix:jeprof"
|
|
|
export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2 # you don't need that if compiled with jemalloc
|
|
|
/usr/sbin/named # use your normal options and configuration that you use in production
|
|
|
```
|
|
|
|
|
|
You'll most probably need to fine tune the `lg_prof_interval` and `lg_prof_sample` numbers (it's **log base 2**) if there's too much file or too little.
|
|
|
|
|
|
After running the benchmark or the regular workload, you should end up with bunch of `jeprof.<pid>.<m>.i<n>.heap` files. Pick the latest and run:
|
|
|
|
|
|
```
|
|
|
jeprof \
|
|
|
--show_bytes \
|
|
|
--nodefraction=0 \
|
|
|
--exclude="default_memalloc|mem_get|isc___mem_get|isc__mem_get|mem_allocateunlocked|isc___mem_allocate|isc__mem_allocate|isc___mem_strdup|isc__mem_strdup" \
|
|
|
/usr/sbin/named **HEAP FILE** --pdf > "jeprof.pdf"
|
|
|
```
|
|
|
|
|
|
More options can be found in [jeprof](https://manpages.ubuntu.com/manpages/impish/man1/jeprof.1.html) manual page, and can't be taken as is, but must be interpreted with knowledge of BIND 9 internals. That said if you are reporting what you think is a memory issue, attaching output of the `jeprof` is certainly going to help. |
|
|
\ No newline at end of file |