Slow Dashboard Graph Loading Times

Help
1

I have PiHole v5.1 installed on a Ubuntu Server VM.
Since the update from v4 to v5 and the change from line graphs to column graphs loading the dashboard graphs takes a couple of minutes to load. Specifically the "Client activity over last 24hrs" graph appears to be the culprit.
Granted I do have 100s of devices, and the Pihole services over 500k queries a day.

DNS resolution time is good. No performance issues there, it's just the dashboard display.

Can I adjust the graph either back to the line graph, or adjust the 24hr time frame down, maybe options for 12, 6 and 3hrs? Or reduce the timescale from 10 mins to 20, 30 or 60 mins?

Debug Token:

https://tricorder.pi-hole.net/ta5yauau7q

2

I doubt chart presentation is related to slow dashboard refresh speeds, but you may switch back to Pi-hole's former mode by unchecking Use new Bar charts on dashboard on Settings | API / Web interface.

Your debug log shows no outright warnings.
It shows Pi-hole has full IPv4 connectivty, but I noticed a few less common settings:

*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the ens160 interface:
   192.168.23.242/22 matches the IP found in /etc/pihole/setupVars.conf

[i] Default IPv4 gateway: 192.168.20.100
[✓] Gateway responded.

Your gateway is not sitting at the start or end of your network range, and you are using a /22 netmask.

I trust this is intentional, but note that Pi-hole's embedded dnsmasq limits netmask usage to /8, /16,/24, and /32 in places. In particular, this will affect Conditional Fowarding (CF) (Pi-hole's developers have submitted an upstream patch to address this that still waits for acceptance by dnsmasq.).

And there are indeed indications for reverse lookups being forwarded from the loopback to some local address, yet this address is not configured as one of Pi-hole's upstream servers:

*** [ DIAGNOSING ]: Pi-hole log
-rw-r--r-- 1 pihole pihole 16996 Aug 17 05:17 /var/log/pihole.log
   -----head of pihole.log------
   Aug 17 01:00:00 dnsmasq[1242]: query[PTR] 22.23.168.192.in-addr.arpa from 127.0.0.1
   Aug 17 01:00:00 dnsmasq[1242]: forwarded 22.23.168.192.in-addr.arpa to 192.168.20.243

This may imply Pi-hole could be forwarded those reverse lookups back to itself, constituting a DNS loop.

As CF settings are absent from your debug log, these may have been configured manually.

Let's take a look at your current dnsmasq configuration.
On your Pi-hole machine, what's the output of the following command:

grep -nRv '^#\|^$' /etc/dnsmasq.*
3

@DL6ER Please resubmit your proposal. They might have just forgotten about it?

4

Please keep answers on topic:
dnsmasq developers will decide on features to incorporate at their own discretion, no need to push or alert Pi-hole's developers here.

(If you want to improve chances for arbitrary netmask support, submitting a well justified request with dnsmasq may be better suited to achieve that.)

5

Thanks @Bucking_Horn,

I've set the graph back to lines and the speed has improved thanks. I believe the slowness comes down the number of objects needing to be drawn. Reducing the displayed sampling time or window will reduce the objects and improve loading times. I think the bar graphs are more useful, the lines get so close it's just black, but at least it can load without timing out the browser.

Here is the output you requested. All my CFs are /16 or /24s.


