unbound-control dump_cache / load_cache

W.C.A. Wijngaards wouter at nlnetlabs.nl
Mon Jan 4 14:29:49 UTC 2016

Hash: SHA256

Hi Havard,

On 30/12/15 00:28, Havard Eidnes via Unbound-users wrote:
> Hi,
> a while back I needed/wanted to reconfigure my unbound recursor to
> have more memory available for the "rrset cache", in what seems to
> be a futile attempt at increasing the cache hit rate.
> This would cause unbound to discard its cache in its entirety.  I 
> thought that in order to soften the blow for the users, I would use
> the "dump_cache / load_cache" operations of unbound-control so that
> I could (more or less) restore the state of the cache across the
> reconfiguration.

Unbound stores the expired rrsets still in cache, they are evicted
when space is needed for better contents.  You do not have better
contents (eg. your low cache hit rate).

Did you increase the message cache size (to about half the rrset cache
size) ?  That one also needs to be bigger, it stores message details,
like RCODEs.

If you were to increase the rrset cache without the message cache, it
would store a lot of rrsets, but they would not actually be referenced
by the message cache and thus not be used for cache responses.

Best regards, Wouter

> However, despite my unbound-control "stats" saying via 
> "mem.cache.rrset" that it had lots of memory consumed for caching
> -- at the time around 2GB, current values are
> mem.cache.rrset=1357501872 mem.cache.message=4587299 
> mem.mod.iterator=16540 mem.mod.validator=32503056
> i.e. 1.3GB of data in the "RRSET" cache, the result of dump_cache 
> came to only around 43MB (a re-dump just now gave 36MB), and the 
> mem.cache.rrset value was dumped nearly to zero by the reconfigure 
> and increased much after load_cache was performed.
> So ... is dump_cache doing a rather incomplete job of dumping the 
> cache?
> What got me started on this path was that I'm observing that the
> cache hit rate of my unbound name server (collected via a collectd
> plugin, graphed with grafana) is ... rather pitiful, typically
> hovering somewhere around 60-65%.  I've configured it to do
> "prefetch", but I'm seeing a rather low rate of prefetches -- below
> 5%, and my other recursor, running BIND, appears to see 75-80%
> cache hit rate (which isn't all that great either, but appears to
> do marginally better...).
> It is admittedly the "quiet season" now, so the daily query rate
> is rather low, but I'm stil left wondering if there's something
> which could be done about the cache eviction policies to increase
> the cache hit rate?  And I'm left wondering what all that memory
> which doesn't show up in "dump_cache" is used for...
> Best regards,
> - Håvard

Version: GnuPG v2


More information about the Unbound-users mailing list