Docker Community Forums

Share and learn in the Docker community.

File access in mounted volumes extremely slow, CPU bound


(Eugenmayer) #256

@jonathak NFS is about 3-5 times slower then native speed, that is why http://docker-sync.io 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.


(Sandrodz) #257

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.


(Mikeball) #258

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?


(Codycraven) #259

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.


(Shaunc) #260

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.

services:
  web:
    build: "$PWD/services/crane-wisdom"
    image: "cws/wisdom"
    volumes:
      - $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
    links:
      - server
    command: [
      "ember", "serve", "--proxy", "http://server:16006",
      "-lr", "false" ]
    depends_on:
      - server
    labels:
      - traefik.port=4200
      - traefik.frontend.rule=Host:localhost

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

(Ibxl) #261

Sorry Docker, I give up on you


(Nemo64) #262

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.


(Eugenmayer) #263

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


(Nemo64) #264

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.


(Rscott564) #265

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.


(Barat) #266

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) http://espeo.eu/blog/docker-for-mac-performance-tweaks/
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:


(Joe Mewes) #267

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.


(phil swenson) #268

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.


(Joe Mewes) #269

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 (https://docs.docker.com/docker-for-mac/osxfs/#performance-issues-solutions-and-roadmap), but I don’t think it has been updated for several months.


(Yallop) #270

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


(Donnykurnia) #271

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.


(Sébastien Morel) #272

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.


(Eugenmayer) #273

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 https://github.com/EugenMayer/docker-sync/wiki/4.-Performance ) 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 https://github.com/EugenMayer/docker-sync/wiki/4.-Performance

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


(Frankwaanders) #274

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:


(Blasterpal) #276

NOTE: This is a duplicate of https://github.com/docker/for-mac/issues/2141#issuecomment-337323903
but adding here if needed.

This issue has started for me in the last day for no apparent reason. I did
update to the latest Docker this week but problems did not occur directly
afterward. Still happens after fresh shut down and start (mostly).

Version 17.09.0-ce-mac35 (19611) Channel: stable a98b7c1b7c

macOS 10.12.6 (16G29)

I have a strong feeling that it is related to mounted volumes, but I’ve not been able to prove 100%.

UPDATE: I created an A/B test to replicate using a repo with README:

This includes full information as request here: https://docs.docker.com/docker-for-mac/osxfs/#performance-issues-solutions-and-roadmap
in section “WHAT YOU CAN DO”

My results using these benchmarks:

Bundled and app copied Docker image:

docker run --rm -it $DOCKER_REPO/derailed /bin/bash -l -c "time bundle exec rails r 'Rails.env'"

real    0m1.587s
user    0m1.270s
sys     0m0.260s

Base Ruby image, mounting app:

docker run --rm -it -w /derailed -v $(pwd):/derailed $DOCKER_REPO/derailed-dev /bin/bash -l -c "export BUNDLE_PATH=vendor/bundle-docker && bundle exec rake db:schema:load && time bundle exec rails r 'Rails.env'"

real    0m36.485s
user    0m2.100s
sys     0m2.220s

UPDATE2: I executed Docker Performance Testbench

Results:

delegated: drush site install 3x

136 seconds
135 seconds
130 seconds

delegated: drush cr 3x

18 seconds
16 seconds
17 seconds

cached: drush site install 3x

133 seconds
131 seconds
129 seconds

cached: drush cr 3x

17 seconds
17 seconds
17 seconds

consistent: drush site install 3x

156 seconds
151 seconds
147 seconds

consistent: drush cr 3x

20 seconds
21 seconds
20 seconds