BIND 9.1.2 memory usage
Chris Pile
Hi,
Just wondering how ppl deal with memory usage of named. I had been
monitoring a DNS cache server running BIND 9.1.1, FreeBSD 4.2, with
256MB RAM, 512MB swap. BIND was running from within a jail (like chroot
but better). After about 500 million successful queries (about one
month of use), named was using 170MB. The server was thrashing into
swap and spent too much time reading/writing to disk, this resulted in a
noticeable delay for responding to queries. I restarted named, which
resolved the problem... until it happens again.
I upgraded to BIND 9.1.2, but didn't really see anything in CHANGES that
will solve this problem.
I realise that the server needs more memory, but the question is how
much. Was thinking of just slapping in loads (memory is pretty cheap
considering) to total up to 1GB, but will this be enough? Probably need
to increase the swap size to correspond with the increase in physical
memory. But even then, how do I know that after 6 months, named won't
have grown to 1.2GB and I'm back where I started.
Having read doc/arm/Bv9ARM.ch06.html:
The server will remove expired resource records from the cache every
"cleaning-interval" minutes. The default is 60 minutes. If set to 0,
no periodic cleaning will occur.
So I assume after an hour, expired records are removed from the cache.
Maybe lowering this value will help keep memory down? Any ideas? Does
BIND free memory when it removes expired records?
What is the best solution? How can you guarantee that named will
stabilise around a specific size? I tried playing with the "datasize"
option but named just dies when it reaches the specified memory size
(tested at 10MB). Below are the errors from /var/log/messages:
May 8 12:49:27 ns-cache2 /usr/local/sbin/named[52778]: starting BIND
9.1.2 -u named
May 8 12:49:27 ns-cache2 /usr/local/sbin/named[52778]: command channel
listening on 192.168.1.1#953
May 8 12:54:50 ns-cache2 May 8 12:54:50/usr/local/sbin/named[: client
192.168.1.2#4219: no more recursive clients: out ofmemory
May 8 12:54:50 ns-cache2 /kernel: pid 52778 (named), uid 3001: exited
on signal 6
May 8 12:54:50 ns-cache2 May 8 12:54:50/usr/local/sbin/named[:
client.c:502: REQUIRE((((client) != 0) && (((const isc__magic_t
*)(client))->magic == ( 0x4E534363U)))) failed
May 8 12:54:50 ns-cache2 May 8 12:54:50/usr/local/sbin/named[: exiting
(due to assertion failure)
and:
May 11 14:13:46 dns-cache /usr/local/sbin/named[67038]: starting BIND
9.1.2 -u named
May 11 14:13:46 dns-cache /usr/local/sbin/named[67038]: command channel
listening on 192.168.1.1#953
May 11 14:15:32 dns-cache May 11 14:15:32/usr/local/sbin/named[: client
192.168.1.2#2019: no more recursive clients: out of memory
May 11 14:15:32 dns-cache /kernel: pid 67038 (named), uid 4002: exited
on signal 6
May 11 14:15:32 dns-cache May 11 14:15:32/usr/local/sbin/named[:
client.c:502: REQUIRE((((client) != 0) && (((const isc__magic_t
*)(client))->magic == ( 0x4E534363U)))) failed
May 11 14:15:32 dns-cache May 11 14:15:32/usr/local/sbin/named[: exiting
(due to assertion failure)
Surely this shouldn't happen. Sometimes named stays running when it
reaches the limit, but it doesn't resolve any more queries.
Does BIND remove old records (after having no queries for a particular
record for say, one hour) from it's cache, regardless of the record's
TTL/expire values?
I've read through some postings covering this topic:
http://groups.google.com/groups?hl=en&lr=&safe=off&ic=1&th=1cf8862076f3ff2b,8&seekm=9c53ss%24ndm%40pub3.rc.vix.com#p
Thanks,
Chris.
Kevin Darcy
The cleaning-interval option only controls how often named will purge *expired* records. The "datasize" option just
sets an OS limit on how much memory named will use -- as you have discovered, when that limit is reached, Bad Things
Happen. In a future release, BIND 9 is supposed to be smart enough to free up memory when it reaches the memory limit
(e.g. by expiring cache entries early and purging them).
There is a "max-cache-ttl" option in BIND 9 that could help keep your cache usage down. However, you would have to
experiment very carefully with this. First of all, bear in mind that most Unices have sophisticated virtual memory
subsystems which will page out unused memory. By making the cache expiration/purging more aggressive, you may actually
be touching more memory pages more often and cause your swapping/paging to get *worse*. Also, by defeating your cache,
you'll undoubtedly increase your network traffic, and since network activity needs buffer space too, this may not be a
win overall.
- Kevin