[Pdns-users] Recursor Cache Sizing: Is more always better?

Winfried walists at mailbox.org
Tue Sep 12 12:20:09 UTC 2023


Hello Christoph,

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 [1] 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 
phase.

> 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
> max-packetcache-entries
> 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.

Winfried
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20230912/6575459f/attachment.htm>


More information about the Pdns-users mailing list