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
_______________________________________________
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users
