-
Notifications
You must be signed in to change notification settings - Fork 266
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Docker Desktop] Investigate Mac CPU performance #12
Comments
Ben, for purposes of documentation of pain points with Docker on Mac, I wanted to make sure there was a reference back to these complaints. Thanks -Alan |
Please add docker/for-mac#4392 to this list. |
Thanks @aguedeney and @cculianu - when we move this into in progress I will link back the tickets we are using in for-mac to highlight where we will be discussing with everyone and also where we will be seeking fresh logs for issues :) please feel free to add other cases here as you think appropriate! |
Please add docker/for-mac#4064. |
The primary issue with CPU that I have seen relates to volume mounts, transfused, and heavy IO workloads. I have observed this a lot of times and inside the VM it is usually transfused using the CPU. See this on why mounts use lots of CPU. Namely: A Linux system call such as open or read that accesses bind-mounted files in a container must be. - turned into a FUSE message in the Linux VFS - proxied over a virtio socket by transfused - forwarded onto a UNIX domain socket by HyperKit - deserialized, dispatched and executed as a macOS system call by osxfs The entire process then takes place in reverse to return the result of the macOS system call to the container. |
This definitely makes sense for bind mounts because it's having to go in and out of the VM to interface with the host filesystem, but I'm still seeing high CPU usage after we switched to using named volumes and that should all be inside of the VM, but I'm still seeing high CPU usage when things are sitting idle, so is there any similar |
This issue is too broad. Some people may suffer from mounts CPU performance, but other have 100% cpu after prune command in this issue: docker/for-mac#4064 |
Thanks to all the responses! |
Hope this helps in some way. I was running into CPU issues as well and noticed something weird happening with volumes. It works as expected, a file from the specific node_module that I modified locally was copied to the container. Likewise I modified a file in another node_module and the change was not copied to the container. Everything works fine. The issue came when I did a I did investigating a few months ago so the reproduction steps might be off, but there was definitely an issue with volumes copying files that it was not supposed to.
|
I would like to highlight that docker/for-mac#3499 (comment) has a concrete suspicion of potentially bugged code that might be easy to investigate (with OCAML knowledge).
I would also like to add that this is not the only cause. I do sometimes see docker spike to at remain at 100% without any containers running. Definitely no high IO workload in that case, pure "home" usage. |
I've also had times where the Docker process was using 100% CPU indefinitely when no containers were running. |
@schellj , can you do a diagnose when it happens? (if the whale menu is responding of course). |
@ebriney I haven't had any issues with Docker for Mac using a lot of CPU unexpectedly since early May - see docker/for-mac#4064 (comment), but I did a couple of diagnostics when I was - see docker/for-mac#4064 (comment) and docker/for-mac#4064 (comment) (I made some other relevant comments in that issue as well). |
I installed the edge build (with spindump) and uploaded this diagnostic: The Kubernetes containers were running (with nothing to manage), nothing from my side, and Docker used 50% CPU. |
My Diag Id with spindump 80E081FA-7763-4245-BB3F-15814B31E0BB/20200627174556 |
Another diag ID F2F1BBBF-4BF7-4158-BCFA-0C29469D1E33/20200630084358 |
Here's another one with only 5-10% but it still seems like a lot with no containers running on a decent MBP: A913E1F9-1085-4C2B-A79D-4B6862C0EA1E/20200630095026 |
Another diag: 93B23EAA-7413-4ACB-8278-F008093AD412/20200701154406 |
The new edge build works pretty well for me. I can work for quite some time comfortably. CPU use stays at around 25% with a couple of containers running. But after a while (2 hours or so) or when waking my machine from sleep, com.docker.hyperkit flares up to 200% - 250% and stays there until I stop all containers. With no containers running I'm at 5% cpu. |
Concur with @vredeling Edge 2.3.6.0 is working much better for me. I think there is at least one dangling issue, however: Returning from sleep sends the hyperkit process spinning on all CPUs. Stopping the containers does not help. I am able to stop the bleeding be using Restart from the Docker tray icon. I have gRPC-FUSE enabled. Let me know if there is any information I can provide to help diagnose the issue. |
With gRPC-FUSE enabled I'm getting some operation denied calls when a bazel build in the docker container attempts to create a symlink within a bind mounted directory. |
@vredeling @JamesonNetworks If you can reproduce this issue on waking the computer, please upload a diagnostics bundle and paste the GUID here. Thank you. |
@jsharpe thanks for your feedback -- are you able to create and share a small repro case of the problem? If not, next time it manifests, could you upload a diagnostics report and quote the ID on a fresh ticket on https://github.com/docker/for-mac ? Thanks! |
@djs55 Yes to repro:
Gives output when grpc-fuse is on:
When using osxfs you will see bazel build the software. This is on edge 2.3.6.0 |
@stephen-turner Alright, got an ID for the diag:
After sitting with this issue for a couple of weeks, I'm noticing the high CPU calm down after about 30-40 mins. I assume this is actually expected behavior and not an issue. Wanted to come back here and update in case anyone was looking into it. I believe 2.3.7.0 solves all my CPU woes. I appreciate all that the docker team is doing, thanks for the good work and awesome software everyone! |
I just thought I'd report a positive outcome from upgrading to the 2.3.7.0 Edge release, following advice in the comments here. For three days since upgrading from Stable 2.3.0.4 to 2.3.0.5, I had constant high CPU (and associated fan noise), despite virtually idle container activity. Following the upgrade, I can report that hyperkit %CPU is sitting just under 20%: |
I've not encountered this issue any more since I moved to Docker Desktop 2.3.7.0 |
The latest CPU-related changes from the edge 2.3.7.0 have now made it to stable 2.4.0.0 for Mac and Windows. If you get a chance to try this, let us know how it goes. If there are still CPU problems please provide as much information as you can: ideally a repro example and a set of diagnostics. Thanks for all your help so far! |
I just upgraded to 2.4 for Mac and CPU usage is a lot better for the app I'm running! The code is mounted inside the container during development and the app checks all relevant files (769 atm.) for changes every 5 seconds in order to auto reload. This usually caused a good spike in CPU usage up to around 50% CPU. Now there's a consistently low usage, mostly below 5%, when checking every second! So I can confirm that IO performance and CPU usage have improved a lot in this update in my case. Tested on: MacBook Pro (13-inch, 2017, 2,3 GHz Intel Core i5) |
I'm still getting 2.3.7.0 as latest release, both on stable and edge channel. What's needed to get 2.4 to install? |
@andig 2.4.0.0 is latest in Stable. 2.3.7.0 was never in Stable and never will be. See the Stable Release Notes for how to download any stable version. Note that you will lose all containers and volumes switching from edge to stable. |
I've upgraded to 2.4.0.0 and got a lot of |
I have updated Docker to 2.4.0 the CPU usage seems to be lower (now only around 10-12%) and everything has been running smooth so far on my MacBook Pro 2.8 GHz Quad-Core Intel Core i7. |
Yes! this is a giant improvement!!! |
And even works on MacOS Big Sur ;-) |
hm the 2.4.0 build was behaving well so far without any fans running extensively all of a sudden without an apparent reason. but today after starting a project and leaving the computer for half an hour, just started up a project in DDEV right before, when i returned the fans were running on max and the cpu was spiking without a stop. :/ setup: macos 10.13.6 on a mbp 13" early 2011 8GB RAM with docker desktop 2.4.0 running a Drupal site with DDEV. i've sampled the .com.docker.backend process which was constantly at +/- 100% and com.docker.hyperkit which was around 10 to 30%... the samples: p.s. and according to the deprecation notice for high sierra on the first startup of the minor 2.4.0 release it was the last release for macos 10.3 so no 2.4.x bug fix release anymore? |
Hey all, We have now shipped the changes from our investigation over the last 3 months as part of the 2.4 Desktop release. We will do a blog post in a few weeks detailing the things we found/changes we made to give you some insight into what we did and why. If you are still having issues, I would ask that you create new tickets on for-mac rather than comment on old tickets as we are going to close these to keep our backlog a bit tidier and not mix up the messages (and it is easier for us to get signal on the scale of issues this way). Thanks again for your patience and an even bigger thank you to all of you who took the time to test builds & upload diagnostics! |
@nebuk89 can you share link to blog post if it was written? |
@sashaaKr Unfortunately we never got round to writing the blog post. |
Tell us about your request
CPU performance on Mac is a long standing issue, we have investigated this in the past but want to dedicate time to re-invetsigate this and try and find a fix
Which service(s) is this request for?
Desktop
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
We keep spiking to 100% CPU and this isn't good, no one likes their laptop taking off
Are you currently working around this issue?
N/A
Additional context
N/A
Attachments
docker/for-mac#1759
docker/for-mac#3499
docker/for-mac#2601
The text was updated successfully, but these errors were encountered: