4

I just upgraded my 2018 15" MacBook Pro from Mojave to Catalina (10.15.4). It's been a few hours.

One of the first things I did after the upgrade was edit a video using the new free trial of Final Cut Pro X. My laptop's cooling fans ran full-speed the entire time, but there was always background rendering going on, so I figured that was normal.

When I finished and quit FCP, the fans didn't spin down, so I checked Activity Monitor and discovered that mDNSResponder is taking 90-100% CPU continuously. The Threads column in Activity Monitor indicates 3-4 threads most of the time; the 100% is spread across all of those, and they're not all on the same core. I'm not sure how it's managing to do that and still sit at or just under 100% most of the time, but that's what it's doing.

screenshot of Activity Monitor

The laptop has six cores (12 logical), so having one core fully occupied does not make a noticeable difference in performance (unless I start measuring how long things take -- but that's noticing that the numbers are different — not that the performance is different!).

Note: In the aggregate, the bar graphs show more than one full core being utilized. This is expected. I have a search applied in my Activity Monitor screenshot, and there's lots of other stuff going on -- Slack is open, Chrome with eleventybillion tabs, IntelliJ IDEA is probably indexing something, and so on.

I tried rebooting mDNSResponder using these commands:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

I watched the process disappear, so I know the command worked, but it immediately returned to 100% CPU usage when I started it back up. mDNSResponderHelper did not stop, so I tried again, inserting sudo killall mDNSResponderHelper as an intermediate step. This made both processes go away as I intended, but still didn't fix the problem.

I also tried sending a HUP signal to mDNSResponder as follows:

sudo killall -HUP mDNSResponder

This also had no effect.

I opened up Console, entered mdnsresponder in the search field, and watched the messages flow by for a minute or two. Some stuff about Bonjour, LOTS of <private>, and some pretty normal-looking DNS query logging. I tried disabling both Bluetooth and Wifi in hopes of affecting Bonjour, but I'm on a hardwired Ethernet connection (which I did not disconnect) and it did not seem to have any effect.

After typing this, I eventually noticed that cloudphotosd was also taking up a healthy chunk of CPU. I assumed that this was the notorious reindexing process that frequently happens after OS upgrades, going through my (quite large) photo library, updating metadata based on whatever new features came with Catalina, and uploading those changes to iCloud. That would explain some constant network activity, and so I thought maybe that would explain mDNSResponder's activity. So I left this window open without submitting and waited a while to see if cloudphotosd would calm down. It did, but mDNSResponder did not. So much for that hunch!

Finally, I tried rebooting my Mac; mDNSResponder wasted no time getting back to business. With no apps running after a fresh boot, it was already consistently sitting at or just under 100%, just like before.

This is a Q&A site, and I haven't asked a question, so here goes: how do I figure out what it is doing, and how do I make it stop?

UPDATE: it's been nearly 48 hours and it's still churning away. My battery life sucks now. I've observed that closing the laptop lid does seem to make it stop, but it comes right back when I open it again. I've also noticed an additional symptom: first-time DNS lookups after a reboot take ~2 seconds (I'd expect <200ms). I'm not sure if that's simply a side effect of mDNSResponder being so busy doing whatever it's doing or if it is related to the cause.

UPDATE 2: it's been more than three weeks. I've added a 100-rep bounty. The DNS lookup delay has increased; it often takes 20-30 seconds, and while there does seem to be some caching in place, I think it has a time-based expiry on it, because the delay reoccurs later without a restart. I'm happy to interact directly with someone knowledgeable enough to debug and diagnose this issue. I'm on Eastern Daylight Time in the United States (UTC-4) and generally available during business hours.

  • I don't think it's mDNSResponder per se. It will periodically scan your network looking for devices, but continually? No, it shouldn't. It also responds to DNS requests - if it's doing that while your Mac is sitting idle, something's making requests. Let's start off by booting in Safe Mode (Hold Shift while booting) to see if the activity stops. – Allan Apr 30 at 23:32
  • All that said...I am definitely not a fan of upgrading from one OS to the next; I like clean installs. In Apple world, things go a bit screwy when upgrading especially which such drastic changes like there is in Catalina. A clean install may be the solution to this one. – Allan Apr 30 at 23:35
  • I’ve been using Macs since ~1990 and have never skipped an OS version. I think I’ve done maybe two clean installs. So FWIW, “in Apple world, things go a bit screwy when upgrading” is maybe a bit of an overstatement. – JakeRobb Apr 30 at 23:40
  • I tried Safe Boot a while back — IIRC, mDNSResponder is calm while in that mode, but the behavior comes right back when I go back to regular mode. I will re-verify to be sure. – JakeRobb Apr 30 at 23:42
  • I've managed organizations with 1500+ Macs at a time for the better part of a decade and produced reams of technical notes on dealing with these things. I appreciate your experience, but where I'm coming from is far from "overstating" things. – Allan Apr 30 at 23:43
1

Here's my recommendation:

  1. Let's see what mDNSResponder is actually doing. Here's a utility to turn off/on censorship behind the <private>label. Make sure to turn it back on once you're done. You may find something like the process is hung up on something and just loops continually, or something like that. https://georgegarside.com/blog/macos/sierra-console-private/

  2. Get a packet capture of your network as you make a DNS request. Grab Wireshark, start a capture on the interface you're using (be it ethernet or WiFi; but make sure the one(s) you're not using are off/unplugged). I would do this first in the environment where it takes 20-30s, and then again after a reboot when the conditions are such that it only takes 2-3s. The less you can have using the network the better as you run these packet captures, as they'll get big fast. This should show us the DNS request as well as requests to and from the websites themselves, so we can see where the delays are. If there aren't delays in the network, then we'd look at processes instead.

  3. Upload relevant parts of the logs and/or the packet capture(s) somewhere for us to look at. Make sure you censor or remove any private data.

  4. And, finally, note that this may be solved faster by doing an in-place OS reinstall. That may oppose your views on being able to fix your equipment, knowing what goes on with your equipment, etc., but if the goal is to get mDNSResolver back to sanity as quickly as possible, an in-place OS reinstall may be the quickest way there.

| improve this answer | |
  • If you know how to make DNS requests from the command-line, that might be better than visiting a website with your browser, because it cuts out everything other than the DNS request. Also, this will show us parts of what the network is doing, but not the process: for that we may have to employ fs_usage, if it looks like the network isn't doing anything unexpected. – Harv May 1 at 0:01
  • 1
    I don't know if you know this, but "george" is active here. Also, can you expand on what the OP should be looking for after turning off the private label? There's lots of info in the log. As for the Wireshark log...what constitutes "relevant?" – Allan May 1 at 0:05
  • I had no idea George was here, that's awesome. What's his username? Regarding logs and Wireshark, there are many things that might be relevant, and I can't list or even predict them all. One example might be if OP is using Google's public DNS yet requests are actually taking 20s on an otherwise-fine connection. If we see that show up in the packet trace, we might also see where the delay is (going out or coming back). If it doesn't show up in the packet trace (eg packets went out and came back quickly), we can assume it's an issue in a process, not the network. – Harv May 1 at 0:06
  • So, it must be something other than just DNS requests. If I use dig or nslookup at the command line, queries come back instantly (~0.05s). I have some additional info. The problem persists regardless of the following: wired or wifi. ISP-provided DNS or Google DNS. Disabled my work-provided GlobalProtectDNS. Disabled Dropbox and Google Drive's syncing daemons. Other devices on my home network are not affected. – JakeRobb May 6 at 16:06
  • 1
    @JakeRobb nice work! Wondering if you’d be willing to share the script with me so I can reproduce it on my end. I’m very curious about what mDNS is doing. – Harv May 6 at 19:30
-1

This can be a lot of things, but all involving remote/sharing via the internet.

Do you have Screen Sharing, Remote Login, Remote Management, Bluetooth Sharing, or even Bonjour activated?

One of these things could be generating all of these DNS traffic.

On the other hand, this can be a Malware. Try to clean all your DNS cache and change it to 0.0.0.0

To flush DNS cache:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder    
| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .