Gathering Information on BIND9 Memory Usage
| Author: Michael McNally Reference Number: AA-01208 Views: 5056 Created: 2014-09-18 06:27 Last Updated: 2014-09-29 16:28
0 Rating/ Voters
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:
- BIND version and compilation options, as reported by "named -V"
- Information about the operating system and hardware on which your nameserver is running, including:
need to see your named.conf to understand what BIND features you are
using; this will help us narrow our search. Please omit secret
information such as shared keys -- we have no need for it -- but it is
otherwise helpful to us to see the
configuration that is in use. Please be sure to also provide any files
that are incorporated into the configuration by the "include" directive
or use "named-checkconf -p" if your version of BIND supports it. 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.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.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.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.
- 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.
Additional Information Gathering Options
The additional suggestions below for monitoring and troubleshooting BIND9 memory use may consume more CPU, and other system resources. Server performance may be impacted as a result.
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 top 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 top 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
There are two other named -m options: size, and mctx. Although these can be valuable in other circumstances, they're not useful for gathering information about memory usage.
- 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()
© 2001-2017 Internet Systems ConsortiumFor assistance with problems and questions for which you have not been able to find an answer in our Knowledge Base, we recommend searching our community mailing list archives and/or posting your question there (you will need to register there first for your posts to be accepted). The bind-users and the dhcp-users lists particularly have a long-standing and active membership.ISC relies on the financial support of the community to fund the development of its open source software products. If you would like to support future product evolution and maintenance as well having peace of mind knowing that our team of experts are poised to provide you with individual technical assistance whenever you call upon them, then please consider our Professional Subscription Support services - details can be found on our main website.