Contents x
Gathering Information on BIND 9 Memory Usage
  • 02 May 2019
  • 3 Minutes to read
  • Contributors
  • Print
  • Dark
    Light
  • PDF
Contents

Gathering Information on BIND 9 Memory Usage

  • Updated on 02 May 2019
  • 3 Minutes to read
  • Contributors
  • Print
  • Dark
    Light
  • PDF
Article summary

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 -px" 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 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 BIND 9 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 to 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 to 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) for your version of BIND 9.

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()
What's Next

Cookie consent

We use our own and third-party cookies to understand how you interact with our Knowledgebase. This helps us show you more relevant content and ads based on your browsing and navigation history.