Do I need to upgrade my Pi model or do I have something causing performance issues?

Destrin · July 25, 2025, 5:28pm

I'm noticing occasionally blinks in my performance with internet after having my pi running for...I want to say a couple of months at this point. It's mostly okay but then a few times a day you try to click on a link and you get a DNS timeout, try again and it's fine. It feels like the pi is not keeping up (and I get relatively frequent 'long term load' notifications when I notice performance is poor and I go to check).

This is vanilla pi-hole install running on a rev 2 Model B - which feels like it might be old and maybe is the reason things aren't keeping up. Come here to provide my debug token in the hopes someone can check I haven't done something idiotic or easily fixable with the config and can recommend which model I should upgrade to to smooth this out a bit

Debug Token:

https://tricorder.pi-hole.net/5CqaeT6I/

Bucking_Horn · July 25, 2025, 6:14pm

While it won't win any speed contest, I don't think your 2B would be obsolete yet. I am running one of my Pi-holes on a Zero, and another one on a NanoPi with only 256M of RAM.
Pi-hole's web UI may feel slow on a single core machine like your 2B or my Zero, but DNS shouldn't be an issue.

Your debug log shows your Pi-hole to be operational, but it has connectivity issues:

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve flurry.com on lo (127.0.0.1)
[✗] Failed to resolve flurry.com on eth0 (192.168.1.1)
[✓] doubleclick.com is 172.217.169.14 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve flurry.com on lo (::1)
[✗] Failed to resolve flurry.com on eth0 (fdc6:<redacted>e3)
[✗] Failed to resolve flurry.com on eth0 (fe80::<redacted>4c%eth0)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)

And the only router activity detected by Pi-hole is related to an Espressif device, which emits IPv6 router advertisements as received on your 2B's eth0 link?

Pi-hole also didn't receive any DHCP server replies, which is remarkable since you have enabled Pi-hole's DHCP server.

Are you running your 2B in some kind of isolated environment?

Run from your 2B Pi-hole machine, please share the output of:

nslookup flurry.com

nslookup discourse.pi-hole.net 192.168.1.1

nslookup discourse.pi-hole.net 1.1.1.1

And run from a client in your network that you expect to use Pi-hole for DNS, what's the output of:

nslookup pi.hole

nslookup flurry.com

nslookup flurry.com 192.168.1.1

Destrin · July 25, 2025, 6:44pm

It shouldn't be isolated at all. I have a BT Homehub providing the fibre connection, of the 3 open LAN ports on the back of that, 2 are connected to small netgear hubs, the pi is on one of those 2, the other is at the end of a cable that runs upstairs. There are 2 wifi discs extending the wifi network off the homehub.

I've disabled ULA and ipv6 address allocation on the homehub. I found that if I had that enabled the homehub was just taking over and acting as the DNS server for any device that negotiated an ipv6 address (notably my main desktop PC where I tend to do all my testing would always resolve through the hub). The pi is the DHCP server for kinda the same reason, the homehub can't have it's DNS changed in DHCP addressing so I needed to have the pihole do it.

test results pi:

pdavies@raspberrypi:~ $ nslookup flurry.com
Server:         192.168.1.254
Address:        192.168.1.254#53

Non-authoritative answer:
Name:   flurry.com
Address: 76.223.84.192
Name:   flurry.com
Address: 13.248.158.7

pdavies@raspberrypi:~ $ nslookup discourse.pi-hole.net 192.168.1.1
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   discourse.pi-hole.net
Address: 157.180.42.82

pdavies@raspberrypi:~ $ nslookup discourse.pi-hole.net 1.1.1.1
Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   discourse.pi-hole.net
Address: 157.180.42.82

This looks normal I think?

test results my desktop:

C:\Users\destr>nslookup pi.hole
Server:  pi.hole
Address:  192.168.1.1

Name:    pi.hole.lan
Addresses:  fdc6:53dd:e037:81d3:f12c:d705:504d:72e3
          192.168.1.1


C:\Users\destr>nslookup flurry.com
Server:  pi.hole
Address:  192.168.1.1

Name:    flurry.com
Addresses:  ::
          0.0.0.0


C:\Users\destr>nslookup flurry.com 192.168.1.1
Server:  pi.hole
Address:  192.168.1.1

Name:    flurry.com
Addresses:  ::
          0.0.0.0

C:\Users\destr>nslookup discourse.pi-hole.net 192.168.1.1
Server:  pi.hole
Address:  192.168.1.1

Non-authoritative answer:
Name:    discourse.pi-hole.net
Address:  157.180.42.82

Added a non-blocked domain on the local test just for extra data. Confirmed via ipconfig /all that my local machine only has one DNS server in it's config (192.168.1.1)

Bucking_Horn · July 26, 2025, 8:39am

Yes, all of those nslookups did return expected results, precluding that any firewall rules on your 2B would block inbound or outbound port 53 traffic.

I'm at a loss explaining your debug log's connectivity issues, but your 2B not receiving or allowing inbound port 53 traffic at times would match your observation of temporary DNS outages.

Would another debug log still show those issues?

Destrin · July 26, 2025, 12:21pm

Here it is: https://tricorder.pi-hole.net/S0CvYn5z/

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve flurry.com on lo (127.0.0.1)
[✗] Failed to resolve flurry.com on eth0 (192.168.1.1)
[✓] doubleclick.com is 172.217.169.14 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✗] Failed to resolve flurry.com on lo (::1)
[✗] Failed to resolve flurry.com on eth0 (fdc6:53dd:e037:81d3:f12c:d705:504d:72e3)
[✗] Failed to resolve flurry.com on eth0 (fe80::5400:39ef:ee0c:f14c%eth0)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)

Same result on the lookups...is this just my connection being flaky? Given a direct nslookup on the device works what is the debug script doing different that means it doesn't return a result?

I haven't intentionally changed any firewall settings that I recall, this is just base Raspian then I ran the install script, then poked a few config settings:

