Knowledge Base ISC Main Website Ask a Question/Contact ISC
Gathering Information on BIND9 Memory Usage
Author: Michael McNally Reference Number: AA-01208 Views: 4953 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:


  1. BIND version and compilation options, as reported by "named -V"
  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.
  3. We 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. 
  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
May not be suitable for many Production Environments

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.

  1. 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.
  2. 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.
  3. 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).
  4. 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).


Other runtime options for named -m

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 Consortium

For 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.

Feedback
  • There is no feedback for this article
Quick Jump Menu