PiHole on RPi3B+ went from working to barely responsive

Expected Behaviour:

PiHole on a dedicated RPi 3B+ should be able to serve as DHCP and DNS blocking for a home network, ~40 total connected devices (a few computers, some phones/tablets, and other various internet connected devices).

Actual Behaviour:

PiHole FTL has started taking 100% CPU time, and DNS requests sent to PiHole went from mostly working to taking 30+ seconds or timing out completely.
Bypassing PiHole yields good internet speeds with ads. Even SSH into PiHole or pinging pinhole leads to instability and ~75% packet loss. Connecting Pi to physical KBM allows for basic management.

Debug Token:

Many attempts made to generate debug log. Either times out (web interface connected to Pi admin console) or get the error 'There was an error uploading your debug log' when running on the RPi directly.

These are the tale-tale signs of other lingering issues underneath the hood, going on with your system.

There could be several issues, starting with the available storage (what's the output of df -h ?) , SD starting to "fade out", system errors ...

What is the output of these commands from the Pi terminal - we are looking at the load on the Pi-Hole and free memory.

echo ">stats" | nc localhost 4711

free

ls -lh /etc/pihole/pihole-FTL.db

ls -lh /var/log/pihole.log.1

dig flurry.com

echo ">stats" | nc localhost 4711
domains_being_blocked 4632621
dns_queries_today 545
ads_blocked_today 333
ads_percentage_today 61.100918
unique_domains 26
queries_forwarded 60
queries_cached 152
clients_ever_seen 4
unique_clients 4
dns_queries_all_types 545
reply_NODATA 27
reply_NXDOMAIN 335
reply_CNAME 6
reply_IP 143
privacy_level 0
status enabled

Trying to run the rest of those commands, but it is taking some time, I'll post one at a time when I can get them running.

free
              total        used        free      shared  buff/cache   available
Mem:         949448      543544       43980       33024      361924      321280
Swap:        102396       12288       90108
ls -lh /etc/pihole/pihole-FTL.db

-rw-r--r-- 1 pihole pihole 41M Mar 22 15:58 /etc/pihole/pihole-FTL.db

-rw-r--r-- 1 pihole pihole 20K Mar 22 15:33 /var/log/pihole.log.1

dig flurry.com

; <<>> DiG 9.10.3-P4-Raspbian <<>> flurry.com
;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52461
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:
;flurry.com. IN A
;; Query time: 1393 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Mar 22 15:58:56 PDT 2019

;; MSG SIZE rcvd: 39

The 3B+ is a few weeks old, and only has PiHole on it. Everything is basically brand new. Here is df -h output:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        28G  3.3G   24G  13% /
devtmpfs        460M     0  460M   0% /dev
tmpfs           464M  7.7M  456M   2% /dev/shm
tmpfs           464M  6.3M  458M   2% /run
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           464M     0  464M   0% /sys/fs/cgroup
/dev/mmcblk0p6   68M   22M   47M  33% /boot
tmpfs            93M     0   93M   0% /run/user/1000
/dev/mmcblk0p5   30M  1.6M   27M   6% /media/pi/SETTINGS
tmpfs            93M     0   93M   0% /run/user/999

I also just checked, and Bluetooth and Wifi are both off (Bluetooth had been on, but I'm not using it, so I turned it off).

Should I be using Wifi or Wired for this application? I assumed Wired was best, correct?

That is on huge chunk of blocked domains ... I believe it does have something to do with the delays (on that particular hardware)...

For testing purposes, try restoring the default blocklists, update gravity and see how that goes...

https://discourse.pi-hole.net/t/how-can-i-restore-pi-holes-default-ad-lists/4683/3?u=ramset

I've disabled all of the other block lists.

Have discovered something interesting with the DHCP server now:
Devices will not get addresses automatically from DHCP, but if I manually configure the device to have the same IP as the reservation, then things tend to be fine. Still can't get anything to resolve through the PiHole in less than 30 seconds though, but gravity is still updating.

You can use a DHCP probe tool to request a lease from the DHCP server and dump the contents for analysis.

(this might work: GitHub - JohannesBuchner/DHCProbe: Send a DHCP request to DHCP server to check its configuration)

No rogue DHCP servers present ?

No rogue DHCP servers, I'll have to see how I can do that probe (this is already stretching my skillset and knowledge).

I figured that the PiHole DHCP solution would 'just work' but its been a lot of trouble. I suppose I can turn it off and go back to having the ORBI handle DHCP and I'll just live without granular device logging (which was really helpful to fine tune getting ads blocked and white lists correct).

It does :slight_smile: it's been serving DHCP leases (out of the box) in my home network for years now :slight_smile:

Most likely there are configuration issues there that prevent you form enjoying Pi-hole to it's fullest potential.

I still can't get the RPi to reliably respond to a ping, so I guess its no surprise that DHCP is failing.

In other news, looks like gravity failed to update because the PiHole can't update the lists. Any idea what would prevent PiHole itself from getting online now?

edit

/etc/resolv.conf

and change from 127.0.0.1 to 1.1.1.1.

Try again after that.

You can rename the existent adlists.list and create a new one with hose default links from the reply above.

Then run a pihole -g

Finally got a Debug Token after forcing a Gravity update:

https://tricorder.pi-hole.net/iifszdf97t!

I could not generate this from the RPi directly, since it could not get online, but I was able to connect from another machine on the network, which I have configured to use a regular DNS server, bypassing the PiHole.

Does that log help at all?

There seems to be a package available for dhcp probing.

sudo apt install dhcp-probe

here's the manual:

https://packages.debian.org/stretch/dhcp-probe