Com.docker.hyperkit up CPU to 340%

[jmreicha]

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

• Full output of the diagnostics from "Diagnose & Feedback" in the menu

Docker for Mac: version: 1.12.5 (3e6f00c1d)
OS X: version 10.11.6 (build: 15G1004)
logs: /tmp/6CF4E326-BEB6-4F67-A37C-573FA4CBEFAE/20161230-131947.tar.gz
[OK]     vmnetd
[OK]     dns
[OK]     driver.amd64-linux
[OK]     virtualization VT-X
[OK]     app
[OK]     moby
[OK]     system
[OK]     moby-syslog
[OK]     db
[OK]     env
[OK]     virtualization kern.hv_support
[OK]     slirp
[OK]     osxfs
[OK]     moby-console
[OK]     logs
[OK]     docker-cli
[OK]     menubar
[OK]     disk

• A reproducible case if this is a bug, Dockerfiles FTW
  • https://forums.docker.com/t/com-docker-hyperkit-up-cpu-to-340/13057/32?u=jmreicha

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.

[djs55]

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 naumanbadar/activator-runner image)

[jmreicha]

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.

[dcroley]

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.

[jmreicha]

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 yarn install on the host machine.

[jmreicha]

I just ran yarn install on the host without anything else running and noticed the CPU spiking issue, so this happens even without containers. It looks like something that docker.hyperkit itself is doing and not specific to containers but I'm not sure how to troubleshoot that.

[carmelocatalfamo]

Similar problem here using a container with Symfony (I know about actual issues)

Expected behavior

No spike in CPU

Actual behavior

After running container with php and symfony, CPU usage is constantly around 300/450%
Last command is 'npm start' which start gulp but i have no problem with this process. Gulp reload bundles very fastly.

Information

• Diagnostic ID: 7512DBAE-0FC4-4A91-9E1D-C75CB435D900

• Diagnostics output:

Docker for Mac: version: 1.12.5 (3e6f00c1d)
OS X: version 10.12.2 (build: 16C67)
logs: /tmp/7512DBAE-0FC4-4A91-9E1D-C75CB435D900/20170105-144513.tar.gz
[OK]     vmnetd
[OK]     dns
[OK]     driver.amd64-linux
[OK]     virtualization VT-X
[OK]     app
[OK]     moby
[OK]     system
[OK]     moby-syslog
[OK]     db
[OK]     env
[OK]     virtualization kern.hv_support
[OK]     slirp
[OK]     osxfs
[OK]     moby-console
[OK]     logs
[OK]     docker-cli
[OK]     menubar
[OK]     disk

• Screenshot:

Steps to reproduce the behavior

I cannot link repo (business reasons).
As soon as possible i will send you a similar image to reproduce issue.

[dsheets]

@jmreicha it sounds like yarn install either does a lot of file system operations or starts background processes to complete work after the command has returned. The naumanbadar/activator-runner image in the forum thread is doing rapid file system polling which causes the CPU use that people have reported with it. The mds_stores, mds, and mdworker processes you observe in your jmreicha/cpu-bug test case belong to macOS's metadata service which indexes files for features like Spotlight. Their appearance is expected after heavy file system usage involving creation, deletion, and edition of files and directories.

@carmelocatalfamo by default gulp polls the file system for changes instead of using a file system event notification mechanism like inotify. I recommend using a package like gulp-watch that uses chokidar that itself uses the appropriate file system event interface for the platform.

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.

[jmreicha]

@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?

[dsheets]

Linux 4.9 which should be in Beta 37 should show some improvement and 38 or 39 should have some more.

[carmelocatalfamo]

@dsheets Yes, thanks. Solved with gulp-watch! Cpu from 390 to 1.5%!

[jmreicha]

I was able to test this out, and the performance has improved SIGNIFICANTLY in Beta 38. No more CPU spike from hyperkit.

[ken-at-sri]

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.

[zhangalex]

I finally 'reset to factory defaults' then fixed the issue.

Version 1.13.1 (15353)
Channel: Stable
94675c5a76

[micklove]

Like @ken-at-sri (@dcroley and @zhangalex )
I used the 'reset to factory defaults' option in docker preferences
(under the 'reset' tab in the docker client preferences)
I then upped the ram to 4GB.

Warning, this will remove your existing containers

Seems to have done the trick. (com.docker.hyperkit is no longer hogging the cpu)

Thanks all!

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

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.
/lifecycle locked