High CPU issue on boot

Over 100% CPU usage from pihole-FTL for approximately 10 minutes during which the GUI (obviously) does not connect the API and Pi-hole doesn't work. Restarting causes the same look of high CPU usage to happen. Ran pihole -r. Same issue afterwards.

Pi-hole v5.2.4
Web Interface v5.3.2
FTL v5.6
Debian 10 32-bit

Please upload a debug log and post just the token generated by

pihole -d

allowing to upload when prompted, or do it through the Web interface:

Tools > Generate Debug Log

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

This issue only started after running most recent update. Prior to this updated a few months ago,

You are running out of memory:

   [2021-02-04 04:46:18.405 843M] Resizing "FTL-dns-cache" from 24576 to (1792 * 16) == 28672 (/dev/shm: 1.6GB used, 1.6GB total)
   [2021-02-04 04:46:18.405 843M] WARNING: More than 90% of /dev/shm is used

You have enabled Conditional Forwarding:

*** [ DIAGNOSING ]: Setup variables
    REV_SERVER=true
    REV_SERVER_CIDR=192.168.1.0/24

You may have created a partial DNS loop here, if your router had been configured to use Pi-hole as its upstream DNS server (as opposed to distributing it as local DNS server via DHCP). Pi-hole and your router may then bounce DNS queries back and forth among them forever or until time-out.

This would result in an excessively high volume of queries, which could explain high memory usage pointed out by jfb.

However, that is not confirmed by your current usage statistics, which show only a reasonably low amount of queries:

*** [ DIAGNOSING ]: contents of /var/log
 -----tail of pihole-FTL.log------
 Imported 23373 queries from the long-term database
  -> Total DNS queries: 23373
  -> Cached DNS queries: 5957
  -> Forwarded DNS queries: 7176
  -> Blocked DNS queries: 6395
  -> Unknown DNS queries: 0
  -> Unique domains: 862
  -> Unique clients: 11
  -> Known forward destinations: 5

But then, those may be low only due to a recent restart.
You could check your current stats (last 24 hours) by running:

echo ">stats >quit" | nc localhost 4711

The following command would give us an indication of the number of queries conditionally forwarded to your router in the last few days:

zgrep -c "to 192\.168\.1" /var/log/pihole.log*

You should check your router's configuration, and also check whether disabling CF would mitigate your issue.

dnsmasq directly delegates the Pi-hole as the DNS server via DHCP. Below is the setting for anyone else interested.

dhcp-option=option:dns-server,IPv4

There were over 23,000,000 queries (from the DHCP server) after the Pi-hole started functioning again, including some very odd entries. Only keep queries for 24 hours, so don't have these records anymore. Agree, whatever was causing so many queries was causing the lack of memory.

Restarted and everything is working now after a reboot.

For future privacy reference, how long are debug records kept?

An uploaded Debug Log is kept for 48 hours, as mentioned in the log itself (click for head):
~ $ head /var/log/pihole_debug.log
This process collects information from your Pi-hole, and optionally uploads it to a unique and random directory on tricorder.pi-hole.net.

The intent of this script is to allow users to self-diagnose their installations.  This is accomplished by running tests against our software and providing the user with links to FAQ articles when a problem is detected.  Since we are a small team and Pi-hole has been growing steadily, it is our hope that this will help us spend more time on development.

NOTE: All log files auto-delete after 48 hours and ONLY the Pi-hole developers can access your data via the given token. We have taken these extra steps to secure your data and will work to further reduce any personal information gathered.

I take it you are referring to a dnsmasq instance running on your router?

If CF is not the reason for high volume of DNS queries, you should consider finding the device causing that and stop it from doing so.

Should have read the debug report instead of skimming it.

Yes

The DHCP server was sending all the queries based on the top client statistic. I think it had something to do with conditional forwarding, but since it is working now I am happy.

Thank you for the prompt help. IPFire creators are very much against DNS blocking, but I think it is the best bad solution to filter what don't want.

Similar thing happened. This time DNS failure without high CPU usage. Updating and restarting Pihole resolved.

Please add

DEBUG_ALL=true

to the file /etc/pihole/pihole-FTL.conf (create if it does not exist) and run

pihole restartdns

Next time the failure happens, please include the last couple of lines from /var/log/pihole-FTL.log and /var/log/pihole.log
This should help us getting a better picture of where/why exactly the issue happens.

Thanks.

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