Hello, just want to add some basic info before we get into the issue.
- I had Pi-hole running on an RP 4 since 2019, maybe even 2018 using the same SD card.
- I was running up until a week ago, when I tried to upgrade from buster that I was on, then that failed and found out the SD card was dead.
- Luckily, I managed to grab an export from the GUI right before the crash, so I have the latest config to start with.
- I flashed a new SD card on the same hardware but with version 12, and installed Pi-hole from the link on the website.
So that's the story of how I got here. Now that I am here, I notice that it is not as responsive as my previous installation, and it almost a constant load of at least 0.3, where before it would be around 0 or 0.1 at the most.
Is there a config I am missing or something wrong in my debug that would indicate why it is so unresponsive at times?
It has gotten so bad that I am considering running a docker Pi-hole on my server as a failover. But that's a lot of work to get the physical Pi-hole to advertise the second one as DNS as well to the DHCP clients.
I would appreciate any help.
A new installation on the same hardware should have the same responsiveness.
Load goes up to 4 and higher sometimes, the Pi-hole becomes unresponsive at times.
Take a look at the output of
htop and see what processes on the Pi are consuming the CPU cycles.
A review of your debug log shows the following issues:
Lack of connectivity between the Pi and the network for the interface on which you have Pi-hole configured:
*** [ DIAGNOSING ]: Networking
[✗] No IPv4 address(es) found on the eth0 interface.
[✗] No IPv6 address(es) found on the eth0 interface.
*** [ DIAGNOSING ]: Setup variables
You do have an active connection on a different interface:
pihole -r and select the reconfigure option to get Pi-hole listening on the active interface.
Did the -r, still the same:
htop was the top CPU usage on htop. The rest of the CPU was idle.
It would be highly unusual if htop were using this much CPU.
htop was taking 2%, so it was not taking more than it should.
The image btw is at idle, this was not the case before the clean installation.
Load Averages are not just CPU utilization. Other things like storage device contention (IO Wait) and a few other things that
htop wont show. You could check with
iotop but if you are seeing load averages in the 4 range and
top is not showing any kind of CPU load then you need to look at other places for the slowdown. A good starting point would be a search for "high load average low cpu utilization" for a wide range of troubleshooting options.
You have a Pi R4 so load averages of
0.37 is effectively nothing.
Yeah, but before that it was even less, like I said it was 0 or 0.1 at most.
Well, I came here first in case this is a known issue. It is strange to me, how the same hardware (almost, SD card replaced), same software but clean install on a different OS makes such a huge change.
I did not expect things to run slower on bookworm.
Could this be related to the new SD card? I am planning on replacing it with a usb msata drive for better reliability, but I need to know if that's a possibility here.
I installed iotop, nothing sticks out as problematic so far.
This is when I try to reach the GUI, and nothing happens. Clearly, no process is using the io. I am baffled.
Also, after a restart to RP
much more reasonable and what I am used to seeing.
but it will creep up after a while.
I recommend you visit the forums for the Pi and your OS. This does not appear to be an issue with your Pi-hole installation.
But that's the thing, the load in Pi-hole is the only load reported, I've checked every other measurement, there's nothing there.
You're effectively using less than 10% of the resources you purchased. I'm not sure why you are focusing on using the least amount of resources, when I buy computer hardware it's because I intend to use it fully.
I think you may be missing the forest for the trees though, is the real issue that the web interface is non-responsive and you have made the connection that the sluggishness/pauses are caused by the load? Perhaps we should look at that problem and try to find the solution.
You've mentioned that you installed 12 on the Raspberry Pi. Can you explain how you did that? Currently you have to use a bypass to install on Raspberry Pi OS 12 and I didn't see you mention that. It's also very possible that the new OS has a higher baseline utilization due to the major changes made from 11 to 12.
I just went to the official website, and etched the image to the SD card using balena etcher.
That is the only difference between my previous install and this one. At least from the user side, and not the backend.
Are you running the 32 bit or 64 bit version of RaspberryPi OS?
And, is this a change from your previous install?
Please provide a link to the exact image you selected.
Please explain in detail the exact steps you took to install Pi-hole.
The process of troubleshooting and debugging often involves investigating situations that do not seem obvious at first glance. We can continue to troubleshoot the non-responsive web page but we need detailed answers to our questions, the more detail the better we can investigate. We may ask questions that you feel don't apply but we've been at this for over 7 years and we've investigated countless setups, we don't ask questions that we don't feel apply.
64, and I can't remember if it was 32 before, is 64 a new thing?
I took the lite since I do not need a desktop.
I curled the shell script from the link and ran it like it says here:
curl -sSL https://install.pi-hole.net | bash
Pretty standard stuff, like I said it has been around 5 years since I last did this, things have changed, but not so much.
It's been 32 in the past, really you don't need 64, it's kind of niche. 64 bit can also explain the increased baseline utilization. https://techexplorations.com/guides/rpi/begin/rpi-os-32bit-vs-64bit/
You should have seen a warning that the OS is unsupported, and it really is unsupported at this time. Can you show the contents of the
/etc/os-release file please?
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
I didn't. If I had, I would have noticed, and looked up why it's not supported.
You appear to be running the 64 bit version, which reports as Debian, not Raspbian.
This would not trigger the unsupported OS warning, since Debian 12 is a supported OS.
If your old install was 5 years old, you were likely running 32 bit, because I don't think 64 bit was released at that time.
Pi-hole is indifferent to whether you are running a 32 bit or 64 bit OS (other than Raspbian 12 32 bit being reported as Raspbian and showing as "unsupported" at this point).
Is it possible for you to image with the 32 bit release and see if that resolves the issues? You will need to use the Unsupported OS bypass but I'm pretty sure you will see the load averages drop.
Wait, if 64 is the unsupported OS, and you want me to install the 32 one, why would that one say Unsupported? I am confused here, which is the recommended OS for Pi-hole?
Also, since I got you here, any chance there's a tutorial somewhere on how to have 2 redundant Pi-holes in one network, where one is a DHCP?
I want to set up a docker Pi-hole, so I could experiment with the physical one and not lose internet access while doing so.
(P.S. the docker-compose.yml example uses an old format, there's compose V2 since June, so it may need to be updated.)
- mode: ingress
- mode: ingress
- mode: ingress
- mode: ingress
- type: bind
- type: bind