File access in mounted volumes extremely slow, CPU bound

I too tried out @stephank’s docker-for-mac-nfs yesterday and ran into some initial problems (because I think I did something wrong at first, not because there was a problem with his instructions), but I was able to debug and solve my problems by logging in directly to the docker host VM and poking around there. @stephank’s blog post ( and the other blog post he linked from there ( were very helpful for me.

I haven’t done extensive testing yet, but I can verify that docker-for-mac-nfs is working well for me in that it was pretty easy to set up, it is in fact working (I can view and modify shared files), and the performance is not as abysmal as it is with osxfs. I’m not sure how close the performance is to native, but for my purposes it doesn’t matter all that much.

Thank you very much, @stephank for this great, well documented solution! (Though hopefully it is only temporary until Docker for Mac is finally fixed for real. =P)

1 Like

@jonathak NFS is about 3-5 times slower then native speed, that is why is not using NFS at all - a proper sync is used. One other problem with NFS is the permission issue (uid/gid)

@barat Using a sync solution ( 2 way ) like unison, docker-sync provides native performance, so as there would be no share at all. You will be back to ~1s on page load with it

This makes a difference esp. with a lot of PHP based projects, since NFS becomes even worse with reading a lot of smaller files, which PHP frameworks like Symfony or Drupal tend to have ( out of the PHP DNA).
It also seem to have a big impact on bigger Java-Frameworks, when compiling happens.
Also projects with a huge NPM dependency tree (which gets this way very fast…) tend to be very slow with NFS. It seems like NFS degrades very fast with the number of files.

I do not understand why people really wait for a solution in docker for mac. Folder-Sharing performance is a huge topic, neither Oracle nor VMware are able to cope with it on a level, where it would by any means suite development.
That said, are you really believing Docker can at any level compete with a company which involves experts on paravirtualization ONLY?
The reasons why things gone silent here is, because Docker already knows, they will not be able to get anything big happen in this. They are not able to provide 1/50 of the ressources VMware dedicates to their solution like Fusion.

I see myself, there are a lot of suggestions in my writing, but lets say, there are some facts and odds to cover this one up.

That said, people stop complaining here again and again. Either pick a different solution then d4m, pick a workarround like a NFS based one or a docker-sync like, or move to linux.

1 Like

Your right. The only solution is for apple to implement namespaces and cgroups in kernel like linux does. They should be working with apple, not wasting resources on a lost cause.

In other words docker for mac is completely unable for it’s primary use case :confused: Docker you make me laugh and cry.

Does docker on windows suffer from the same problems?

In the meantime, for the millions of developers with mac laptops that can’t immediately switch over to linux laptop, and want to use containers for local development environment to build java/node/ruby/php apps. What’s the current best option?

Linux in a virtualbox vm?


I completely agree, I’ve ran into the same performance issue with VirtualBox using NFS with Drupal projects (switched to rsync, then switched again to a plugin called gatling-rsync-auto – for performance reasons).

I would like to see D4M include a de-facto solution (docker-sync seems like the best option to me) so that end users aren’t forced to spend countless hours researching to come to the same conclusion.


I gnashed my teeth for about 24 hours on this problem before coming to a simple solution for my case: simply don’t sync when not necessary. I’m sure this doesn’t work for everyone – but in case your issue is analogous:

I set up a development environment including traefik, ember-cli and some data services. Ember-cli has the package directory mounted and uses ember serve to serve. It takes 8-10 times longer set up this way. However, mounting the ./tmp and ./dist subdirectories as tmpfs volumes gives me almost all the time back.

    build: "$PWD/services/crane-wisdom"
    image: "cws/wisdom"
      - $PWD/services/crane-wisdom/crane-wisdom:/home/docker/app
      - $PWD/services/crane-wisdom/crane-wisdom/docker_node_modules:/home/docker/app/node_modules
      - web_temp:/home/docker/app/tmp
      - web_dist:/home/docker/app/dist
      - server
    command: [
      "ember", "serve", "--proxy", "http://server:16006",
      "-lr", "false" ]
      - server
      - traefik.port=4200
      - traefik.frontend.rule=Host:localhost

# create temporary volumes for ember-cli compile to avoid
# slow sync back to host
      type: tmpfs
      device: tmpfs
      type: tmpfs
      device: tmpfs

Sorry Docker, I give up on you


I like to mention that there is still the docker-toolbox which does not experience these performance issues. I use it for some php projects and the loading times are 5 to 10 times faster using virtualbox and even faster using vmware fusion.

nemo64 of course it does, its a share though vbox, considered to be ultra slow with bigger projects, see in the lower section. vbox nativ with toolbox is usually far worse then docker for mac is, so its by no means better.

1 Like

But it is. I used boot2docker a year ago and i can confirm that is was so slow that i used nfs instead. But the newer virtualbox versions have better shared folders which in my experience are on the same level as nfs shares. As I said, I have symfony and typo3 projects running with docker on a mac. I tested a typo3 project with 5200 php files and cache disabled (although still not all are used for a request).

This is the an apache benchmark result for a page with docker for mac:

Percentage of the requests served within a certain time (ms)
  50%   2029
  66%   2130
  75%   2223
  80%   2292
  90%   2474
  95%   2593
  98%   2699
  99%   2735
 100%   2735 (longest request)

This is the same request with the same benchmark and the same configuration but using docker-toolbox:

Percentage of the requests served within a certain time (ms)
  50%    561
  66%    584
  75%    613
  80%    621
  90%    691
  95%    737
  98%    796
  99%    880
  100%    880 (longest request)

I don’t have php 7 natively installed and I can’t easily reproduce this environment natively… I could try to start docker completely within a linux vm but I think my point is already clear. I would try the docker-toolbox.

EDIT: I thought I add some information: I used docker for mac Version 1.13.1-rc1-beta40 and docker-toolbox with the vmware fusion driver.

I agree. In fact I think they should pull Docker For Mac permanently until they can get a fix for this. It’s a fools errand to try to develop on mac with this tool. Why devote all the effort to this is other areas when this Achilles heel will bring down the entire project in terms of usefulness for development.

Well, this thing is irritating - true, but I don’t think that it makes Docker for Mac useless.
Actually I use docker-compose + docker-sync in a project where other team members are Linux users and it’s not that bad.
I even wrote an article about how some things may be tweeked (thanks to this thread and few more on github)
If You can live with few small quirks then Docker for Mac is pretty usable… for eg Java guys in my company are happy with 1.13 :slight_smile:

1 Like

I have to agree. Can be better, yes… but already really useful… yes. I use for all Drupal 7/8 sites with a my own custom UNISON container approach to managing this particular issue, and have no other issues. I’m looking forward to this being resolved, but doesn’t actually get in the way of any development work.

It still works fine if you aren’t sharing a large number of files in a volume. But for example, our test suite takes 20x as long running in docker vs not so people no longer run tests in docker for development.

I am concerned Docker has gone completely silent on this. I would like to know if this issue is being actively worked? I’m guessing not or we’d have gotten a recent update.

Any official update from a member of the Docker for Mac team would be great. There’s info in the docs specifically about this issue (, but I don’t think it has been updated for several months.

There’s an update about our future plans for osxfs performance on the issue tracker:


Hi everyone. A few months ago I encounter NFS limitation when I need to restore a database file with size more than 300MB. NFS simply time out when in use. So, I switched to use docker-sync instead. For the databases, I use named volumes and only pull the files out as a backup rather than mounting the data folder using NFS / osxfs / vboxsf. So, now I don’t use NFS or any shared folder anymore. The development synced to named volumes using unison wrapped by the docker-sync gem.

For those who struggle with the slowness of the available shared folder, try docker-sync and see if it help you in your work with docker.

Hey, I have used D4M for months now for Symfony and eZ Platform projects. I looking forward to testing the new :cached option or Docker when released. I don’t really like docker-sync as it duplicates everything… but anyway, why would you use NFS for your database? I have used D4M with DB bigger than that. But my database does not mount anything from the host.

To me, D4M should be used only to share the code between the container and the host for development purposes and that is it. I am also sharing the cache for PhpStorm plugins and some configuration files.

But other than that everything else should be in the container (no mount on the host) and then the perfs are native.

Was just a little feedback :slight_smile:

May the 4th be with you.

With todays release of docker-sync 0.4.0 we probably have a promising final solution.
Since the new :cached mode wont be to effective ( see ) we will need a external solution anyway - :cached is still 50 times slower then native.

The biggest concerns using docker-sync were host-dependencies - and that has been removed - there are no host dependencies any longer - just a gem on your system ruby. No brew, unison or unox.

In addition to that, no filewatchers are used anymore, so no crazy CPU usage. OSXFS is used in a away that the OSX->sync-container sync is done using the low level implementation of OSXFS, but the mount into your app container is done using a live-copy - that gives you native performance while having a 2-way sync without hazzles.

Just try it yourself and check the performance table

Have a try, would be happy to have some feedback on this.

1 Like

Tried every option and landed with this one. Making use of docker-sync (currently using 0.4.6) is by far the fastest solution. The real difference is noticeable especially with PHP applications. Would really like to see that the Docker team looks into integration this the Docker core somehow :slight_smile: