Slow loading of pages when navigating the web UI, dnsmasq signal 17 logged to FTL.log #2284
Comments
|
My setup having similar issue, DNS unresponsive every 10s. |
|
I had the same problem, but increasing memory should not be necessary. Pi-Hole is hardly using any. FWIW, I found that double clicking any of the left menu items provided an immediate response. |
|
DNS resolution works fine, doesn't seem afflicted by whatever is causing the sluggishness of the web UI. The docs still suggest 512 MB of RAM as the base requirement (I am currently running 1 GB now), but I will try bumping up to 2 GB to see if that helps, especially since I am also running unbound in the same VM. EDIT: Bumped to 2 GB of RAM, made no difference, so I've reverted back to 1 GB. |
|
Updated to v6 this evening; had to pull it off my network. Pi 3B, very very poor UI and DNS performance. |
|
|
|
Came to log this issue, but found one already here. I can confirm the same behaviors as listed above. I upgraded to v6, and noticed the change. In an attempt to resolve, I used teleporter backup, uninstalled pihole, clean install, and restored the backup. No improvement. |
|
Just voicing my voice with the same experience. |
|
I made a fresh install for testing in a VM running Debian. I have no clients pointing to this pi-hole instance, but I can confirm every page load takes 30s. BUT for me this only happens in Safari. Strange enough it works like charm in Chrome. Dunno if that helps. |
|
I tried doing safari, edge, and arc, all are slow. Edge seems slightly faster than the others. There is also a noticeable CPU utilization spike when attempting to load any page. |
|
Mine is running in an LXC container on Proxmox. Had issues with the update from v5 to v6, so I spun up a new container and installed v6 from scratch (Debian 12.7.1 as the base). The only issue I'm having is the cpu usage (shows up to 200% at times, but the load values are pretty close to the production v5 instance, so idk), and the ui slowness.
I get the same result using Safari
I found the same. Really slow in Safari (except noted above) and links are instantaneous in Chrome. edit to add versions and other info: |
Ooooooh what a nice find. I can confirm the same. Double clicking any link in the side bar immediately loads the page in Safari for me as well. A single click though takes 30s. Again Chrome is instant with just a single click. I don't observe any high cpu spike or anything on my VM. The machine is basically idling. So I assume this is somehow browser related... Edit: Core version is v6.0.4 (Latest: v6.0.4) |
|
Double clicking is only a partial workaround for Safari. The Query List, in particular, still takes many seconds to render the table if you do this even if the rest of the page has already loaded. |
|
I can't check that because my install is fresh and I have no clients pointed to it. But worth to consider for sure! |
|
Could you please try the following Settings > All Settings > Web Interface > webserver.headers > Add Do a full Pi-hole restart with |
|
I don't have webserver.headers on that page. Do I need to enable this elsewhere? |
|
Sorry, the code is not yet released. You need to checkout the development branch with
|
|
Okay I did that. Unfortunately no difference in Safari.
|
|
A pitty. Thanks for trying. You can go back with
|
|
No problem! You are welcome. I can test everything you want if you have other ideas, this is just a VM explicitly setup for testing the new v6 with no production clients pointing to it. |
|
I just made another interesting observation. When I use Safari, click on a link in side bar it "stalls" for 30s - so far so (not) good. But while in this state the machine also does not answer any other connections ie. to Chrome. Chrome stalls as well until the page loads in Safari and then continues normally. As if the process serving the pages is "busy". Dunno if that helps. |
|
Transferring to FTL, as this is a webserver/API issue. |
|
Could you please enable 'debug.API' and post a log excerpt when it get stall from |
|
Just for fun and games... please try experimenting with the By default it is set to be equal to the number of CPU cores minus one. Which is out of an abundance of caution to ensure the entire system doesn't become unrespsonsive. Could you try increasing it in increments of 5? i.e try 5, if that doesn't make a difference try 10 etc etc etc... |
Here's mine. I clicked on the Groups menu item immediately after enabling |
|
I should note that logging only began several seconds after clicking the Groups link so whatever is slowing down these requests seems to be occurring before this log snippet began. |
Went up to 20, made no difference. |
and there was nothing above that? This seems to suggest your requests did not arrive at Pi-hole's web server at all. Not sure if this is a browser or webserver issue. Could you try again, this time with the Developer Tools of your browser opened (F12) and Network tab selected?
Then check on possibly reported slow requests in detail, e.g.
(in my case, the slowness is expected as I'm not at home right now and connected to my Pi-hole via LTE and a VPN) |
|
I'm trying the other suggestions in minute, but since @DL6ER posted log from the web inspector here is what this looks in Safari. I opened the homepage, then clicked Settings->System. The request is stalled for exactly 30s, then starts processing: 
|
Log entries start getting populated as soon as Safari registers that the page has loaded in the Developer Tools, which makes some sense since I enabled |
|
Here is my waterfall to the Groups page, it's similar to @seisfeld's. 
As you can see, almost 30 seconds for initial page load then everything is fast after that. My other Pi-hole instance on a dedicated Ubuntu box does not exhibit this behaviour at all but that one is sitting behind a Traefik reverse proxy so it's not completely the same. |
|
This is really strange, do you also see it without the traefik proxy, i.e., if directly accessing Pi-hole (over HTTPS or HTTP)? |
|
No change if I bypass Traefik and directly access Pi-hole on the other (non-problematic) server via http (as opposed to https through Traefik)—everything remains fast and responsive. On my problematic Pi-hole (which does not sit behind a reverse proxy), it makes no difference whether I use http or https, I get the 30-second delay all the time. |
|
I wonder what's the difference between Safari and Chrome here. I only get this 30 stall in Safari. In Chrome it's snappy. Also it's strange that in Safari double clicking a link makes it load immediately - without the 30 stall. |
|
The obvious difference I see between Brave (I don't have Chrome) and Safari is that Safari logs possibly CSRF-related errors in its console on page load: 
Interestingly, reloading the same page in Safari makes it load relatively instantly (probably similar to double-clicking the link as the workaround that's been suggested) and does not show these errors. |
|
This seems to be core / thread related as @PromoFaux suggested earlier. When I increase the cores in the VM from 2 to 4, the problem in Safari is gone. Another observation, when on 2 cores, while it's stalled, clicking on another link immediately loads that one. That said, v5 worked fine on VM with 1GB RAM and 2 CPUs. |
Maybe this suggests that - somehow - the first request in Safari doesn't make it to your Pi-hole and by "double clicking" you are actually making two requests in close succession and the second one immediately makes it.
It's probably worth looking at |
I went back to two CPUs but changed the @fongd did you restart the FTL service when you changed it? For me it only has an effect when do:
|
|
I enabled Here are the corresponding entries from Looking at I should note that I sometimes still see the |
Good catch! I did not manually restart pihole-FTL, I figured Pi-hole was already doing that for me by "applying" the changes. I'm happy to report that in my case, bumping the number of |
|
So conclusion is, when setting is 0, threads are (as per @PromoFaux cores -1) with 2 cores only 1 thread. Apparently the system does not like it. When increasing the cores (4 in my case) the default setting would default 2 threads. -> works. When changing manually to 2 it also works with only two cores. So seems it needs at least 2 threads? Pretty much an edge case we found here haha. Crazy. But why the heck this does not happen using Chrome... |
|
Curious why it only affects Safari, though. I wonder if it's because other browsers can keep going even if they consider the page to still be loading? |
|
This issue has been mentioned on Pi-hole Userspace. There might be relevant details there: https://discourse.pi-hole.net/t/error-on-v6-if-live-update-is-enabled/75879/21 |
|
This issue has been mentioned on Pi-hole Userspace. There might be relevant details there: |
|
Can confirm that changing the number of cpu cores from 2 to 4 seems to have resolved the slow ui issue with Safari on my setup. I did not try yet changing it back to 2 and adjusting the webserver.threads setting |
|
This issue has been mentioned on Pi-hole Userspace. There might be relevant details there: |
|
We are currently discussing increasing the number of threads. Thank your for your input. Safari is definitely doing something fishy here and we can see the 29 seconds delay here: From this data alone, it seems Safari is somehow opening (and keeping open!) a connection which it never uses with a timeout of 29 seconds. With only one thread, this is blocking the webserver. With more threads, the webserver will be able to serve the content just fine. This is really an issue when we have only one thread... |
|
Can confirm that raising from 1 to 4 cores, editing the webserver.threads value from 0 to 2 and restarting the vm with only 2 cores (running on proxmox) is solving the timeouts as mentioned from @seisfeld. |
For me, it also happens in Firefox. It is a little bit harder to trigger, but still possible. But I can confirm that raising threads from 0 to 64 (on a 2 core vCPU, Proxmox) solved the issue for me. Thank you @PromoFaux for that hint on reddit! |
|
|
Versions
Platform
Expected behavior
Navigating from page to page in the web UI should be fast.
Actual behavior / bug
The web UI is extremely slow to load pages. It takes between 25 to 30 seconds (!) between clicking any of the left menu items for the requested page to load. It's not just the Query Log page either—even just going to any of the settings pages results in the same lengthy delay. Filtering the Query Log and going page to page once it's loaded is actually fast, though.
When I enable debug logs, I see these messages being logged to FTL.log when I navigate from page to page:
I'm pretty sure this has something to do with the interface's lack of responsiveness, however, I don't know where to start looking especially since my other Pi-hole instance is using a very similar Pi-hole configuration as this one but does not exhibit this behaviour.
Steps to reproduce
Steps to reproduce the behavior:
Debug Token
Additional context
I am running another Pi-hole v6 instance on another server (that one is running Ubuntu with beefier hardware but still this N5105 should be more than adequate) that does not exhibit this behaviour.
Both of my Pi-hole instances were upgraded to v6 from v5.18.4. Only this one exhibits this problem, the other Pi-hole instance's web UI is snappy.
The text was updated successfully, but these errors were encountered: