---
title: "adb: grow_entries and adb: grow_names log messages"
slug: "aa-00548"
description: "These are informational messages about the resizing of hash tables used by recursive servers."
updated: 2018-10-30T19:43:48Z
published: 2018-10-30T19:43:48Z
canonical: "kb.isc.org/aa-00548"
stale: true
---

> ## Documentation Index
> Fetch the complete documentation index at: https://kb.isc.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Why is BIND logging "adb: grow_entries to <number>" and "adb: grow_names to <number>"?

### Question:

Since installing a new version of BIND, I'm getting the following informational messages on starting **named**. What do they mean?

```
18-Nov-2011 03:35:14.872 database: info: adb: grow_entries to 1531 starting
18-Nov-2011 03:35:14.874 database: info: adb: grow_entries finished
```

```
18-Nov-2011 03:36:21.908 database: info: adb: grow_names to 1531 starting
18-Nov-2011 03:36:21.911 database: info: adb: grow_names finished
```

### Answer:

These are just diagnostic (informational) messages about the resizing of hash tables that are used by recursive servers. The feature (which improves run-time performance) was introduced in BIND 9.8.0. Depending on the loading on your server, you may also see them intermittently at other times - usually when there is a peak in query rates, or a spate of queries that are for names with a greater diversity than usual.

2993. [func] Dynamically grow adb hash tables. [RT #21186]

The ADB hash table sizes are never reduced, even if cache (including ADB) is emptied via `rndc flush`. There is no reason to decrease them, as the likelihood is that when repopulated following the flush, cache will once again reach a similar size.

Note on the new functionalityCurrently **named** stalls other activity while this happens because the table being resized is accessed by multiple threads. This stall may or may not become externally noticeable, and if it does, we need to look at implementing a more complicated strategy to grow the hash table. However, we need the log messages now to correlate events and to be able to diagnose whether this is a problem.