I know this sounds ambiguous at best, but it would be a nice feature none-the-less. I feel the cache should only empty as entries expire. If there was away to restore cached data, or a feature that rolls cache data over. It would be something interesting to test.
Pi-hole does expire the cache as TTL values expire. The only time you should be seeing cache evictions is when the cache is too small and that's a very rare occaision.
Restoring stale cache values seems like it would be kind of a waste of time, how do you see this action being useful?
I can see where you are going at with your statement of it being a waste of time; this models my attached ambiguous statement flying true. The purpose can have many reasons. One being that pi-hole has a rather big cache. Every time gravity updates or some other process that causes FTL to restart/reload brings that high collection to zero. I feel with the higher cache size allotted to pi-hole, it would be beneficial to be able to restore after maintenance functions brought on by pi-hole for example.
And I can see where this may be something helpful but the amount of help would be very small for the amount of work needed.
This would require changes on the level where dnsmasq code is involved and would probably be vetoed for the reason of diverging the code bases.
The performance improvements would be very small, unless you have an upstream that is slow or your uplink is low speed. You may want to look at using unbound as your upstream and allow it to use it's cache as a buffer. Multiple layers of cache is fine, but you do add the complexity of a second daemon to care for.
1 Like
This is an excellent suggestion.
This does not happen all that often, though. Gravity happens once per week. At Sunday morning when everyone is sleeping.
Let me ask two questions to get some more context:
- How many cache entries are still valid when gravity runs?
- How often do you restart/reload FTL?
Concerning question 1: Given that cache entries expire after the TTL is reached (which is seldomly larger than an hour), I guess the answer will be: close to zero.
Concerning question 2: Given that Pi-hole is a set-and-forget kind of software (configure it once and that's it), I guess the answer will be: close to never (after initial configuration). Also note that black- and whitelisting does not involve a cache wiping.
@DL6ER How can we measure how full the cache is at the moment?
Since it's dnsmasq handling that you can use the same methods:
The cache statistics are also available in the DNS as answers to
queries of class CHAOS and type TXT in domain bind. The domain names
are cachesize.bind, insertions.bind, evictions.bind, misses.bind,
hits.bind, auth.bind and servers.bind. An example command to query
this, using the dig utility would bedig +short chaos txt cachesize.bind
You can also send USR1 signal and have it dump the stats to the log:
sudo pkill -USR1 dnsmasq
You cannot (easily). The cache is organized in hash buckets and there is no method available to count the number of still valid cache entries as there is no housekeeping in the cache. Instead, dnsmasq leaves all entries alone and only checks them when new records are to be cached or if a query revealed that a cached entry was expired.
The only way of getting a number is to iterate over the entire cache and check what is still valid. This could, however, be implemented if really needed. I'm not sure what new insight will be created from knowing how much percent of the cache is currently used. In the end, the only important is that there are no evictions (because the cache was too small). This can already easily be checked.
In the meantime, what @DanSchaper suggested will work. But be warned that this will be very verbose and the log file will grow quickly. In addition, mind that DNS resolution will be down while the cache is pretty-printed and dumped into the log file. I don't recommend doing this often.
1 Like
Just for clarification: This PR only makes the data available. It does not add any new graphs anywhere. However, interested users that know how to do so can use any third-party software to gather and display/analyze the DNS cache composition (and filling level) over time.
1 Like
Does your PR have the same limitation?
Yes but really No. Since we are not printing anything but only counting the cache entries, the task should be finished quickly on all possible devices. I just let it run ten times in a row and it took less than 1 msec in total.
Thank you. I tested this and got some interesting insight. Over night, when nobody is browsing, the cache depletes almost completely. Only a few automated lookups to Ubuntu servers stay alive. In the morning, when the first device is used again, the cache fills very quickly and stays at about the same level throughout the day.
Nothing too surprising but this shows that
should not affect the cache filling level in any noticeable way.
Can we have a graph for this on the dashboard? I feel it is a nice addon.
edit Ignore my last question. I came to the conclusion that this may be more harm- than useful.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.