[Pdns-users] Recursor Cache Sizing: Is more always better?
walists at mailbox.org
Tue Sep 12 12:20:09 UTC 2023
On 12.09.23 13:35, Christoph via Pdns-users wrote:
> Hi Winfried,
>> My recommendation is to limit the TTL to 12 or 6 hours and find out
>> how many cache entries are created during this time. Increase that by
>> 50% and that's your value.
> thanks for your recommendation. I've played a bit with this to see what
> max-cache-entries values this procedure would result in.
> What input should influence whether this should be done with a
> max-cache-ttl of 6, 12 or 24 hours?
> The change to max-cache-ttl  to N hours would just be temporary,
> during the collection of the cache-entries metric, and be set back to
> 1d (default) after that or stay at N hours?
It stays at N hours.
> Should this procedure be done with refresh-on-ttl-perc=0 for the data
> gathering phase?
If you use prefetching, I would also turn it on for the data gathering
> In any way, the approach results in a significantly larger
> max-cache-entries setting than we currently use.
If max-cache-entries is too small, cache cleaning will also delete cache
entries whose TTL has not yet expired.
> Does the same apply to other caches like
> aggressive-nsec-cache-size and
> dnsdist's packetCache maxEntries?
Yes. But in my opinion, maxTTL=900 can be used with dnsdists cache. This
reduces the time how long RRs are cached in dnsdist to 900s, and with it
the cache size. However, the expiring TTL that was originally supplied
by the Recursor is delivered, so the clients does not see this
reduction. 900s is enough to still serve most out of the dnsdist cache
under heavy load. The additional latency due to cache misses is not
significant because the Recursor cache catches these requests.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pdns-users