-
Notifications
You must be signed in to change notification settings - Fork 117
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
Com.docker.hyperkit up CPU to 340% #1094
Comments
Thank for your report. There are known performance problems when running some "watch the filesystem"-style workloads which are being investigated. I've added this ticket to our internal tracker. If you have a particular scenario / use-case you'd like us to investigate (e.g. Dockerfile) then please do show it to us -- that would be very helpful. (FWIW I was able to reproduce the 50% CPU load observed via the |
I created a repo for testing one of the CPU spiking issues. It may be different than other reports (I haven't run across the CPU jump coming out of hibernation in quite awhile) but is something that I have personally run into. I can add any additional details her or to the repo if needed. |
I was experiencing similar problems and discovered that I need to adjust the memory setting for Docker for Mac in it's preferences, upping it from the default 2GB. I tried to reproduce using the repo that @jmreicha mentioned and could not with the increased memory setting. |
I tried upgrading to beta 34.1 as well as increasing the memory to 4GB but I still see the same result. It still takes about 5 minutes for the CPU to mellow out after running the |
I just ran |
Similar problem here using a container with Symfony (I know about actual issues) Expected behaviorNo spike in CPU Actual behaviorAfter running container with php and symfony, CPU usage is constantly around 300/450% Information
Steps to reproduce the behaviorI cannot link repo (business reasons). |
@jmreicha it sounds like @carmelocatalfamo by default We currently have a number of patches in testing that should significantly reduce the CPU usage of both HyperKit and osxfs in scenarios like these. Additionally, there were some issues with the Linux scheduler in multi-processor configurations that have been improved in recent Linux kernel releases (4.8+). I recommend using the Beta channel for the most up-to-date performance improvements. |
@dsheets Thanks for the update. Do you know which version these improvements will be released in or have a timeline for when we will see the patches? |
Linux 4.9 which should be in Beta 37 should show some improvement and 38 or 39 should have some more. |
@dsheets Yes, thanks. Solved with |
I was able to test this out, and the performance has improved SIGNIFICANTLY in Beta 38. No more CPU spike from hyperkit. |
FWIW...my macOSSierra + Docker CPU issues were resolved by simply increasing the amount of memory used by Docker from 2GBs to 4GBs as @dcroley suggested. I am currently running 15 docker containers for various reasons and so 2GBs were obviously not enough. |
I finally 'reset to factory defaults' then fixed the issue. Version 1.13.1 (15353) |
Like @ken-at-sri (@dcroley and @zhangalex ) Warning, this will remove your existing containers Seems to have done the trick. (com.docker.hyperkit is no longer hogging the cpu) Thanks all! |
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. |
Expected behavior
No spike in CPU
Actual behavior
After running an npm install locally on a large project and using volume mounts, com.docker.hyperkit eats up lots of CPU and doesn't release it until the Docker app is restarted.
Information
Steps to reproduce the behavior
I'm linking to this thread on the D4M forums, as the discussion originated over there. The first link above also has steps to reproduce as well.
There is lots more info in the post. Basically, doing lots of reads and writes (npm install) when using volume mounts causes the com.docker.hyperkit process to eat CPU until the app is restarted. There is probably more to the puzzle.
The text was updated successfully, but these errors were encountered: