Docker Mac backend CPU at 100% even with no containers or volumes

[rjcohn]

• [X] I have tried with the latest version of Docker Desktop
• [X] I have tried disabling enabled experimental features
• [X] I have uploaded Diagnostics
• Diagnostics ID: 0D18D530-E22B-4E5F-8CF1-E5799C452F32/20210214162249

Expected behavior

CPU utilization normal

Actual behavior

com.docker.backen CPU utilization at 100%

Information

• macOS Version: 10.15.7
• Docker Desktop Version: 3.1.0 (51484)

Steps to reproduce the behavior

I run docker-compose with 3 containers, a shared volume, and a mount point. After running, com.docker.backend stays at 100% CPU. I give Docker 8/16 CPUs, and one CPU is in use at 100%. Even after:

• docker-compose down -v --remove-orphans
• docker system prune -f
• restarting Docker from the menu, CPU remains at 100%.

I still see this: rcohn 39299 99.3 0.1 5168448 37668 ?? R 11:37AM 1:48.98 /Applications/Docker.app/Contents/MacOS/com.docker.backend -watchdog

Only after quitting Docker and manually restarting returns things to normal.

This seems to have started with a recent update of Docker, though I can't say for sure which one.

[stephen-turner]

@rjcohn Do you have any JetBrains products running? There is a known issue with them polling at an excessive rate.

Alternatively, are you sharing the minimum number of files? Trying to share the whole of your home directory (for example) will lead to a large amount of CPU.

[rjcohn]

I do use PyCharm, but this is repeatable without PyCharm running. If it's helpful, I could restart my mac and try this without ever having started PyCharm. I mount my home directory only for debugging. We don't do anything like that in our prod envs. But we've also been doing that for a long time (a year or more), and this problem has only started happening recently.

[hanoii]

Probably duplicate of #5164

[evg-rz]

• [x] I have tried with the latest version of Docker Desktop
• [x] I have tried disabling enabled experimental features
• [x] I have uploaded Diagnostics
• Diagnostics ID: 0D18D530-E22B-4E5F-8CF1-E5799C452F32/20210214162249

Expected behavior

CPU utilization normal

Actual behavior

com.docker.backen CPU utilization at 100%

Information

• macOS Version: 10.15.7
• Docker Desktop Version: 3.1.0 (51484)

Steps to reproduce the behavior

I run docker-compose with 3 containers, a shared volume, and a mount point. After running, com.docker.backend stays at 100% CPU. I give Docker 8/16 CPUs, and one CPU is in use at 100%. Even after:

• docker-compose down -v --remove-orphans
• docker system prune -f
• restarting Docker from the menu, CPU remains at 100%.

I still see this: rcohn 39299 99.3 0.1 5168448 37668 ?? R 11:37AM 1:48.98 /Applications/Docker.app/Contents/MacOS/com.docker.backend -watchdog

Only after quitting Docker and manually restarting returns things to normal.

This seems to have started with a recent update of Docker, though I can't say for sure which one.

