com.docker.backend uses 100% with no containers running #5164
Comments
|
Version 3.0.2 and 3.0.3 are same, high cpu. |
|
Confirming behavior on 3.0.3 with macOS 11.1 (big sur). Persistent, 100% CPU usage by |
|
Is this still an issue in 3.1.0? |
|
I am able to observe high com.docker.backend CPU usage on my 3.1.0 (51484). |
3.1.0 seems to have fixed it for me. |
|
I'm also seeing ~100% CPU usage by com.docker.backend (22 threads) on my 3.1.0 (51484). I've attached a Sample of com.docker.backend.txt that suggests to me that a thread spinning within github.com/docker/pinata/common/pkg/paths.FrontendExecutable: |
Not me. I'm still seeing this in 3.1.0. Edit: I went into "Docker Engine" settings on my end to see if anything looked weird, and changed "Docker Engine" JSON settings for Edit: I'm on macOS 10.14.6 on Intel hardware. |
|
I'm still seeing this problem on 3.1.0. Still only with the bind mount, though. I have both |
|
On OSX, turning off the experimental features seems to fix it. |
However, turning off |
|
AFAICT, the docker engine config is irrelevant, the only thing that had an impact for me was the FUSE option. |
|
Also experiencing this on macOS Catalina 10.15.7 (19H524) and Docer 3.1.0 (51484). I just disabled gRPC FUSE and will see how it behaves. |
|
I did that, thought all was good, it was not. I had a particular directory in the bind mount that never saw updates without restarting docker. Other dirs seemed unaffected. It seemed to only pick up the current version at the time I (re)started docker. This cost me a bunch of time, so I just sucked it up and re-enabled the gRPC FUSE option. I guess it's a good thing I'm working from home so I can plug in all the time. |
|
Probably related to #5200 |
This was referenced Feb 16, 2021
|
Just had this issue on M1 (Big Sur 11.2.1) and I had a few containers running but they were all at less than 0.1% cpu utilization |
It's not. I haven't discovered a pattern so far. Resetting docker to Factory defaults usually fixes the issue for a while - at least for me. |
|
as suggested it helped me to turn off experimental features 🤷♀️ |
|
Thanks @luxmeter, I've checked before to verify I don't have any experimental features enabled so that's not the case for me |
|
I updated my Docker Desktop today to try and deal with this same issue, and because apparently Docker doesn't give me the option not to upgrade anymore. Now my lando environments won't boot up and my productivity is ground to a halt. So that's awesome. |
|
FWIW on 3.1.0 I Restarted Docker and the problem went away (I have gRPC FUSE enabled, which I think is the stock configuration). |
|
I am still seeing this issue with Docker for Mac 3.2.2 |
|
The behavior is erratic. I ran the past few weeks on Docker Desktop for Mac version 3.2.2 on macOS 10.15.7 without problems. But then today I needed to rebuild one of my containers to upgrade its software. Upon restart of the container, I've seen this behavior before, and it seems that every now and then I am able to start my containers without triggering this problem. But once it is triggered, stopping all of the running containers, and even deleting everything but leaving Docker Desktop running, the backend process continues to run amok. Only stopping Docker itself and restarting it will work. So I've resorted to restarting over and over until I somehow hit the sweet spot where it works correctly. Here is what resource usage looks like when running 10 containers (idle), which is the expected behavior: |
same |
|
Also having this issue with the latest lando: 3.1.0 |
|
Confirmed still present in version 3.3.0 (Engine v20.10.5), as soon as I start a container with a mounted disk, FWIW, here's a spin dump of the thrashing process from the latest version, 3.3.0: |
|
I used the hack successfully: |
|
dd 3.5.2, Mac OS 11.5, switching off Use gRPC FUSE for file sharing solved the problem immediately |
|
dd 3.6.0 |
|
UPDATE: Turns out this did not actually fix the issue. I'm on macOS 11.5.2 and was experiencing the same issue. I was able to fix it by following these steps:
I still have "Use gRPC FUSE for file sharing" enabled in the Docker settings. I'm able to consistently reproduce the high cpu issue if I revoke the files and folders entitlements and restart Docker. |
|
@dafalcon That's a great find. My only question - were you using any of those folders in any way with your docker runs? As in mounting any of those dirs or their children? I'm guessing not, which would make this an even more unintuitive fix. |
|
@dafalcon would love to try this, however Docker is not listed in the Apps under Files and Folders. Any idea why that may be the case? |
|
@keithlayne, @tibotiber after more testing I can say the entitlements were a red herring and did not actually fix the high cpu issue. Apologies for that! However I did find a way to reliably reproduce the issue. Restart Docker to start from a clean slate, then run any container while bind mounting your toplevel home directory into the container:
The command itself runs as expected, but it immediately causes com.docker.backend to consume 100% cpu until I restart Docker. If I run a similar command but with a subfolder instead of my toplevel home dir, com.docker.backend does not go to 100% cpu:
The behavior is the same regardless of whether entitlements have been granted. Hope this helps! |
|
Thanks for getting back @dafalcon |
|
this stills happening.. been like this for looooong time. and now... Companies waste more funds in monthly electricity caused by this bug that overheats the majority of the developers laptops in the office compared the cost itself of the license that Docker, Inc. is asking now. I would discourage everyone to buy a single license from Docker, Inc. until this bug is resolved. It would be the first license I see that doesn't include support "take it or leave it".. I guess "we, the community" (those who contributed to a large amount of your code) would have to take cards into this... GGWP! |
|
I've tried all suggestions in this thread and nothing seems to stick. Still at 99% CPU when using docker. When will this be fixed? |
|
This is going to be a popular thread as EKS-A got announced today and my com.docker.backend started cooking trying to deploy it (with focus on trying). |
|
Still happening on v4.0.1 (MacOS 11.6) though unchecking gRPC FUSE still works to control CPU thankfully. |
|
macOS 11.6 Still happening for me. Disabling Before fixing it, I used instruments to figure out where all this wasted electricity was going: |
|
Happening for me right now on MacOS 10.15.7, with no containers at all (running or stopped):
This might be related to bind-mounting, as I'd never seen this issue before and was never bind-mounting before. Now I've started using bind-mounting regularly and this showed up; will follow up with more information if I can find any. EDIT1: Doing the update-and-restart flow from Docker Desktop has fixed the high CPU issue for now (though no containers are running). |
|
Really annoying.. we try to develop mostly simple Rails/Javascript Apps, with most powerful Laptops on the market... and then such things.... I feel like beeing thrown in the year 2002 Compared screenshots ordered by CPU% :
Most recent Docker for Mac Macbook Pro 2020 16" 16GB
without success... What else can we do? |
|
@exocode give up on Docker Desktop for macOS (and probably Windows) and switch to GitHub Codespaces, which is pretty great from what I've seen so far. Or try VS Code's |
@mrmachine me too in the meanwhile. I uninstalled Docker for Mac completly! I use now: and it works like a charm... two more commands to spin up.. BUT NO troubles anymore... Mac is now more silent and only 30% of CPU is used. This is how I spin up minikube on Mac (I had to provide
|
|
Issues go stale after 90 days of inactivity. Prevent issues from auto-closing with an 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. |
|
/remove-lifecycle stale |
|
Going on for over a year, hard to have any confidence that there's any understanding of even what is causing this. Going to look into the advice of others and look at things like Minikube. What good is a fancy UI with an unwanted permanent fan tester bundled with it. |
|
FWIW, I have totally abandoned Docker Desktop. I only needed it for one client so we could use Lando dev tool. Now that we have to pay for a license it isn't worth the trouble and I am switching them over to Docksal which works with VirtualBox. |
|
Make sure you don't have the Docker VS code extension installed. This so far has fixed this very frustrating issue for me... |
|
Issues go stale after 90 days of inactivity. Prevent issues from auto-closing with an 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. |
|
Closed issues are locked after 30 days of inactivity. If you have found a problem that seems similar to this, please open a new issue. Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
and others
Expected behavior
Very low CPU usage when not running any containers
Actual behavior
com.docker.backendusing 100% of 1 CPU core while no containers are running.Information
This is new with 3.0.2. Did not happen with 3.0.1. Exactly the kind of thing that causes me to want to be able to disable automatic updates (see also #5163).
Reproducible.
Diagnostic logs
<!-- Full output of the diagnostics from "Diagnose & Feedback" in the menu ... -->I cannot find "Diagnose & Feedback" in the menu
Steps to reproduce the behavior
docker run -it -v $HOME:/localhost --rm alpine:3.12.1 truedocker psand observe no containers are runningcom.docker.backendreporting 100% CPU usageThe text was updated successfully, but these errors were encountered: