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