In previous pihole versions, when a list download failed, the previously cached version was used. These cached lists could be found in /etc/pihole, example: list.3.bitbucket.org.domains. In pihole 5, these lists only appear to exist while the list is processed, it is deleted as soon as processing is…

Improve gravity performance release/v5.0 ← tweak/gravity_performance opened 03:48PM - 24 Jan 20 UTC (UTC) [image] DL6ER …

[image] jpgpi250: do I enter this to go to the new branch on a pihole v4.3.2 system? Yeah, that should have much the same affect as checking out that branch from a 5.0 system. If you want to be safe, go from 4.3.2 to 5.0, and then check out the gravity performance branch of core afterward. Bu…

Can you please just cache every list so if the download in the future fails it can be re-used? I believe you didn't think about server failures when removing this feature. Also /var/cache is a thing btw, there is no need to keep it in /etc.

[image] jacklul: Can you please just cache every list so if the download in the future fails it can be re-used? Asked and answered earlier: [image] DL6ER: edit It turns out we keep them, but we moved them into the migration_backup directory. This is now fixed.

Thank your for another enlightening explanation, @DL6ER :wink: [image] DL6ER: Only then, the database is written to and the tree is built up (as the index is populated). I see no way how this could be implemented any better. I took a glance at the DDL from Templates/gravity.db.sql. My under…

[image] jfb: minus https://wally3k.github.io (which is not a blocklist but is a collection of blocklists, and cannot be parsed by Pi-Hole) Removed it from my lists for all tests. I've typed this during the pihole -g wait periods, so forgive me, if some comments are no longer necessary or val…

[image] Bucking_Horn: I took a glance at the DDL from Templates/gravity.db.sql . Be warned, this file is not the sole source of truth. You'll also have to check the gravity migration upgrade scripts... This is something that is not very nice, however, it ensures that everyone at any level of …

[image] DL6ER: There should be no triggers on the gravity table, did I miss something? No, I suppose it's rather my understanding of your DB design that is lacking :wink: I only saw a bunch of triggers on several of the list tables, none for gravity itself.

[image] jpgpi250: my earlier suggestion to build gravity in a temp table eliminates the need to flush it… This is already implemented. You should already see [image] DL6ER: [✓] Preparing new gravity table instead of [image] DL6ER: [✓] Flushing gravity table [image] jpgpi250…

[image] jpgpi250: gravity_performance produces only 25% of the beta5 result I found a typo because of which only the last downloaded list was actually used. Fix pushed.

running pihole -up [✓] Installing latest logrotate script [i] Backing up /etc/dnsmasq.conf to /etc/dnsmasq.conf.old [✓] man pages installed and database updated [i] Testing if systemd-resolved is enabled [i] Systemd-resolved is not enabled [✓] Restarting lighttpd service... [✓] Enabling light…

Pi-hole Userspace

Pihole -g / List download / disappointing performance

General Beta 5.0

show post in topic

Home
Categories
Guidelines
Terms of Service
Privacy Policy

Powered by Discourse, best viewed with JavaScript enabled