Docker Community Forums

Share and learn in the Docker community.

File access in mounted volumes extremely slow, CPU bound


(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


(Fulcrum) #277

Please note that with the latest release of Docker for Mac 17.12.0-ce-mac46, that d4m-nfs is broken and it is TBD if it can be fixed or should be retired - https://github.com/IFSight/d4m-nfs/issues/55


(Sebastian Tschan) #278

We’re using a similar approach to improve filesystem performance as @eugenmayer’s docker-sync, by using lsyncd to sync host mounts with named container volumes:

It’s only one-way sync, but it does not require any additional tools and only one additional Docker container to run any number of host mount to named volume setups.

The Dockerfile itself is super small and the overall setup very simple, so it does not add much complexity, while providing a lot of flexibility thanks to lsyncd's configurability.

I thought I’ll post it here if someone else if looking for a similar, simple solution.


(Eugenmayer) #279

docker-sync native_osx does not need anything on the host… that is all gone.

The problem with everything you put on rsync alikes, as lsyncd, is the file watcher - and that is what you will face. Its the huge CPU hog which will happen on any fswatch implementation on OSX, no matter its HFS+ or APFS - so what you did, we already went through and have with the rsync strategie (included in docker-sync).
But its very resource hungry and gets worse as longer is runs. It also will lose FS events if you branch change and things like that.

You can believe me, that solution is by no means different then rsync, unison local (unison-filewatcher) and probably every OSX native sync solution out there - detecting FS changes - thats the actual PITA. Syncing is super easy with every of those tools.


(Sebastian Tschan) #280

Thanks for your reply.
It was not my intention to declare our solution as superior or largely different, simply to propose a simple alternative setup.

I’m also by no means a file system events expert and believe that you’ve spent a lot of time in investigating the alternatives.

I’m aware of https://github.com/EugenMayer/docker-sync/issues/410 and understand that this issue affects anyone relying on osxfs file system events, like our setup does.

At least so far, the CPU/Memory usage of a single lsyncd container seems to be relatively low.
Anyway, that’s not due to our efforts but thanks to the creator of lsyncd.


(Eugenmayer) #281

ah, now i see - you are using a host-mount and the use file-system watcher on top of OSXFS.
Well yes, then you basically will run into the same issues like https://github.com/EugenMayer/docker-sync/issues/517 or the one you mentioned https://github.com/EugenMayer/docker-sync/issues/410

Since the issues are from host to container, you are affected in your strategy, since that is the only direction you sync.

lsyncd could be more effective or less effective then unison, i do not know. It could be a addition to docker-sync since the current rsync strategy uses fswatch on the host, does not use host-mounts at all - but thats actually the significant difference to native_osx and thus, for some people could work better.

lsyncd could just be “faster” but it will not be more reliable to the facts above - and yet rather few people did go after the speed of sync in those cases. Its rather docker-for-mac stopping FS events https://github.com/docker/for-mac/issues/2417

Whatever suits you - i am just hunting a “good solution” and wanted to point out, yours is not different to what we have seen so far and will struggle with exact the same symptoms ;/ Bad news for us all.


(Sebastian Tschan) #282

Yeah I agree that there’s no ideal solution yet.
I also hope that the Docker for Mac issue you linked to gets fixed and have added my thumbs up. :slight_smile: :+1:


(Tanc) #284

Has anyone tried NFS mounts recently? In the latest stable release notes it says:

“Support NFS Volume sharing.”

I’ve not found any documentation and the only thread I’ve found about this is: NFS Native Support