Updated to latest Pi-Hole and DNS resolving got so slow I had to stop using it.
Pi-hole version is v5.2.2 (Latest: v5.2.2)
AdminLTE version is v5.2.2 (Latest: v5.2.2)
FTL version is v5.3.3 (Latest: v5.3.3)
Pi-Hole is running on RPI 3B+ and before the upgrade yesterday, everything was running smoothly.
How can I downgrade to previous version of Pi-Hole?
slow...? I have a first model of RPi with 256MB RAM and you are slow on RPi 3? I did the same update yesterday. no slow motion.
You’d need to go back to the backup you made prior to the update.
Unfortunately I did not make a backup so no luck with that. Is there an another way to downgrade?
And yes, resolving is now unbearable slow.
If you’d like to figure out why, and solve the issue then we can. Reverting isn’t an easy process and can lose all the data.
I would be more than happy to find out why the damn thing went so slow after upgrading. It's definitely not because of resources, as there´s 65% of memory free and 90% of CPU resources free and now new services are installed on Raspberry. Upstream DNS servers are working as advertised when Pi-Hole is disabled so it's not about that, either.
Debug token please (pihole -d, then choose to upload)
Card ok? Space ok? queries to ram? Or power source...?
As a quick test, can you disable all regex entries and see if that changes the slow resolution?
I tried disabling all my four regex entries but it did not help. Resolving is still slow.
Can you post some dig outputs that show what you are seeing as slow?
dig www.navy.mil
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> www.navy.mil
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22849
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.navy.mil. IN A
;; ANSWER SECTION:
www.navy.mil. 4804 IN CNAME www.navy.mil.edgekey.net.
www.navy.mil.edgekey.net. 143 IN CNAME e16312.dscb.akamaiedge.net.
e16312.dscb.akamaiedge.net. 120 IN A 23.32.105.158
;; Query time: 1551 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: pe joulu 25 20:02:52 EET 2020
;; MSG SIZE rcvd: 132
dig www.hel.fi
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> www.hel.fi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6023
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.hel.fi. IN A
;; ANSWER SECTION:
www.hel.fi. 3580 IN A 137.163.136.41
;; Query time: 2851 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: pe joulu 25 20:04:09 EET 2020
;; MSG SIZE rcvd: 55
Just couple of examples.
Please update to the latest FTL v5.3.4. We meanwhile released a performance fix connected to regex evaluation.
Updated and it is now definitely better. It would be good if there would be a some kind of diagnosis metrics output available, for example how long how long the Pi-Hole is processing resolve. This would enable maybe a more analytical approach on performance debugging.
You should have that information on the admin interface in the query log.
Or check the output from dig:
;; Query time: 2851 msec
Just to add, I updated to 5.2.2 Docker and everything ground to a massive halt.
(I use dnsdist in front of pihole, and dnsdist was reporting huge latency. Rolling back to 5.2.1 resolved the issue for me).
Can't run pihole -up as I'm in a Container. I have pihole -d logs from 5.2.1 and 5.2.2 if of interest.
Also having issues with v 5.2.2 and 5.3.3 of FTL. I'm running it inside a docker container and after upgrade of the docker container the FTL became offline, with no real solution to make it online, downgraded (meaning use of container with tag v5.2.1) and the issue wasn't there no more, so really seams to be a 5.2.2/5.3.3 issue