Linux raspberrypi 6.12.25+rpt-rpi-v6 #1 Raspbian 1:6.12.25-1+rpt1 (2025-04-30) armv6l GNU/Linux

Bucking_Horn · July 26, 2025, 3:37pm

Not likely, as that usually wouldn't affect the loopback interface.

Pi-hole's debug script uses a dig command instead of nslookup, e.g.

dig +tries=1 +time=2 -4 flurry.com @127.0.0.1 A

Could you please also share the ouput of:

sudo pihole-FTL dhcp-discover

Destrin · July 26, 2025, 6:24pm

Scanning all your interfaces for DHCP servers and IPv6 routers
Timeout: 6 seconds

* Received 72 bytes from fe80:<redacted>9c @ eth0
  Hop limit: undefined
  Stateful address conf.: No
  Stateful other conf.: No
  Mobile home agent: No
  Router preference: Medium
  Neighbor discovery proxy: No
  Router lifetime: 0 s
  Reachable time: N/A
  Retransmit time: N/A
 Unknown option 26:  1a 01 80 00 00 00 00 00
  - Prefix: fdc6:53dd:e037:81d3::/64
    Valid lifetime: 1800 sec
    Preferred lifetime: 1800 sec
    On-link: Yes
    Autonomous address conf.: Yes
  - Route: fdd7:143a:abd6:1::/64
    Route preference: Medium
    Route lifetime: 1800 sec

* Received 303 bytes from 192.168.1.1 @ eth0
  Offered IP address: 192.168.1.73
  Server IP address: 192.168.1.1
  Relay-agent IP address: N/A
  BOOTP server: (empty)
  BOOTP file: (empty)
  DHCP options:
   Message type: DHCPOFFER (2)
   server-identifier: 192.168.1.1
   lease-time: 86400 ( 1d )
   renewal-time: 43200 ( 12h )
   rebinding-time: 75600 ( 21h )
   netmask: 255.255.255.0
   broadcast: 192.168.1.255
   dns-server: 192.168.1.1
   domain-name: "lan"
   ntp-server: 192.168.1.1
   router: 192.168.1.254
   --- end of options ---

Received 1 DHCP (IPv4) and 1 RA (IPv6) answers on eth0

Destrin · July 26, 2025, 6:38pm

Randomly firing commands whilst reading historical forum posts to try to understand what's happening:

 dig +tries=1 +time=2 -4 flurry.com @127.0.0.1 A
;; communications error to 127.0.0.1#53: timed out

; <<>> DiG 9.18.33-1~deb12u2-Raspbian <<>> +tries=1 +time=2 -4 flurry.com @127.0.0.1 A
;; global options: +cmd
;; no servers could be reached

Maybe 5-10 minutes later:

dig +tries=1 +time=2 -4 flurry.com @127.0.0.1 A

; <<>> DiG 9.18.33-1~deb12u2-Raspbian <<>> +tries=1 +time=2 -4 flurry.com @127.0.0.1 A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9013
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 15 (Blocked): (gravity)
;; QUESTION SECTION:
;flurry.com.                    IN      A

;; ANSWER SECTION:
flurry.com.             2       IN      A       0.0.0.0

;; Query time: 9 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Jul 26 19:35:13 BST 2025
;; MSG SIZE  rcvd: 68

I'll admit to not having a full understanding of the nitty gritty but I don't understand how it would fail to respond on loopback 1 time than succeed 5 mins later

Bucking_Horn · July 26, 2025, 7:05pm

It may have been Pi-hole's upstreams that have timed out.
How did that first failing lookup register in Pi-hole's Query Log?

If that fails again, a direct lookup through your upstreams may help verify whether they are accessible, e.g.

dig +tries=1 +time=2 -4 flurry.com @1.1.1.1 A

(The command uses 1.1.1.1 to resolve an A record for flurry.com via IPv4 (-4), setting the timeout to 2 seconds without any retries.)

Destrin · July 26, 2025, 7:44pm

Checking the query log appears to be destroying performance:
Load: 3.62 / 5.51 / 9.75
Memory usage: 70.5 %

