Performance issue when using shared folders, vbox guest additions, and node's `forever --watch` or `nodemon` on running image. #631

johnpancoast opened this Issue Nov 16, 2014 · 9 comments


None yet

4 participants


Docker noob here.

When developing node apps it seems common to use forever --watch or nodemon to watch for changes in particular directories and restart node when it finds changes. This speeds up development.

When I use either forever or nodemon as my CMD to start my node app forever --watch app.js, CPU for VBoxHeadless goes to 250%. This only happens when I use these tools and docker. Starting my app without them node app.js works fine. Using forever or nodemon on my host machine works fine.

The problem exists with both forever and nodemon so I suspect it's not them and something related to boot2docker, docker, or the share but I'm really not sure. I've seen a ton of posts related to this but I'm not sure if I'm missing something or not.

Can you shed some light on if this is a known bug/limitation and if there are workarounds?

@johnpancoast johnpancoast changed the title from Performance issue when using shared folders and node's `forever --watch` or `nodemon` on running image. to Performance issue when using shared folders, vbox guest additions, and node's `forever --watch` or `nodemon` on running image. Nov 16, 2014

Likely also related to #593


EDIT: After looking into this, the same problem exists when using either the samba share or vbox guest additions methods suggested below. Both raise VboxHeadless CPU to >200%.

Following the first suggestion here seemed to be better for me.

I'll check it out more soon to verify that works.


It's specifically grunt watch that's the issue in my case. Still thinking it's some kind of perf issue related to the share.

tianon commented Nov 26, 2014

That sounds like it's likely related to vboxsf.


If I understand correctly, grunt watch uses inotify to check for changes, but vboxsf doesn't support this ( So possibly grunt will have to scan all files to check for modifications?


Interesting. Thanks. I've noticed after some reading that this is a known (and commonly understood) limitation of vboxsf.

Are there workarounds, other options, or potential features/fixes on your side related to this?


I think it's best to search in the other issues about this topic. Depending on your situation, there may be some workarounds, but not sure.

In my personal setup (but this is beyond the scope of boot2docker), I don't use a shared folder, but have a SSHD helper-container and let my IDE sync changes to the container over SSH. The downside of course is having the source in two locations, but performance-wise it just works a lot better.


@shideon I faced the exact same problem so started comparing all options (nodemon, forever, grunt). For me grunt-develop with livereload works like a charm. Maybe that can help.

@thaJeztah thaJeztah referenced this issue in boot2docker/boot2docker-cli Dec 25, 2014

Seems to be very slow for volumes with many (>= 10k) files #329


@kimpellikaan thanks! I'll check it out.

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