$ grep -nRv '^#\|^$' /etc/dnsmasq.*
/etc/dnsmasq.conf:1:conf-dir=/etc/dnsmasq.d
/etc/dnsmasq.conf.old:1:conf-dir=/etc/dnsmasq.d
/etc/dnsmasq.d/01-pihole.conf:21:addn-hosts=/etc/pihole/local.list
/etc/dnsmasq.d/01-pihole.conf:22:addn-hosts=/etc/pihole/custom.list
/etc/dnsmasq.d/01-pihole.conf:25:localise-queries
/etc/dnsmasq.d/01-pihole.conf:28:no-resolv
/etc/dnsmasq.d/01-pihole.conf:32:cache-size=10000
/etc/dnsmasq.d/01-pihole.conf:34:log-queries
/etc/dnsmasq.d/01-pihole.conf:35:log-facility=/var/log/pihole.log
/etc/dnsmasq.d/01-pihole.conf:37:local-ttl=2
/etc/dnsmasq.d/01-pihole.conf:39:log-async
/etc/dnsmasq.d/01-pihole.conf:40:server=208.67.222.123
/etc/dnsmasq.d/01-pihole.conf:41:server=208.67.220.123
/etc/dnsmasq.d/01-pihole.conf:42:interface=ens160
/etc/dnsmasq.d/01-pihole.conf:43:server=/use-application-dns.net/
/etc/dnsmasq.d/lxd:4:bind-interfaces
/etc/dnsmasq.d/lxd:5:except-interface=lxdbr0
/etc/dnsmasq.d/02-*******.conf:10:server=/***.local/192.168.20.241
/etc/dnsmasq.d/02-*******.conf:11:server=/***.local/192.168.20.243
/etc/dnsmasq.d/02-*******.conf:12:server=/*******.com.au/192.168.20.241
/etc/dnsmasq.d/02-*******.conf:13:server=/*******.com.au/192.168.20.243
/etc/dnsmasq.d/02-*******.conf:14:server=/************.com/10.34.34.165
/etc/dnsmasq.d/02-*******.conf:15:server=/************..com/10.34.34.133
/etc/dnsmasq.d/02-*******.conf:16:server=/*********.com/192.168.20.241
/etc/dnsmasq.d/02-*******.conf:17:server=/*********.com/192.168.20.243
/etc/dnsmasq.d/02-*******.conf:18:server=/**********.com/203.52.0.221
/etc/dnsmasq.d/02-*******.conf:19:server=/**********.com/203.52.1.222
/etc/dnsmasq.d/02-*******.conf:25:server=/168.192.in-addr.arpa/192.168.20.241
/etc/dnsmasq.d/02-*******.conf:26:server=/168.192.in-addr.arpa/192.168.20.243
/etc/dnsmasq.d/02-*******.conf:27:server=/100.10.in-addr.arpa/192.168.20.241
/etc/dnsmasq.d/02-*******.conf:28:server=/100.10.in-addr.arpa/192.168.20.243
/etc/dnsmasq.d/02-*******.conf:29:server=/0.0.10.in-addr.arpa/192.168.20.241
/etc/dnsmasq.d/02-*******.conf:30:server=/0.0.10.in-addr.arpa/192.168.20.243
/etc/dnsmasq.d-available/lxd:4:bind-interfaces
/etc/dnsmasq.d-available/lxd:5:except-interface=lxdbr0
6

Do any of above servers have Pi-hole configured for upstream DNS resolution potentially resulting in previous mentioned DNS loop ?

7

Hi @deHakkelaar,

Yes, some of them do point back to the Pihole. I hadn't noticed any problems with DNS looping, is there a good way to determine how much looping is occurring? For my situation I'm not sure how to avoid the loops.

8

Any looping, even just a tiny bit, can run out of control using up all available resources like for example concurrent connections.
And you'll notice higher load as usual:

uptime

Live tail the logs at /var/log/pihole.log :

pihole -t

9

The number of data points to be calculated and displayed for the dashboard graph is the same, regardless of bar or line charts. I have never noticed a difference in drawing speed so far, but then I have about a dozen clients at most on my network.

If you say you are observing a notable difference, how many clients and requests do you deal with in a 24 hours dashboard period?

Looking at your dnsmasq configuration, these are the few things I noted:

potential DNS loops

As suspected, you've manually configured your own forwarding rules for reverse lookups.
deHakkelaar has already confirmed with you that at least some of your private address forward targets (i.e. 10.34.34.133, 10.34.34.165, 192.168.20.241, 192.168.20.243) would use your Pi-hole as upstream.
A DNS loop would be closed if one of those wouldn't know the answer to a query and then forward the query back to Pi-hole.

Consider the following lines from your config:

If .241 and .243 each knew a separate set of local hostname definitions, Pi-hole would be at a loss in picking the correct upstream for a given IP. Hence some lookups may be forwarded to the wrong upstream, which throws the query back at Pi-hole in lieu of an answer, and that repeats forever or until timeout. Resolution may eventually succeed if Pi-hole tries the respective other server.

You could try to mitigate this by being more specific for your in-addr.arpa delegation (e.g. /41.168.192.in-addr.arpa/ for .241 and /43.168.192.in-addr.arpa/ for .243). However, as mentioned earlier, note that this cannot be aligned to your /22 netmask subnet.

conflicting dnsmasq configuration

Are you running LXD and/or a separate dnsmasq instance intentionally?

We sometimes find an lxd file interfering with Pi-hole's dnsmasq configuration, and often the user would be unaware that file exists. This seems to happen predominantly on Ubuntu installations.

If you were not using LXD container management or some other related virtualisation tools like kvm on your Pi-hole machine, you should consider moving that file out of the way. If /etc/dnsmasq.d-available/lxd would hold a backup copy, it would be safe to delete /etc/dnsmasq.d/lxd.

potential mDNS conflicts

It would seem you are using .local as your local domain name.

That is also the default domain for the mDNS protocol as implemented e.g. by Apple's Bonjour or Linux' Avahi. Using .local in a network where such clients are present may lead to resolution conflicts and unexpected results.

typo?

The two above dots preceding com look dodgy.

I suspect it's just a glitch from sanitising the domain name, but better check. :wink:

1 Like
10

Looking at the logs, there were just 115 out of 550k in the last 24 hours. It looks like they aren't looping endlessly.

Both .241 and .243 are DCs and have identical DNS records. Both entries are listed for redundancies.

This server serves about 550k requests in 24 hours to about 450 devices.
A did a couple of timed runs and the line charts completed in 15-20 sec, while the bar charts take 75-80 sec on average.

I am running Ubuntu but am not using lxd so I've removed /etc/dnsmasqd/lxd

And yes that is just a typo in sanitising.

So back to my initial request, is there a way to modify the time frame for the graphs.
There was this post from 3 years ago.

There was an option to change the graph behavior.
TIMEFRAME=24h

I tried setting it to this, but it didn't alter the dehaviour.
TIMEFRAME=6h

11

Thank you for providing this information on timings.

As we've covered and for the most part excluded potential interferences from dnsmasq configuration, your observation supports that there is indeed a difference in drawing speed when using bar vs. line charts for large numbers (500k+) of queries.

Could I ask you to update your topic title to reflect this?
This may help other users with similar problems to decide on its relevance to them.

I've never used this myself, but I've found this in Pi-hole's documentation:

MAXLOGAGE=24.0

Up to how many hours of queries should be imported from the database and logs? Maximum is 24.0

As I've never used this, I am not sure whether this would affect initial data import only or graph's drawing range as well.

EDIT:
You'd have to restart Pi-hole for this setting to become effective

pihole restartdns

Afterwards, also reload the dashboard page in your browser.

17

Thanks,This is what I was looking for.

Editing /etc/pihole/pihole-FTL.conf reduced the page load times to 30 sec, and other values worked too.

MAXLOGAGE=12.0
30

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.