and it keeps timing out my remote connection (I should probably setup SSH instead of using RPI connect but it's so much easier when it works :p)

It looks like it's blocking them but that's not enough queries for the 5-6 times I regularly issued the query from the cmd line so I'm a bit confused, and in all those cases the cmd line was coming back with ' communications error to 127.0.0.1#53: timed out'

trying direct to Cloudflarr works every single time, from the pihole cmd line:

[20:37:45] pdavies@raspberrypi:~ $ dig +tries=1 +time=2 -4 flurry.com @1.1.1.1

; <<>> DiG 9.18.33-1~deb12u2-Raspbian <<>> +tries=1 +time=2 -4 flurry.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35593
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;flurry.com.                    IN      A

;; ANSWER SECTION:
flurry.com.             300     IN      A       13.248.158.7
flurry.com.             300     IN      A       76.223.84.192

;; Query time: 9 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Sat Jul 26 20:43:52 BST 2025
;; MSG SIZE  rcvd: 71

Destrin · July 26, 2025, 7:50pm

tried with a higher timeout

pdavies@raspberrypi:~ $ dig +tries=1 +time=10 -4 flurry.com @127.0.0.1 A

; <<>> DiG 9.18.33-1~deb12u2-Raspbian <<>> +tries=1 +time=10 -4 flurry.com @127.0.0.1 A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38821
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 15 (Blocked): (gravity)
;; QUESTION SECTION:
;flurry.com.                    IN      A

;; ANSWER SECTION:
flurry.com.             2       IN      A       0.0.0.0

;; Query time: 6859 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Jul 26 20:48:19 BST 2025
;; MSG SIZE  rcvd: 68

6.8s to get a response

Which shows in the query log as blocked

but with a much faster query time at the resolver end

Bucking_Horn · July 26, 2025, 8:10pm

Ah, sorry, my fault - of course flurry.com is blocked, so upstreams cannot be involved here.

This is unexpected.
There is no obvious reason why a lookup of a blocked domain should take almost 7 seconds - it should return instantly (as the 0.2ms from the Query Log).

Interestingly, the timeout for Pi-hole's dhcp-discover is 6 seconds.
This means that a delay of more than 6 seconds on IPv4 traffic could also explain why we don't see a DHCP server response in the debug log, despite Pi-hole being that DHCP server.

Run from your 2B, could you please share the result of:

readelf -A "$(command -v sh)" | grep Tag_CPU_arch | awk '{ print $2 }'

readelf -A "$(command -v pihole-FTL)" | grep Tag_CPU_arch | awk '{ print $2 }'

sudo lscpu | grep 'Arch\|Model'

Destrin · July 26, 2025, 8:23pm

Bucking_Horn:

readelf -A "$(command -v sh)" | grep Tag_CPU_arch | awk '{ print $2 }'
v6
readelf -A "$(command -v pihole-FTL)" | grep Tag_CPU_arch | awk '{ print $2 }'
v6KZ
sudo lscpu | grep 'Arch\|Model'
Architecture: armv6l
Model name: ARM1176
Model: 7

Inline

Bucking_Horn · July 26, 2025, 8:43pm

So what we seem to observe here are occasional delays of more than 6 seconds before pihole-FTL register's traffic.
This seems to happen for DNS as well as DHCP traffic.

@DL6ER, what could cause those delays?

IvanDobsky · July 28, 2025, 2:48pm

A reply from a tangent - do you have a dedicated power supply? Or are you running the PI from USB power?

I used to run my PI 3B via the USB port of a router. At times I got patchy dropouts and performance issues. Swapped to a quality dedicated power supply and problems went away.

Attempted to find my old post about it in this forum. Instead founds loads of others who had same issues.

Destrin · July 29, 2025, 5:40pm

I do have a dedicated power supply but it's not a bad shout to at least check it - it's an old adapter so maybe that's causing problems? I thrw this script at it: Checking your Raspberry Pi's view of its power supply (sometimes it's not the wall-wart) · GitHub

and it's hot but it's not reporting that it's being throttled and honestly I'm not good with knowing what core voltage should be but I don't think this is showing it as bad:

vcgencmd get_throttled (0x0)
vcgencmd measure_volts:
core volt=1.2000V
sdram_c volt=1.2000V
sdram_i volt=1.2000V
sdram_p volt=1.2250V
Temperature: temp=54.1'C

DL6ER · July 29, 2025, 6:25pm

I am not sure, the new multi-layer database design in v6 should prevent any slow disk I/O from affecting the DNS operation when queries are written into the database. This was an issue especially with v5 on very slow hardware.

What could give us some guidance here is running

sudo pihole-FTL --config debug.all true

and then, once you observe it, trying to locate the problematic time interval in /var/log/pihole/FTL.log as well as /var/log/pihole/pihole.log providing a few lines before and after.

Ideally, you @-mention me on your reply once you have it, there is currently so much going on and this just makes it somewhat more likely I will notice your reply in a timely manner.

Destrin · July 30, 2025, 12:03pm

@DL6ER (though this is hardly a critical problem if you are busy - just some rando with a weirdly behaving home connection so no rush)

Caught it during a moment where it was failing to resolve google.com for my main client PC (also the only other machine currently pointing to the pihole, I reverted the rest of the network to using the router DHCP for the moment and hardcoded my own machine.

Immediately went and tailed the FTL.log and got this pile of gubbins which may or may not be useful? Not really sure what to spot in the debug that might be off

2025-07-30 12:47:19.228 BST [18876M] DEBUG_DATABASE: domain_in_list("@@||catalog.gamepass.com.edgesuite.net^", 0xb47b8348, antigravity): -1
2025-07-30 12:47:19.230 BST [18876M] DEBUG_VECTORS: Getting sqlite3_stmt** 0xb6f4a4b0[17] --> 0xb47b8108
2025-07-30 12:47:19.231 BST [18876M] DEBUG_DATABASE: domain_in_list("catalog.gamepass.com.edgesuite.net", 0xb47b8108, gravity): -1
2025-07-30 12:47:19.233 BST [18876M] DEBUG_QUERIES: Checking if "catalog.gamepass.com.edgesuite.net" is in gravity (exact): no
2025-07-30 12:47:19.245 BST [18876M] DEBUG_QUERIES: Checking if "||net^" is in gravity (ABP): no
2025-07-30 12:47:19.247 BST [18876M] DEBUG_DATABASE: domain_in_list("||net^", 0xb47b8108, gravity): -1
2025-07-30 12:47:19.248 BST [18876M] DEBUG_QUERIES: Checking if "||edgesuite.net^" is in gravity (ABP): no
2025-07-30 12:47:19.250 BST [18876M] DEBUG_DATABASE: domain_in_list("||edgesuite.net^", 0xb47b8108, gravity): -1
2025-07-30 12:47:19.251 BST [18876M] DEBUG_QUERIES: Checking if "||com.edgesuite.net^" is in gravity (ABP): no
2025-07-30 12:47:19.253 BST [18876M] DEBUG_DATABASE: domain_in_list("||com.edgesuite.net^", 0xb47b8108, gravity): -1
2025-07-30 12:47:19.265 BST [18876M] DEBUG_QUERIES: Checking if "||gamepass.com.edgesuite.net^" is in gravity (ABP): no
2025-07-30 12:47:19.267 BST [18876M] DEBUG_DATABASE: domain_in_list("||gamepass.com.edgesuite.net^", 0xb47b8108, gravity): -1
2025-07-30 12:47:19.268 BST [18876M] DEBUG_QUERIES: Checking if "||catalog.gamepass.com.edgesuite.net^" is in gravity (ABP): no
2025-07-30 12:47:19.270 BST [18876M] DEBUG_DATABASE: domain_in_list("||catalog.gamepass.com.edgesuite.net^", 0xb47b8108, gravity): -1
2025-07-30 12:47:19.271 BST [18876M] DEBUG_QUERIES: DNS cache: AAAA/192.168.1.169/catalog.gamepass.com.edgesuite.net is not blocked (domainlist ID: -1)
2025-07-30 12:47:19.278 BST [18876/T25662] DEBUG_LOCKS: Waiting for SHM lock in GC_thread() (/app/src/gc.c:668)
2025-07-30 12:47:19.273 BST [18876M] DEBUG_QUERIES: Query 77224: CNAME catalog.gamepass.com ---> catalog.gamepass.com.edgesuite.net
2025-07-30 12:47:19.282 BST [18876/T25662] DEBUG_LOCKS: SHM lock: 0xb6fbc000
2025-07-30 12:47:19.291 BST [18876M] DEBUG_LOCKS: Removed SHM lock in FTL_CNAME() (/app/src/dnsmasq_interface.c:1914)
2025-07-30 12:47:19.294 BST [18876/T25662] DEBUG_LOCKS: Obtained SHM lock for GC_thread() (/app/src/gc.c:668)
2025-07-30 12:47:19.296 BST [18876/T25662] DEBUG_LOCKS: Removed SHM lock in GC_thread() (/app/src/gc.c:670)
2025-07-30 12:47:19.303 BST [18876M] DEBUG_FLAGS: Processing FTL hook from src/dnsmasq/rfc1035.c:867 (type: ?, name: "catalog.gamepass.com.edgesuite.net", id: 77224)...
2025-07-30 12:47:19.307 BST [18876M] DEBUG_FLAGS:      Flags: F_FORWARD F_CNAME F_UPSTREAM 
2025-07-30 12:47:19.308 BST [18876M] DEBUG_LOCKS: Waiting for SHM lock in FTL_reply() (/app/src/dnsmasq_interface.c:2183)
2025-07-30 12:47:19.309 BST [18876M] DEBUG_LOCKS: SHM lock: 0xb6fbc000
2025-07-30 12:47:19.311 BST [18876M] DEBUG_LOCKS: Obtained SHM lock for FTL_reply() (/app/src/dnsmasq_interface.c:2183)
2025-07-30 12:47:19.312 BST [18876M] DEBUG_QUERIES: **** got upstream reply: catalog.gamepass.com.edgesuite.net is (CNAME) (ID 77224, src/dnsmasq/rfc1035.c:867)
2025-07-30 12:47:19.314 BST [18876M] DEBUG_LOCKS: Removed SHM lock in FTL_reply() (/app/src/dnsmasq_interface.c:2342)
2025-07-30 12:47:19.328 BST [18876M] DEBUG_LOCKS: Waiting for SHM lock in FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3816)
2025-07-30 12:47:19.333 BST [18876M] DEBUG_LOCKS: SHM lock: 0xb6fbc000
2025-07-30 12:47:19.338 BST [18876M] DEBUG_LOCKS: Obtained SHM lock for FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3816)
2025-07-30 12:47:19.343 BST [18876M] DEBUG_LOCKS: Removed SHM lock in FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3822)
2025-07-30 12:47:19.350 BST [18876M] DEBUG_QUERIES: FTL_CNAME called with: src = catalog.gamepass.com.edgesuite.net, dst = a1992.dscd.akamai.net, id = 77224
2025-07-30 12:47:19.352 BST [18876M] DEBUG_LOCKS: Waiting for SHM lock in FTL_CNAME() (/app/src/dnsmasq_interface.c:1793)
2025-07-30 12:47:19.353 BST [18876M] DEBUG_LOCKS: SHM lock: 0xb6fbc000
2025-07-30 12:47:19.356 BST [18876M] DEBUG_LOCKS: Obtained SHM lock for FTL_CNAME() (/app/src/dnsmasq_interface.c:1793)
2025-07-30 12:47:19.362 BST [18876M] DEBUG_QUERIES: Set global cache status to 0
2025-07-30 12:47:19.364 BST [18876M] DEBUG_QUERIES: a1992.dscd.akamai.net is not known
2025-07-30 12:47:19.366 BST [18876M] DEBUG_VECTORS: Getting sqlite3_stmt** 0xb6f4a470[17] --> 0xb47b7fe8
2025-07-30 12:47:19.368 BST [18876M] DEBUG_DATABASE: domain_in_list("a1992.dscd.akamai.net", 0xb47b7fe8, whitelist): -1
2025-07-30 12:47:19.370 BST [18876M] DEBUG_VECTORS: Getting sqlite3_stmt** 0xb6f4a490[17] --> 0xb47b8588
2025-07-30 12:47:19.371 BST [18876M] DEBUG_DATABASE: domain_in_list("a1992.dscd.akamai.net", 0xb47b8588, blacklist): -1
2025-07-30 12:47:19.373 BST [18876M] DEBUG_VECTORS: Getting sqlite3_stmt** 0xb6f4a4d0[17] --> 0xb47b8348
2025-07-30 12:47:19.385 BST [18876M] DEBUG_DATABASE: domain_in_list("a1992.dscd.akamai.net", 0xb47b8348, antigravity): -1
2025-07-30 12:47:19.386 BST [18876M] DEBUG_QUERIES: Checking if "a1992.dscd.akamai.net" is in antigravity (exact): no
2025-07-30 12:47:19.388 BST [18876M] DEBUG_QUERIES: Checking if "@@||net^" is in antigravity (ABP): no
2025-07-30 12:47:19.389 BST [18876M] DEBUG_DATABASE: domain_in_list("@@||net^", 0xb47b8348, antigravity): -1
2025-07-30 12:47:19.391 BST [18876M] DEBUG_QUERIES: Checking if "@@||akamai.net^" is in antigravity (ABP): no
2025-07-30 12:47:19.393 BST [18876M] DEBUG_DATABASE: domain_in_list("@@||akamai.net^", 0xb47b8348, antigravity): -1
2025-07-30 12:47:19.406 BST [18876M] DEBUG_QUERIES: Checking if "@@||dscd.akamai.net^" is in antigravity (ABP): no
2025-07-30 12:47:19.410 BST [18876M] DEBUG_DATABASE: domain_in_list("@@||dscd.akamai.net^", 0xb47b8348, antigravity): -1
2025-07-30 12:47:19.412 BST [18876M] DEBUG_QUERIES: Checking if "@@||a1992.dscd.akamai.net^" is in antigravity (ABP): no
2025-07-30 12:47:19.414 BST [18876M] DEBUG_DATABASE: domain_in_list("@@||a1992.dscd.akamai.net^", 0xb47b8348, antigravity): -1
2025-07-30 12:47:19.424 BST [18876M] DEBUG_VECTORS: Getting sqlite3_stmt** 0xb6f4a4b0[17] --> 0xb47b8108
2025-07-30 12:47:19.426 BST [18876M] DEBUG_DATABASE: domain_in_list("a1992.dscd.akamai.net", 0xb47b8108, gravity): -1
2025-07-30 12:47:19.427 BST [18876M] DEBUG_QUERIES: Checking if "a1992.dscd.akamai.net" is in gravity (exact): no
2025-07-30 12:47:19.429 BST [18876M] DEBUG_QUERIES: Checking if "||net^" is in gravity (ABP): no
2025-07-30 12:47:19.430 BST [18876M] DEBUG_DATABASE: domain_in_list("||net^", 0xb47b8108, gravity): -1
2025-07-30 12:47:19.432 BST [18876M] DEBUG_QUERIES: Checking if "||akamai.net^" is in gravity (ABP): no
2025-07-30 12:47:19.434 BST [18876M] DEBUG_DATABASE: domain_in_list("||akamai.net^", 0xb47b8108, gravity): -1
2025-07-30 12:47:19.449 BST [18876M] DEBUG_QUERIES: Checking if "||dscd.akamai.net^" is in gravity (ABP): no
2025-07-30 12:47:19.452 BST [18876M] DEBUG_DATABASE: domain_in_list("||dscd.akamai.net^", 0xb47b8108, gravity): -1
2025-07-30 12:47:19.456 BST [18876M] DEBUG_QUERIES: Checking if "||a1992.dscd.akamai.net^" is in gravity (ABP): no
2025-07-30 12:47:19.460 BST [18876M] DEBUG_DATABASE: domain_in_list("||a1992.dscd.akamai.net^", 0xb47b8108, gravity): -1
2025-07-30 12:47:19.464 BST [18876M] DEBUG_QUERIES: DNS cache: AAAA/192.168.1.169/a1992.dscd.akamai.net is not blocked (domainlist ID: -1)
2025-07-30 12:47:19.468 BST [18876M] DEBUG_QUERIES: Query 77224: CNAME catalog.gamepass.com.edgesuite.net ---> a1992.dscd.akamai.net
2025-07-30 12:47:19.470 BST [18876M] DEBUG_LOCKS: Removed SHM lock in FTL_CNAME() (/app/src/dnsmasq_interface.c:1914)
2025-07-30 12:47:19.471 BST [18876M] DEBUG_FLAGS: Processing FTL hook from src/dnsmasq/rfc1035.c:1092 (type: ?, name: "a1992.dscd.akamai.net", id: 77224)...
2025-07-30 12:47:19.473 BST [18876M] DEBUG_FLAGS:      Flags: F_FORWARD F_IPV6 F_UPSTREAM 
2025-07-30 12:47:19.481 BST [18876M] DEBUG_LOCKS: Waiting for SHM lock in FTL_reply() (/app/src/dnsmasq_interface.c:2183)
2025-07-30 12:47:19.482 BST [18876M] DEBUG_LOCKS: SHM lock: 0xb6fbc000
2025-07-30 12:47:19.484 BST [18876M] DEBUG_LOCKS: Obtained SHM lock for FTL_reply() (/app/src/dnsmasq_interface.c:2183)
2025-07-30 12:47:19.492 BST [18876M] DEBUG_QUERIES: **** got upstream reply: a1992.dscd.akamai.net is 2a02:26f0:fd00:3::213:75aa (ID 77224, src/dnsmasq/rfc1035.c:1092)
2025-07-30 12:47:19.496 BST [18876M] DEBUG_LOCKS: Removed SHM lock in FTL_reply() (/app/src/dnsmasq_interface.c:2342)
2025-07-30 12:47:19.497 BST [18876M] DEBUG_LOCKS: Waiting for SHM lock in FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3816)
2025-07-30 12:47:19.499 BST [18876M] DEBUG_LOCKS: SHM lock: 0xb6fbc000
2025-07-30 12:47:19.500 BST [18876M] DEBUG_LOCKS: Obtained SHM lock for FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3816)
2025-07-30 12:47:19.502 BST [18876M] DEBUG_LOCKS: Removed SHM lock in FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3822)
2025-07-30 12:47:19.514 BST [18876M] DEBUG_FLAGS: Processing FTL hook from src/dnsmasq/rfc1035.c:1092 (type: ?, name: "a1992.dscd.akamai.net", id: 77224)...
2025-07-30 12:47:19.516 BST [18876M] DEBUG_FLAGS:      Flags: F_FORWARD F_IPV6 F_UPSTREAM 
2025-07-30 12:47:19.517 BST [18876M] DEBUG_LOCKS: Waiting for SHM lock in FTL_reply() (/app/src/dnsmasq_interface.c:2183)
2025-07-30 12:47:19.519 BST [18876M] DEBUG_LOCKS: SHM lock: 0xb6fbc000
2025-07-30 12:47:19.520 BST [18876M] DEBUG_LOCKS: Obtained SHM lock for FTL_reply() (/app/src/dnsmasq_interface.c:2183)
2025-07-30 12:47:19.521 BST [18876M] DEBUG_QUERIES: **** got upstream reply: a1992.dscd.akamai.net is 2a02:26f0:fd00:3::213:7586 (ID 77224, src/dnsmasq/rfc1035.c:1092)
2025-07-30 12:47:19.523 BST [18876M] DEBUG_LOCKS: Removed SHM lock in FTL_reply() (/app/src/dnsmasq_interface.c:2342)
2025-07-30 12:47:19.535 BST [18876M] DEBUG_LOCKS: Waiting for SHM lock in FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3816)
2025-07-30 12:47:19.536 BST [18876M] DEBUG_LOCKS: SHM lock: 0xb6fbc000
2025-07-30 12:47:19.537 BST [18876M] DEBUG_LOCKS: Obtained SHM lock for FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3816)
2025-07-30 12:47:19.540 BST [18876M] DEBUG_LOCKS: Removed SHM lock in FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3822)
2025-07-30 12:47:19.542 BST [18876M] DEBUG_NETWORKING: Interfaces: Called from src/dnsmasq/forward.c:1865
2025-07-30 12:47:19.554 BST [18876M] DEBUG_NETWORKING: Identifying interface (looking for 192.168.1.1):
2025-07-30 12:47:19.555 BST [18876M] DEBUG_NETWORKING:   - IPv4 interface eth0 (2,0) is 192.168.1.1
2025-07-30 12:47:19.557 BST [18876M] DEBUG_NETWORKING:     ^^^^^ MATCH ^^^^^
2025-07-30 12:47:19.558 BST [18876M] DEBUG_NETWORKING: Analyzing interfaces:
2025-07-30 12:47:19.560 BST [18876M] DEBUG_NETWORKING:   -  OK  IPv4 interface eth0 (2,0) is 192.168.1.1
2025-07-30 12:47:19.561 BST [18876M] DEBUG_NETWORKING:   - SKIP IPv4 interface lo: (1,0) != (2,0)
2025-07-30 12:47:19.571 BST [18876M] DEBUG_NETWORKING:   -  OK  IPv6 interface eth0 (2,0) is fe80::5400:39ef:ee0c:f14c (LL)
2025-07-30 12:47:19.574 BST [18876M] DEBUG_NETWORKING:   -  OK  IPv6 interface eth0 (2,0) is fdc6:53dd:e037:81d3:f12c:d705:504d:72e3 (ULA)
2025-07-30 12:47:19.576 BST [18876M] DEBUG_NETWORKING: Exiting interface analysis early (have IPv4 + ULAv6)
2025-07-30 12:47:19.577 BST [18876M] DEBUG_EDNS0: No EDNS(0) pheader found
2025-07-30 12:47:19.579 BST [18876M] DEBUG_FLAGS: Processing FTL hook from src/dnsmasq/forward.c:1897 (type: ?, name: "wpad.home", id: 77225)...
2025-07-30 12:47:19.580 BST [18876M] DEBUG_FLAGS:      Flags: F_FORWARD F_IPV4 F_QUERY 
2025-07-30 12:47:19.581 BST [18876M] DEBUG_LOCKS: Waiting for SHM lock in FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3816)
2025-07-30 12:47:19.583 BST [18876M] DEBUG_LOCKS: SHM lock: 0xb6fbc000
2025-07-30 12:47:19.595 BST [18876M] DEBUG_LOCKS: Obtained SHM lock for FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3816)
2025-07-30 12:47:19.599 BST [18876M] DEBUG_LOCKS: Removed SHM lock in FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3822)
2025-07-30 12:47:19.606 BST [18876M] DEBUG_LOCKS: Waiting for SHM lock in _FTL_new_query() (/app/src/dnsmasq_interface.c:750)
2025-07-30 12:47:19.608 BST [18876M] DEBUG_LOCKS: SHM lock: 0xb6fbc000
2025-07-30 12:47:19.609 BST [18876M] DEBUG_LOCKS: Obtained SHM lock for _FTL_new_query() (/app/src/dnsmasq_interface.c:750)
2025-07-30 12:47:19.611 BST [18876M] DEBUG_QUERIES: **** new UDP IPv4 query[AAAA] query "wpad.home" from eth0/192.168.1.169#58502 (ID 77225, FTL 17334, src/dnsmasq/forward.c:1899)
2025-07-30 12:47:19.612 BST [18876M] DEBUG_OVERTIME: getOverTimeID(1753875900): 144
2025-07-30 12:47:19.613 BST [18876M] DEBUG_STATUS: query type 2 set (new query), ID = 77225, new count = 3176
2025-07-30 12:47:19.623 BST [18876M] DEBUG_STATUS: Query 77225: status initialized: UNKNOWN (0) in _FTL_new_query() (src/dnsmasq_interface.c:872)
2025-07-30 12:47:19.627 BST [18876M] DEBUG_STATUS: status 0 set, ID = 77225, new count = 1
2025-07-30 12:47:19.628 BST [18876M] DEBUG_OVERTIME: getOverTimeID(1753875900): 144
2025-07-30 12:47:19.630 BST [18876M] DEBUG_STATUS: reply type 0 set (new query), ID = 77225, new count = 34
2025-07-30 12:47:19.631 BST [18876M] DEBUG_OVERTIME: overTime[144].total += 1 = 571
2025-07-30 12:47:19.632 BST [18876M] DEBUG_QUERIES: Set global cache status to 3
2025-07-30 12:47:19.634 BST [18876M] DEBUG_QUERIES: wpad.home is known as not to be blocked
2025-07-30 12:47:19.645 BST [18876M] DEBUG_LOCKS: Removed SHM lock in _FTL_new_query() (/app/src/dnsmasq_interface.c:999)
2025-07-30 12:47:19.647 BST [18876M] DEBUG_FLAGS: Processing FTL hook from src/dnsmasq/rfc1035.c:2296 (type: ?, name: "wpad.home", id: 77225)...
2025-07-30 12:47:19.649 BST [18876M] DEBUG_FLAGS:      Flags: F_FORWARD F_NEG F_NXDOMAIN 
2025-07-30 12:47:19.650 BST [18876M] DEBUG_LOCKS: Waiting for SHM lock in FTL_reply() (/app/src/dnsmasq_interface.c:2183)
2025-07-30 12:47:19.651 BST [18876M] DEBUG_LOCKS: SHM lock: 0xb6fbc000
2025-07-30 12:47:19.653 BST [18876M] DEBUG_LOCKS: Obtained SHM lock for FTL_reply() (/app/src/dnsmasq_interface.c:2183)
2025-07-30 12:47:19.664 BST [18876M] DEBUG_QUERIES: **** got cache reply: wpad.home is (NXDOMAIN) (ID 77225, src/dnsmasq/rfc1035.c:2296)
2025-07-30 12:47:19.667 BST [18876M] DEBUG_STATUS: Query 77225: status changed: UNKNOWN (0) -> CACHE (3) in FTL_reply() (src/dnsmasq_interface.c:2367)
2025-07-30 12:47:19.671 BST [18876M] DEBUG_STATUS: status 0 removed (!init), ID = 77225, new count = 0
2025-07-30 12:47:19.674 BST [18876M] DEBUG_STATUS: status 3 set, ID = 77225, new count = 7259
2025-07-30 12:47:19.676 BST [18876M] DEBUG_OVERTIME: getOverTimeID(1753875900): 144
2025-07-30 12:47:19.677 BST [18876M] DEBUG_OVERTIME: overTime[144].cached++ = 470 (new_status = CACHE), ID = 77225
2025-07-30 12:47:19.679 BST [18876M] DEBUG_QUERIES: Set reply to NXDOMAIN (2) in src/dnsmasq_interface.c:2370
2025-07-30 12:47:19.680 BST [18876M] DEBUG_STATUS: reply type 0 removed (set_reply), ID = 77225, new count = 33
2025-07-30 12:47:19.681 BST [18876M] DEBUG_STATUS: reply type 2 added (set_reply), ID = 77225, new count = 1257
2025-07-30 12:47:19.683 BST [18876M] DEBUG_LOCKS: Removed SHM lock in FTL_reply() (/app/src/dnsmasq_interface.c:2385)
2025-07-30 12:47:19.695 BST [18876M] DEBUG_LOCKS: Waiting for SHM lock in FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3816)
2025-07-30 12:47:19.696 BST [18876M] DEBUG_LOCKS: SHM lock: 0xb6fbc000
2025-07-30 12:47:19.698 BST [18876M] DEBUG_LOCKS: Obtained SHM lock for FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3816)
2025-07-30 12:47:19.700 BST [18876M] DEBUG_LOCKS: Removed SHM lock in FTL_dnsmasq_log() (/app/src/dnsmasq_interface.c:3822)

