unbound-control dump_cache / load_cache

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
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
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWioHcAAoJEJ9vHC1+BF+N6dUP/0TQykIU/HzMFcHVUwtT7K0r
k1YEI+dq2MtF3FiiB9/Z8P9vmyPfCwlKn6l2uTjA/tp3UKe18ZMT4/FlccBO+t1y
Vv+KzyLxO17H2OKaZXak6I1XTnfl7h6+CI/HiGHx7kE2bMhVUJn1+Ab24d16/1DF
vnW29YUGZ7R2cELHtB4KEbOSeJj+RTrCWV9aH2JsLw2KatLdK7umuhkzIPFm9GS7
543g+3Kw2khwQfXF9ETIwP9guUo5wSPS633CdMDm6A5Jo5IQvhpKn5AnfIPv6nIz
og8BZbU62NnHCd3b6jBjPH+uyxIMTkAzAZ/mE9je3ywCH4QhN85E8wwJuV08aYCA
2VPUwDdjmifvN5XQQQmuZfwO2vwn4BGVInogRf2SQULY1N+p5OiOsxwX+Ee01Wq6
2WXppLe68GLujnF6QK/zOyFO1V+KzBv1Q2Y8ZBrcD1dDRCF09vKUAYhAI6L1ZcSG
0VNtX2lhDrod6uy+ACjs3aTd+se7CL6EyJNUkrJVVW3yIKVPSXDaqTMljtSyKGLa
rAkauMrC8VgTQM9u/fS1I8oFFqiRfwLSnl+mgMfNXDazP2OcD7vbRYISDWptb8N7
x/l6JX6zCii1gYeplbXcI0rRW7+cGoY3JHH2tatB0ctWfgT7l7Z/UDmmmA24aoHd
FhHIPYsc8c00zyJ7VwQL
=wtQ8
-----END PGP SIGNATURE-----