Gathering Information on BIND 9 Memory Usage
- Updated on 15 Oct 2018
- 3 minutes to read
Some problems that can occur with a program are (relatively) easy to isolate. A log message may indicate what the server was doing when a crash occurred, or the stack trace printed when a crash occurs may point to a certain section of the code.
However, problems such as memory leaks, where symptoms become apparent only over substantial periods of time, are not as easily pinpointed. If you suspect a memory leak in BIND 9 you can help us most by providing as complete a picture as is practical of what the nameserver was doing from the time it began execution to the time excessive memory use became apparent.
In particular, it would be most useful to us if you could provide the following information:
2. Information about the operating system and hardware on which your nameserver is running, including:
- OS name
- kernel identification (from "uname -a")
- processor architecture and number of CPUs
- amount of physical memory present
- swap space available (if known), and
- whether the server is running on virtualized hardware or not.
4. A series of measurements (with corresponding timestamps) showing memory growth over time, taken with the ps command or another utility which shows per-process memory usage. A single data point tells us very little but a profile of growth over time can be very revealing.
5. If your named binary was built with support for XML or JSON statistics and you have the statistics channel enabled in your named.conf, a series of statistics snapshots, with corresponding timestamps, could also be helpful.
6. Log files corresponding to the time period shown in the measurements from (4) and (5) will help tell us what the server was doing during the growth period.
7. If you are asked by ISC developers to provide a core file, please ensure that you also provide copies of the named binary that generated the core file, as well as any shared libraries used, so that the symbol table information is available to debuggers.
Additional Information-Gathering Options
BIND has several built-in options for collecting memory statistics for debugging. These are not enabled by default, but can be used to provide additional data to ISC to assist in troubleshooting memory leaks and unexpected memory consumption issues. Options 1 and 2 below are likely to be the most useful.
named.conf option memstatistics - uses extra memory to keep a record of each memory location in order to match them up on free. The collected statistics will print when named is stopped and will show which allocations have not been freed.
Runtime option: named -m record - uses extra memory to keep a record of each memory location in order to match them up on free. The collected statistics will print when named is stopped and will show which allocations have not been freed.
Runtime option: named -m trace - logs each allocation and free (note that this will have an extremely severe impact on named's performance due to the vast amount of logging output).
Runtime option: named -m usage - logs whenever the maximum in-use memory increases its size (i.e. it passes the high-water mark).
For details on the above, refer to the BIND Administrator Reference Manual (ARM) for your version of BIND 9.
* named -m size - checks that the size argument being passed to isc_mem_put() matches that passed to isc_mem_get()
* named -m mctx - checks that the mctx argument being passed to isc_mem_put() matches that passed to isc_mem_get()