Hi,
I'm faced with the question if my unbound's cachesize is large enough.
The ideal size is reached, if unbound discards entries from the cache
*only if* their ttl was expired.
Could anybody recommend a testplan, which values should be measured?
Thanks & Merry Christmas!
Zitat von Andreas Schulze <andreas.schulze@datev.de>:
Hi,
I'm faced with the question if my unbound's cachesize is large enough.
The ideal size is reached, if unbound discards entries from the cache
*only if* their ttl was expired.
I doubt that the input queries and the result sets are that static so it isn't really useful to get the "optimum" value at some point in time. For most cases it would be best to raise the RAM limits until the performance is as needed and add some room to grow if RAM is available.
Could anybody recommend a testplan, which values should be measured?
You might try to get something useful with
http://www.unbound.net/documentation/unbound-control.html
Thanks & Merry Christmas!
Fröhliche Weihnachten
Andreas
Heya guys,
I'm faced with the question if my unbound's cachesize is large enough.
The ideal size is reached, if unbound discards entries from the cache
*only if* their ttl was expired.
You won't be able to fit all DNS records in your cache except if you have 2 or 3 users always hitting the same websites. Rule of thumb is if you have free RAM use it! For your cache usage, use unbound-control with extended-statistics: yes to see your usage.
To summarize, your cache won't be big enough to cache the whole Internet 
So use the maximum available RAM you have and start from here (keep some space for your OS:).
Thomas
When dealing with the cache you should take the following into account:
* MSG cache contains packet data and meta data with pointers to the RRsets in the RR Cache
* RR Cache contains RRsets
* Cache entries are removed only when needed: Caches will grow to their maximum size. (Unbound will not do any pro-active cleanup).
If you use 'prefetch' you will keep the cache populated with popular requests.
Setting the RR cache about twice MSG cache is reasonable but if you really want to know what the optimal setting is in your environment you should turn on extended statistics and feed them into munin. By flushing the cache and assessing how the message and RRset cache grow you can estimate the ratio between the two.
For example see the image from munin below. You should take the estimate from the area where the memory is still not saturated (where the blue line is still rising, you see that the RRset cache size need is a little more than twice the message cache size need). You can also see that the RRset cache is saturated while the Message cache is still growing. This is an indication that the RRset cache is configured sub-optimal. If they saturate at more or less the same point the ratio is optimal.
Hope this helps.
--Olaf
