Skip to content
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

High CPU when using file watchers and volumes #4386

Closed
2 tasks done
JeremyLoy opened this issue Mar 24, 2020 · 2 comments
Closed
2 tasks done

High CPU when using file watchers and volumes #4386

JeremyLoy opened this issue Mar 24, 2020 · 2 comments

Comments

@JeremyLoy
Copy link

JeremyLoy commented Mar 24, 2020

  • I have tried with the latest version of my channel (Stable or Edge)
  • I have uploaded Diagnostics
  • Diagnostics ID: D698072B-2E0F-4BCB-8A21-D38157DCE455/20200324012814

Expected behavior

CPU usage is identical, or moderately higher when running in a docker container

Actual behavior

CPU usage is several orders of magnitude higher

Information

My project (A small, ~8 endpoint express app) uses typescript compiler file watching (tsc --watch) and nodemon for local development.

The combination of these two processes running outside of docker, on MacOS, uses approximately 5% of one CPU core when idle, 25% cpu of one core when compiling/reloading, and finishes in approximately 2 seconds.

We've been experimenting with developing inside of Docker, as an alternative to using Node Version Manager and juggling multiple projects with different node versions.

Here is the example script we have been running:

yarnWatch.sh

#!/bin/sh

tsc --watch
nodemon app.js
docker run \
  --volume $(pwd):/proj \
  --workdir /proj \
  --rm \
  --publish 3030:3030 \
  --detach \
  node:12.16.1-alpine scripts/yarnWatch.sh

When running in this way, the hyperkit process idles at 200% CPU (my guess is 100% of two cores), uses 500%cpu when compiling/relaoding, and finishes in 20 seconds.

My hypothesis is this is some sort of bottleneck regarding volumes, as running the app in a custom built image has no performance problems.

I also opened the issue moby/hyperkit#279

@docker-robott
Copy link
Collaborator

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@docker-robott
Copy link
Collaborator

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

@docker docker locked and limited conversation to collaborators Aug 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants