Repository navigation
File access in mounted volumes extremely slow #77
Description
continued from https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/178
Expected behavior
File-system performance in the container not significantly slower than on the host or docker-machine.
Actual behavior
Running a composer (PHP) update in a container takes much longer than on the host. In the container we usually hit timeouts when updating huge git repos like twbs/bootstrap.
Information & Steps to reproduce the behavior
See link above
Activity
Vanuan commentedon Sep 4, 2016
Same for
npm install,bundle install,browserify, etc.cyb3rd4d commentedon Sep 5, 2016
Hi
Ok, that's why a Symfony application is very slow in a Docker container!
I load a page in ~ 150 ms when I'm running my local Symfony server (on my host) VS ~ 2000 ms when the config files have been serialized in the cache directory within a Docker container.
It seems the IO in the vendors and the cache / logs directories are very slow...
lfv89 commentedon Sep 6, 2016
Same here with rails and its friends (rails, rake, rspec...)
Please let me know what information I can provide to help you guys out.
mduller commentedon Sep 7, 2016
Same here as well. We're looking into using IntelliJ IDEA and git on the Mac and compiling & running our product in a container, from the shared filesystem. Development cycles are considerably longer and our devs not happy with the proposed switch. Currently evaluating workarounds to still enable the switch to Docker and in particular Docker for Mac.
wadjeroudi commentedon Sep 7, 2016
For those who look for a workaround and didn't read the whole thread, here is the solution :
https://github.com/EugenMayer/docker-sync
ZZromanZZ commentedon Sep 7, 2016
Same with PHP (Symfony, Nette, Composer deps...). I can confirm https://github.com/EugenMayer/docker-sync is usable workaround.
iwaffles commentedon Sep 8, 2016
We're experiencing this as well. We have our API dockerized and sometimes endpoints time out on our local machines (only in docker for mac). We're using Rails 5.
cyb3rd4d commentedon Sep 9, 2016
In my team, some developers use a Mac, others use Linux... Docker sync is not the solution for me because the project configuration will not be the same for all environments. I hope that the OSXFS issues will be fixed quickly.
wadjeroudi commentedon Sep 9, 2016
@MartialGeek Off topic : https://github.com/EugenMayer/docker-sync/wiki/Keep-you-docker-compose.yml-portable
But you should create a makefile to handle the environment properly.
cyb3rd4d commentedon Sep 9, 2016
@wadjeroudi Thank you, I will read that ASAP ;)
petergombos commentedon Sep 13, 2016
Same issue here, takes +30 sec to run my babel build using a mounted volume vs. 5 sec using container's fs.
jsamouh commentedon Sep 14, 2016
👍 Same issue with Git in docker, very slow ! Unusable compare to Docker Machine (with NFS)
Docker For Mac released too fast ! Need to be reviews !!!
jzahedieh commentedon Sep 14, 2016
Whole team is having issues with Magento, 3 minute page loads vs 8 seconds using docker-sync
191 remaining items
bilby91 commentedon Apr 28, 2017
Is there any solution for mac that haves a decent speed ? Running docker in vagrant solves the write speed issue ?
andrerom commentedon Apr 29, 2017
@sanbor @bilby91 As found earlier up in this thread, there are two main choices if :cached does not solve it for you:
ianks commentedon May 3, 2017
Why does the docker for mac engine not just mount NFS?
aimakun commentedon May 3, 2017
@ianks There are several reasons for not using NFS. The issue is current one Docker for Mac using still have own problems. Give the team more time to solve that.
As @andrerom mentioned above, you still can use workarounds. I'm still using docker/toolbox and it's working fine.
Even Docker for Windows has long way to go, currently it still only available on Windows 10 pro.
lox commentedon May 3, 2017
Could mods close this thread to prevent more comments like @ianks? Lots of us want to keep tabs on updates on the issue and the sheer volume of "use nfs or docker-sync" comments makes that very annoying.
luckydonald commentedon May 3, 2017
@lox, You shouldn't kill discussion however.
Don't be so grumpy 😃
ianks commentedon May 4, 2017
@lox It was a question, not a statement.
lox commentedon May 4, 2017
Search on this page for NFS @ianks. If that doesn't clarify your question, we can provide more detail.
EugenMayer commentedon May 4, 2017
To add something for the discussion, i made some benchmarks with :cached and the newest edge release today https://github.com/EugenMayer/docker-sync/wiki/Performance-Tests-2017
In the end, :cached will not really help with 17s, thats even far below the fusion based shares with 12s, not to mention when you compare it with native_osxm which has only 0.20s, near hte native speed with 0.19s.
we are talking about :cached beeing 50x slower then a native docker container or alternatives
lephuongbg commentedon May 4, 2017
@EugenMayer,
:cachedis used for improving read speed, and you're testing write speed. You will have to wait for:delegatefor that benchmark.Vanuan commentedon May 5, 2017
Looks like cached/delegated wouldn't solve the issue. People wouldn't know when to apply what.
EugenMayer commentedon May 5, 2017
For sure it would not, and not even because this implicates, that the container has the superior over the host - which is right the opposite what you need when you actually develop. The container will hardly ever surprise you with something "new interesting" - and if anything, its generated and reproducible.
Very very different for code changes, which are not reproducible and very hard to write again ( mentally alone ). Thats why docker-sync uses always "hosts wins" while still using the buffer. Losing code is just not funny - losing generated assets (in case it ever happens to be a conflict) is a no care.
so :delegate is just something you do never want to touch - even if i do get the general idea.
yallop commentedon May 5, 2017
Subscribers to this issue might be interested to read the following blog post:
User-guided caching in Docker for Mac
which explains how and when to use
cached, along with some details about the implementation.Since there are now significant improvements in the use cases that prompted this issue, we're closing the issue to further conversation. We'll continue to post occasional updates here when further performance improvements are available. There's a new, more focused issue open to track the progress of the caching implementation (i.e. the implementation of
delegated, and further improvements tocached):File system performance improvements
If you'd like to follow developments closely, we recommend subscribing there. Thanks to everyone for contributing to this conversation!