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.
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.