pihole.log from about the same time


Jul 30 12:47:19 dnsmasq[18876]: forwarded catalog.gamepass.com to 1.1.1.1
Jul 30 12:47:19 dnsmasq[18876]: reply catalog.gamepass.com is <CNAME>
Jul 30 12:47:19 dnsmasq[18876]: reply catalog.gamepass.com.edgesuite.net is <CNAME>
Jul 30 12:47:19 dnsmasq[18876]: reply a1992.dscd.akamai.net is 2a02:26f0:fd00:3::213:75aa
Jul 30 12:47:19 dnsmasq[18876]: reply a1992.dscd.akamai.net is 2a02:26f0:fd00:3::213:7586
Jul 30 12:47:19 dnsmasq[18876]: query[AAAA] wpad.home from 192.168.1.169
Jul 30 12:47:19 dnsmasq[18876]: cached wpad.home is NXDOMAIN
Jul 30 12:47:19 dnsmasq[18876]: query[A] wpad.home from 192.168.1.169
Jul 30 12:47:19 dnsmasq[18876]: cached wpad.home is NXDOMAIN
Jul 30 12:47:19 dnsmasq[18876]: query[A] waa-pa.clients6.google.com from 192.168.1.169
Jul 30 12:47:20 dnsmasq[18876]: cached-stale waa-pa.clients6.google.com is 142.250.117.95
Jul 30 12:47:20 dnsmasq[18876]: forwarded waa-pa.clients6.google.com to 1.1.1.1
Jul 30 12:47:20 dnsmasq[18876]: reply waa-pa.clients6.google.com is 142.251.30.95
Jul 30 12:47:20 dnsmasq[18876]: query[HTTPS] waa-pa.clients6.google.com from 192.168.1.169
Jul 30 12:47:20 dnsmasq[18876]: cached-stale waa-pa.clients6.google.com is NODATA
Jul 30 12:47:20 dnsmasq[18876]: forwarded waa-pa.clients6.google.com to 1.1.1.1
Jul 30 12:47:20 dnsmasq[18876]: reply waa-pa.clients6.google.com is NODATA
Jul 30 12:47:20 dnsmasq[18876]: query[A] www.google.com from 192.168.1.169
Jul 30 12:47:20 dnsmasq[18876]: cached-stale www.google.com is 216.58.212.196
Jul 30 12:47:20 dnsmasq[18876]: forwarded www.google.com to 1.1.1.1
Jul 30 12:47:20 dnsmasq[18876]: reply www.google.com is 142.250.140.147
Jul 30 12:47:20 dnsmasq[18876]: reply www.google.com is 142.250.140.99
Jul 30 12:47:20 dnsmasq[18876]: reply www.google.com is 142.250.140.105
Jul 30 12:47:20 dnsmasq[18876]: reply www.google.com is 142.250.140.106
Jul 30 12:47:20 dnsmasq[18876]: reply www.google.com is 142.250.140.104
Jul 30 12:47:20 dnsmasq[18876]: reply www.google.com is 142.250.140.103
Jul 30 12:47:21 dnsmasq[18876]: query[A] wpad.home from 192.168.1.169
Jul 30 12:47:21 dnsmasq[18876]: cached wpad.home is NXDOMAIN
Jul 30 12:47:21 dnsmasq[18876]: query[AAAA] wpad.home from 192.168.1.169
Jul 30 12:47:21 dnsmasq[18876]: cached wpad.home is NXDOMAIN
Jul 30 12:47:21 dnsmasq[18876]: query[A] optimizationguide-pa.googleapis.com from 192.168.1.169
Jul 30 12:47:21 dnsmasq[18876]: cached optimizationguide-pa.googleapis.com is 142.251.29.95
Jul 30 12:47:21 dnsmasq[18876]: cached optimizationguide-pa.googleapis.com is 142.250.129.95
Jul 30 12:47:21 dnsmasq[18876]: cached optimizationguide-pa.googleapis.com is 216.58.204.74
Jul 30 12:47:21 dnsmasq[18876]: cached optimizationguide-pa.googleapis.com is 172.217.169.42
Jul 30 12:47:21 dnsmasq[18876]: cached optimizationguide-pa.googleapis.com is 142.250.151.95
Jul 30 12:47:21 dnsmasq[18876]: cached optimizationguide-pa.googleapis.com is 142.251.30.95
Jul 30 12:47:21 dnsmasq[18876]: cached optimizationguide-pa.googleapis.com is 142.250.117.95
Jul 30 12:47:22 dnsmasq[18876]: cached optimizationguide-pa.googleapis.com is 142.250.179.234
Jul 30 12:47:22 dnsmasq[18876]: cached optimizationguide-pa.googleapis.com is 142.250.200.42
Jul 30 12:47:22 dnsmasq[18876]: cached optimizationguide-pa.googleapis.com is 142.250.140.95
Jul 30 12:47:22 dnsmasq[18876]: query[A] prod-dynamite-prod-07-us-signaler-pa.clients6.google.com from 192.168.1.169
Jul 30 12:47:22 dnsmasq[18876]: cached prod-dynamite-prod-07-us-signaler-pa.clients6.google.com is 142.251.30.95
Jul 30 12:47:22 dnsmasq[18876]: query[HTTPS] prod-dynamite-prod-07-us-signaler-pa.clients6.google.com from 192.168.1.169
Jul 30 12:47:22 dnsmasq[18876]: cached prod-dynamite-prod-07-us-signaler-pa.clients6.google.com is NODATA
Jul 30 12:47:22 dnsmasq[18876]: query[A] static.xx.fbcdn.net from 192.168.1.169
Jul 30 12:47:22 dnsmasq[18876]: cached static.xx.fbcdn.net is <CNAME>
Jul 30 12:47:22 dnsmasq[18876]: cached-stale scontent.xx.fbcdn.net is 163.70.147.23
Jul 30 12:47:23 dnsmasq[18876]: forwarded static.xx.fbcdn.net to 1.1.1.1
Jul 30 12:47:23 dnsmasq[18876]: reply static.xx.fbcdn.net is <CNAME>
Jul 30 12:47:23 dnsmasq[18876]: reply scontent.xx.fbcdn.net is 157.240.214.11
Jul 30 12:47:23 dnsmasq[18876]: query[A] www.google.com from 192.168.1.169
Jul 30 12:47:23 dnsmasq[18876]: cached www.google.com is 142.250.140.147
Jul 30 12:47:23 dnsmasq[18876]: cached www.google.com is 142.250.140.99
Jul 30 12:47:23 dnsmasq[18876]: cached www.google.com is 142.250.140.105
Jul 30 12:47:23 dnsmasq[18876]: cached www.google.com is 142.250.140.106
Jul 30 12:47:23 dnsmasq[18876]: cached www.google.com is 142.250.140.104
Jul 30 12:47:23 dnsmasq[18876]: cached www.google.com is 142.250.140.103
Jul 30 12:47:23 dnsmasq[18876]: query[HTTPS] www.google.com from 192.168.1.169
Jul 30 12:47:23 dnsmasq[18876]: cached www.google.com is <HTTPS>
Jul 30 12:47:23 dnsmasq[18876]: query[A] datarouter.ol.epicgames.com from 192.168.1.169

