'com.docker.hyperkit' process has a very high CPU utilisation

[ghost]

Expected behavior

The process should not be at a very high CPU usage when I'm not interacting with docker.

Actual behavior

The process 'com.docker.hyperkit' is using constantly around 170% of CPU (I have 4 core of my Mac).

Information

My diagnostic id is : 1DBFDF68-B5A9-4686-AA8E-E790DC0C5DB9

Docker for Mac: version: 1.12.6 (a3b0f1129)
OS X: version 10.12.2 (build: 16C68)
logs: /tmp/1DBFDF68-B5A9-4686-AA8E-E790DC0C5DB9/20170112-143647.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

If you have any idea of what could be the issue it would be great :)
Thanks a lot

[dsheets]

Are you running any containers? What are they doing? Can you share their command lines? Does the high CPU utilization continue after all containers are stopped?

[mikeball]

Well know mounted volumes bug that's been know about for nearly a year, don't waste your time. Find solution other than d4m to run containers, it's unusable with mounted volumes.

#1094
https://forums.docker.com/t/com-docker-hyperkit-up-cpu-to-340/13057/67
https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/205

[ijc]

@Matt298 I'm sorry that your usecase/workload is not among the set which work well out of the box.

One particular pessimal workload which some people run into involves build systems (or other functionality) which poll for updates by default, leading to increased CPU load by the hypervisor process. Many such systems which we have come across have an option to use inotify (i.e. event driven notification) instead of polling which works better all round (even on native Linux polling is wasteful, but its particular noticeable on d4m with volume mounts as CPU load).

This (identification of what components might be polling in your setup) is the likely reason for @dsheets's questions, there is IMO a good chance there will be a way to resolve your issue with a small configuration change to your containers. If not then it is still useful to identify the characteristics of your workload so they can be taken into consideration as the developers prioritise the ongoing performance work.

[samoht]

This issue has been inactive for more than 14 days while marked as status/0-more-info-needed. It is being closed due to abandonment. Please feel free to re-open with more information about the problem.

MORE_INFO_EXPIRY_TIMEOUT

[tnguyen14]

I am having this problem as well. Seems like this is now open in #1759

[davidkrcil]

After 5 months I have finally resolved this pain for me. I have used http://www.willnolan.com/cputhrottle/cputhrottle.html and run command: sudo ./cputhrottle 4634 50
My Mac is again my frined with no running fan.

[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