• minimization shared volume
• use mutagen.io - https://mutagen.io/documentation/orchestration/compose
• disabling TurboBoost. pls, use TurboBoostSwitcher (it's free or you can buy pro version) - https://github.com/rugarciap/Turbo-Boost-Switcher

I hope this helps you. I'm sorry for my bad english)

[rjcohn]

Probably duplicate of #5164

I agree.

[santacrab]

Same thing here on macOS Big Sur 11.2.1 (20D74). Docker version 3.1.0 (51484).

• Fresh started Docker with no containers, no volumes stays around 10% CPU usage (much better against the 50% of the 2.x version).

• 60+% CPU usage with just a Couchbase running with NO ACTIVITY at all: no shared volumes, no requests, no running services connected to the Couchbase instance

[Sharpie]

Same here with Docker Desktop 3.2.1 on macOS 10.14.6. com.docker.backend was consuming 100% CPU even after all containers had been stopped and pruned. Energy impact was bad enough that I had to dig the 85 watt power brick out of the closet as the 65 watt tap from my monitor could not keep the battery from running down.

Disabling experimental features, quitting the app, and re-launching resolved the issue.

[docker-robott]

Issues go stale after 90 days of inactivity. Mark the issue as fresh with /remove-lifecycle stale comment. Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. /lifecycle stale

[bokysan]

@docker-desktop-robot I still need to reset my Docker weekly on my Mac so the issue is certainly not stale.

[sempasha]

No containers are running. No images, no volumes and networks are registered. 100% CPU is utilized by process /Applications/Docker.app/Contents/MacOS/com.docker.backend -watchdog -native-api.

$ docker --version
Docker version 20.10.8, build 3967b7d

Docker Desktop version is 4.0.1

[emiliomg]

I have the same problem on my machine:

docker --version
Docker version 20.10.12, build e91ed57

Docker Desktop 4.5.0

MacOs Monterey 12.2.1

[ondrados]

Fresh install of Docker Desktop, only thing i done is to run Docker Desktop and CPU usage is at 100%. MacBook is almost melting...

[kassiansun]

Same here with v4.5, it goes 100% after running a compose service, gets back to 0% after quit and restart Docker. Tried with v4.6 and new fire sharing feature enabled, the build stage doesn't trigger CPU usage at Docker process anymore, so it never goes to 100% and everything works fine now.

[hanoii]

After struggling with this for years, with every single version update of Docker, this has been a life saver: https://www.marco.zone/docker-uses-over-100-percent-cpu

It's a work around, but it does work 🤷 , hope this helps others!

[lcucurachi]

Having the same issue on latest docker version 4.37.2 (179585) and MacOS Sequoia 15.2. Still no fix?

[dotsbb]

having the same issue on Docker version 27.5.1, build 9f9e405 and MacOS Sequoia 15.3.1

UPD: deleting Docker app and reinstalling it - fixed the problem (at least for now)

[maxoux53]

~got the same issue :/ no containers running, no images, no volumes and docker desktop is closed (Quit)...~

edit: not anymore ✅

[vicding-mi]

Same here with Docker Desktop 3.2.1 on macOS 10.14.6. com.docker.backend was consuming 100% CPU even after all containers had been stopped and pruned. Energy impact was bad enough that I had to dig the 85 watt power brick out of the closet as the 65 watt tap from my monitor could not keep the battery from running down.

Disabling experimental features, quitting the app, and re-launching resolved the issue.

had the same issue. disabling the experimental features, quitting the app, hard kill the com.docker.backend and re-launching solved the problem.

[lcucurachi]

Same here with Docker Desktop 3.2.1 on macOS 10.14.6. com.docker.backend was consuming 100% CPU even after all containers had been stopped and pruned. Energy impact was bad enough that I had to dig the 85 watt power brick out of the closet as the 65 watt tap from my monitor could not keep the battery from running down.

Disabling experimental features, quitting the app, and re-launching resolved the issue.

had the same issue. disabling the experimental features, quitting the app, hard kill the com.docker.backend and re-launching solved the problem.

Does disabling experimental features resolve the issue completely?

[vicding-mi]

In my case, hard killing of the com.docker.backend is as well needed. After restarting the docker desktop, the cpu surge was gone.

[imrhlrvndrn]

Same here with Docker Desktop 3.2.1 on macOS 10.14.6. com.docker.backend was consuming 100% CPU even after all containers had been stopped and pruned. Energy impact was bad enough that I had to dig the 85 watt power brick out of the closet as the 65 watt tap from my monitor could not keep the battery from running down. Disabling experimental features, quitting the app, and re-launching resolved the issue.

had the same issue. disabling the experimental features, quitting the app, hard kill the com.docker.backend and re-launching solved the problem.

This worked for me too. Thank you for sharing @vicding-mi