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