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' process has a very high CPU utilisation #1131

Closed
ghost opened this Issue Jan 12, 2017 · 5 comments

Comments

Projects
None yet
6 participants
@ghost

ghost commented Jan 12, 2017

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

This comment has been minimized.

Contributor

dsheets commented Jan 16, 2017

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

This comment has been minimized.

mikeball commented Jan 19, 2017

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

This comment has been minimized.

Contributor

ijc commented Jan 19, 2017

@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 comment has been minimized.

Contributor

samoht commented Feb 2, 2017

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

@samoht samoht closed this Feb 2, 2017

@tnguyen14

This comment has been minimized.

tnguyen14 commented Oct 27, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment