Hello I just did a clean install on my raspberry pi model from 2011, 2012 as the board is stamped which included Dietpi and unbound. I noticed when i go to the web UI it loads slow, sometimes giving me an error about number of cores. prior to doing the clean install I never received this error before. I have attached the debug token hoping someone can help or advise what could be the issue.
I just ran cpu to check these stats not sure if they have anything to do with any of the slow loading:
─────────────────────────────────────────────────────
DietPi CPU Info
Use dietpi-config to change CPU / performance options
─────────────────────────────────────────────────────
Architecture | armv6l
Temperature | 43 °C / 109 °F : Optimal temperature
Governor | ondemand
Throttle up | 50% CPU usage
| Current Freq Min Freq Max Freq
CPU0 | 900 MHz 700 MHz 900 MHz
[ INFO ] DietPi-CPU_info | The current CPU frequency may be affected by processing this script itself.
In fairness, the armv6l architecture at 900MHz single core is the original Raspberry Pi 1, which is right at the edge of what Pi-hole plus Unbound can comfortably handle. The slow web UI loading is mostly just the hardware constraint, PHP running on a single armv6l core is going to be sluggish compared to modern setups, and that's expected.
A couple of things that will help. First, switch the CPU governor from ondemand to performance in dietpi-config under Performance Options. The ondemand governor throttles down to 700MHz when idle and ramps up to 900MHz under load, but that ramp-up adds latency every time the web UI makes a request. Keeping it at full speed all the time makes the UI noticeably more responsive.
The "number of cores" error in the Pi-hole admin panel is a known cosmetic issue on single-core systems, it doesn't affect DNS functionality and you can safely ignore it.
One bigger consideration: Unbound adds meaningful overhead on hardware this old because every DNS resolution requires a full recursive lookup starting from root servers. On a Raspberry Pi 1 this translates to noticeably higher CPU usage and query latency compared to simply forwarding to a fast upstream resolver. If the slow UI persists after the governor change, consider whether you actually need Unbound here. Swapping it for Cloudflare (1.1.1.1) or Quad9 (9.9.9.9) as your upstream would lose the recursive resolution privacy benefit but give you much faster DNS performance overall on this hardware.
Pi-hole doesn't use PHP since February 2025 (although AIs always give answers mixing newer and older versions). Please check your sources before answering.
3 Likes
Aha yes, am still waiting on a reply for the other thread.
1 Like
I also run Pi-hole on the very first Pi model with ethernet.
It can be a bit slower rendering the GUI web page but so what.
As long as the DNS replies are snappy.
Its not like I'm staring at the GUI all day long.
Once set, I most often dont access the GUI for months.
EDIT: Oh ps, I still run on the default OOTB CPU governor mode:
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
ondemand
1 Like
That statement could only be true if you'd query a stream of ever different domains under different TLDs, where unbound would have to walk the entire recursion chain for every single label, without any prior knowledge from previous lookups.
However, a home network's DNS requests would typically center around a few hundred often frequented domains, and those domains could easily be held in a cache and refreshed in background - both Pi-hole as well as unbound can do so, and unbound doing so also means that it doesn't have to do all lookups along the chain again (e.g. com for amazon.com would already be known if say google.com had been requested earlier).
Due to that caching of domains, clients won't notice much of a change from changing to public upstreams.
2 Likes
If you're running Pi-hole exclusively on your Raspberry Pi, use a good SD card, try Raspberry Pi OS Trixie Lite 32-bit, disable swapping, and install Pi-hole and Unbound.
My setup runs flawlessly on a Raspberry Pi 2B.
The 2B is running at 900MHz with 1GB of RAM.
Why would you disable swapping?
Some software (not Pi-hole) wont even run if it doesnt have swap.
My Pi 1B has even less memory as yours and is hardly swapping:
$ free -h
total used free shared buff/cache available
Mem: 221Mi 157Mi 41Mi 7.4Mi 79Mi 64Mi
Swap: 511Mi 54Mi 457Mi
1 Like
Ram is even faster then the SD card and it decreases write processes to it.
It doesn't has a huge impact in the regular function but it's also no disadvantage as well.
1 Like
Swap is only addressed if there is no available memory left.
I still have 64 out of 221MB available for normal operations.
I think on my limited setup, it can address swap on Sundays when the gravity update runs.
EDIT: Oh when disabling swap, you'll let the OOM killer/reaper in the door 
1 Like
lots of information to take in here. i was told a while back that the 1st gen raspberry pi was all that i needed to run DietPi and unbound there was really no need or point to update the hardware. if this has since change what should i get update my current model to a better or more efficient one.
besides it being a little sluggish on the webui it seems to run as great as it has since day one. i am currently running DietPi v10.2.3, unbound and pi hole. i thought that DietiPi was the lowest resource version i should run clearly i am wrong. i have been using DietPi OS for years, so others are suggesting running Pi OS Trixie Lite 32-bit.
i have now changed it to performance as well.
I get the impression you're contradicting yourself.
- Why would I start a process I don't need?
- My Pi 2B has twice as much RAM as a Pi 1, and even that one is adequately equipped?
Without swapping, the installation runs very smoothly and unobtrusively. The wear and tear on SD cards is subjectively lower.
No killer/reaper in the door, no out-of-memory effects or freezes.
Just ignore the whole thing and keep doing what you were doing!
1 Like
For "Unforeseeable Circumstances":
I've run two Pi-hole instances for almost 10 years now running from the same SD cards and did not experience any wear/tear symptoms.
Neither for the other Pi's, O-droid and Tinkerboard SBC's that are running here.
1 Like
Haha... I never had any issues since 5+ years without swapping.
It's just a Pi with pihole. A very effective application.
And not very memory consuming.
The only setting I recommend to tweak on a Pi 1B is the "memory split":
https://www.raspberrypi.com/news/new-sd-card-image/
https://www.raspberrypi.com/documentation/computers/configuration.html#memory-split-nonint
On below link, scroll down to "Steal some memory from the GPU" to see how I've done that for the Bookworm release:
Not sure if anything has changed with the Trixie release though!
Before tweaking:
$ vcgencmd get_mem gpu; vcgencmd get_mem arm
gpu=64M
arm=192M
After tweaking and rebooting:
$ vcgencmd get_mem gpu; vcgencmd get_mem arm
gpu=16M
arm=240M
1 Like
Continuing here instead of via PM.
Yes login via SSH/Putty.
And run below one first to check the current memory split and for comparing after:
vcgencmd get_mem gpu; vcgencmd get_mem arm
With Trixie, check if below file exists:
file /boot/firmware/config.txt
Above file can be compared to the BIOS setup on a regular desktop PC.
If exists, run below one to change the memory split:
sudo tee -a /boot/firmware/config.txt <<< 'gpu_mem=16'
Above one appends the text: gpu_mem=16 to the file config.txt.
16MB is the minimum you can assign to the GPU.
Reboot and check again with the vcgencmd commands:
sudo reboot
vcgencmd get_mem gpu; vcgencmd get_mem arm
I believe you can do above trick with all Pi models for if you have no use for the GPU.
More info about that config.txt file below:
https://www.raspberrypi.com/documentation/computers/config_txt.html
1 Like
i ran the cmd and this is what came up:
root@DietPi:~# vcgencmd get_mem gpu; vcgencmd get_mem arm
gpu=16M
arm=496M