Long storry short : I was very happy with v5 but all of a sudden dns query were not resolved using cloudflare dns. So I updated
Now clouflares resolving still do not work, but also my web gui.
I see lighthttp errors in the log, but not sure how to fix that.
Also at first web interface wasn't working at all so I ran those command lines I found on another topic
sudo chmod 755 /var/www
sudo chmod 755 /var/www/html
*** [ DIAGNOSING ]: System hardware configuration
[i] lshw -short
H/W path Device Class Description
========================================
system Raspberry Pi Model B Rev 2
/0 bus Motherboard
/0/0 processor cpu
/0/1 memory 429MiB System memory
/1 usb1 bus DWC OTG Controller
/1/1 bus USB hub
/1/1/1 eth0 network Ethernet interface
*** [ DIAGNOSING ]: Processor details
[i] lscpu
Architecture: armv6l
Byte Order: Little Endian
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
Vendor ID: ARM
Model: 7
Model name: ARM1176
Stepping: r0p7
CPU max MHz: 700.0000
CPU min MHz: 700.0000
BogoMIPS: 697.95
Flags: half thumb fastmult vfp edsp java tls
I noticed that :
*** [ DIAGNOSING ]: Pi-hole FTL Query Database
-rw-r----- 1 pihole pihole 1.5G Feb 21 03:33 /etc/pihole/pihole-FTL.db
Can this be an issue ? <= EDIT : This is the issue
I guess the bottleneck is the CPU overload.
I stopped pihole service and CPU is quite iddling now (sudo systemctl stop pihole-FTL)
Can there be an issue with my gravity list (quite large around 800k entry) ?
But it runned fine with pihole v5
Before reinstalling from scratch and restoring config backup, I gave this a try :
sudo du /etc/pihole/pihole-FTL.db -h
DB was 1.5Gb
sudo pihole flush
sudo systemctl stop pihole-FTL
sudo rm /etc/pihole/pihole-FTL.db
sudo systemctl start pihole-FTL
sudo du /etc/pihole/pihole-FTL.db -h
DB is 92K
Now pihole CPU usage is back to something acceptable and GUI is browsable.
The default database log lifetime has been reduced from 365 to 91 days. Is that log actually truncated during migration?
And the high CPU usage is only there while the web UI is loading, right? So it seems like the database backend of the web UI has issues with large databases in certain cases. Having the lifetime reduced may help (no one needs a full year of query logs by default), so if it is currently not truncated during migration, that can further help for migrated setups, before having a look into why CPU usage can go up that high.
Does memory usage raise significantly when accessing the web UI? I see 30.9% on the screenshot, but not sure whether this includes swap space or not. Possible that the database backend loads too much of the database into memory, leading to swapping, which is extremely slow with an SD card. Just an idea. ... there are two reports on GitHub where memory usage goes up, but not that much, with at least only some of the swap space used:
