Docker Community Forums

Share and learn in the Docker community.

Com.docker.hyperkit up CPU to 340%

Looks like this problem is related to inotify.

I use docker for developing apps with Playframework (https://www.playframework.com). When I use ‘~compile’ which automatically compiles code on every file change, the cpu usage for hyperkit shoots up to 200% even when the process is idle. i.e. no compilation is going on and waiting for file changes.

When I do the same without docker, cpu load never goes up when idly listening for file changes.

Hello,

It sounds like Play may not be using inotify. Could you supply a reproduction which allows us to test your base image use? Just a simple image/Dockerfile that we could docker run in order to see this ~compile behavior would be very appreciated.

Thanks,

David

Here is the image containing ‘activator’ which can be used to reproduce the scenario.

naumanbadar/activator-runner

Note that its a humungous image of size ~3G because I copied all the sbt/ivy2 dependencies to reduce the startup time in addition to it having base image of java:8-jdk.

Anyway to reproduce the scenario, first you will have to create a project on local director using the container. cd into a temp directory somewhere on your machine and execute the following command:

docker run --rm -v $(pwd):/project naumanbadar/activator-runner activator new TestPlay play-scala

This will create a project directory called TestPlay in your pwd. Next you start the compile process which will recompile the project on any file change with the following command:

docker run --rm -it -v $(pwd)/TestPlay:/project naumanbadar/activator-runner activator ~compile

After it finishes compiling for the first time, it will wait for source changes to trigger compilation again.

Now if you open any source file e.g. TestPlay/app/controllers/HomeController.scala in your editor of choice on your machine and edit and save it, the compilation process will kick in.

Now this automatic compilation would not start with docker+vmware but it does start with Docker for Mac apparently due to inotify.

Now if you leave the process running without changing any files, in case of

  • running natively without docker java process goes down to ~4% cpu load

  • running with docker, cpu load stays around 50% for hyperkit and around 25% for osxfs

Note that previously I said that cpu for hyperkit is around 200% but I noticed that if I leave the process idle meaning without changing any files for around 3 minutes, it goes down to 50% as stated above.

Hello David,

Here the compiler has been sitting idle for last half hour but my mac feels like a hair drier with fan speed going crazy high. :slight_smile:

Also has the highest energy impact of ~180.

Please also note that only if I disable automatic compilation and do it manually every time after changing sources, then the cpu load stays low, almost close to as running it natively without container.

Hope it helps.

Same thing here, 340% CPU utilization.
And that is just with the Docker app running in the toolbar in the background - not running any containers or doing any active development.

Mine is sticking to 100%, and my docker isn’t even running :wink: nope, i’m not kidding here… might be just me

however:

➜ ~ docker info
Cannot connect to the Docker daemon. Is the docker daemon running on this host?
➜ ~ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS

➜ ~

In an attempt to provide as much info as possible, with probably things that really don’t matter but…
closed app using cmd-q
yet still activity monitor still shows it…
problem might have started right after coming out of sleep… think i noticed it about 10minutes after lunchbreak. (so 10 mins after sleep)
docker is still set to start on boot, so it did actually run before the quit, however, never started a single container since my last reboot… haven’t touched docker in over a month…

reopening docker app, makes my activity monitor show this:

then closing it again (can’t show screen because new users can only add 1 image)

keeps the original (same PID) 100% ‘com.docker.hyperkit’ open and a ‘com.docker.vmnetd’ and yes cpu still spiking for 100%
Hope this helps resolving the issue or might give anyone else a hint to finding the problem

Can’t wait to get back to docker, as i do miss it :slight_smile:

I have this issue as well. Any container with Grunt watching mounted files will cause the CPU to run amok. I suspect it’s related to the fact that the files are being watched by both Grunt and Docker, concurrently.

+1, also seeing this

It also happens after a clean restart and no interaction with docker during my session. Usually about 30 minutes into the session.

+1, same here. I have experienced this with docker-machine as well as docker for mac. My MBP is running hot.

+1. Same here. macOS Sierra 10.12

Same here for mocha watch mode. I’m on Docker stable 1.12.1 (build: 12133). So I guess it’s not fixed in the current beta?

Any resolution/workaround for this issue? I’m facing this as well

I was excited to build some helper tools to setup and using docker for development, but facing this same issue here as well.

It’s really frustrating because docker for mac is effectively un-usable for development work(it’s primary use case), and apparently has been in this state for 7 months? Has there been any communication from docker on a plan to address?

+1

Sierra, 1.12.x

Bring up a node 7 express container and CPU hits 400% and stays there.

I got the same, 334% CUP for docker.hyperkit.

Is there any news about this?
I am with the latest version [Version 1.13.0-rc4-beta34 (14840)] and still having the issue :confused:

I have also found this issue to be related (at least for me) to be related to watching based systems. For Golang projects when using the Goat build tool the hyperkit and OXFS processes use a ton of CPU (200%+). Since switching to CompileDaemon I have no issues with high CPU issues. It seems the core difference between the 2 packages is one is built to poll the file system and one is using various mechanisms for detecting changes (inotify, polling etc).

As a side note I also had similar issues with the Meteor build process running in a container (more recent versions seem to have heavily decreased the CPU usage). Hope these notes helps with your research into this problem.

I think I will probably have to go back to docker-machine too (sadface).

Been dealing with this every day for almost 3 months and I’ve just gotten too annoyed by it for it to be worth it. Still an awesome piece of software when my CPU doesn’t start flying!

Oh guys i have for all few solutions shortly i will close this topic bcs it little kill me

First solutions:
Using beta version don’t look on it like on beta just try