Destrin · July 30, 2025, 2:07pm

okay the talk on power supply and then database access speed got me thinking so I ran up the agnostics sdtest script that the pi foundation provide and yeah:

Run 1
prepare-file;0;0;12679;24
seq-write;0;0;12517;3
seq-read;22399;5;0;0
rand-4k-write;0;0;2296;574
rand-4k-read;4960;1240;0;0
Sequential write speed 12517 KB/sec (target 10000) - PASS
Random write speed 574 IOPS (target 500) - PASS
Random read speed 1240 IOPS (target 1500) - FAIL
Run 2
prepare-file;0;0;12486;24
seq-write;0;0;12932;3
seq-read;22436;5;0;0
rand-4k-write;0;0;2211;552
rand-4k-read;4996;1249;0;0
Sequential write speed 12932 KB/sec (target 10000) - PASS
Random write speed 552 IOPS (target 500) - PASS
Random read speed 1249 IOPS (target 1500) - FAIL
Run 3
prepare-file;0;0;12896;25
seq-write;0;0;12496;3
seq-read;22386;5;0;0
rand-4k-write;0;0;2329;582
rand-4k-read;5000;1250;0;0
Sequential write speed 12496 KB/sec (target 10000) - PASS
Random write speed 582 IOPS (target 500) - PASS
Random read speed 1250 IOPS (target 1500) - FAIL

This SD card is not up to scratch on the random read IOPS which I imagine is going to be a factor...new SD card here we come

IvanDobsky · August 2, 2025, 7:26am

Neither am I ... but I was running via rubbish underpowered USB port on a router. Swapping to a dedicated PSU made a difference for me.

Nice spot. Personally I went one jump more and swapped to SSD. It all helps this six year old PI 3 run fine as my main Pi-Hole. I also have a VPN on here.