3 ms·

As far as I know, docker for mac isn't actually usable for dev work if you use mounted volumes. Basically it pegs CPU and makes disk access 10-150 times slower

As far as I know, docker for mac isn't actually usable for dev work if you use mounted volumes. Basically it pegs CPU and makes disk access 10-150 times slower than native which makes mounted volumes impossibly slow. A personal example would be building a jar on a macbook native took 11 seconds, takes docker for mac 9 minutes. See https://github.com/docker/for-mac/issues/77 https://github.com/docker/for-mac/issues/77 https://github.com/docker/for-mac/issues/668 https://github.com/docker/for-mac/issues/668 and a slew of other reports that can all be traced back mounted volume performance. Moral of the story I moved to linux.

cygned 9y ago
Using Docker for Clojure and JavaScript development here. I actually don't have these issues. There is a performance loss, sure, but not nearly as much as you describe it.
- ledgerdev 9y ago
  I would say just check out the threads for the sort of experiences people are reporting across pretty much every stack from rails to symphony. In my case above it was actually jvm clojure building an uberjar, probably worst case scenario. REPL was usable because it didn't do a any mounted volume access, just network access.
  - cygned 9y ago
    I noticed that lein-ring with autoreload is magnitudes slower. We now turn it off for microservices not being worked on. Anyway, I have read a lot about those problems and I hope it gets better at some point - especially for Docker on Windows, which is a pain in the neck for our developers (who now work with a Linux VM running Docker; ...)
silentOpen 9y ago
Many developer use cases do not demand heavy bind mount file access. For example, incremental builds of static languages typically work fine. docker/for-mac#77 is related to "bind mount" performance but docker/for-mac#668 is virtual block device performance. Have you posted a reproduction workload that demonstrates the performance problems you are having? Docker 17.04 includes a `cached` bind mount flag that relaxes consistency of the mount in exchange for significantly reducing guest-host roundtrips especially for inefficient workloads that repeatedly access the same files.
- edsrzf 9y ago
  Could you please link to some docs for the cached flag you mentioned? I can't find anything about it.
  - yallop 9y ago
    Documentation for 'cached' is on its way. There'll be a blog post up soon with a friendly introduction, and some representative benchmarks. In the meantime there's a drier but more detailed specification of the behaviour of 'cached' waiting in a pull request here: https://github.com/yallop/docker.github.io/blob/d9a57867/docker-for-mac/osxfs-caching.md
- lobster_johnson 9y ago
  We're seeing the same issue. We've been using shared folders with VMware for a long time, which are also slow (but not this slow). There's a case for keeping the Docker environment stateless and expendable (wipe to restart), and keep certain things (PostgreSQL databases, for example) on the host machine. Currently, that's impossible because of the aforementioned issue. I haven't tried the "cached" flag since it's still in beta, however.
bdcravens 9y ago
While not ideal, docker-sync has improved the file access issue substantially: http://docker-sync.io/ http://docker-sync.io/

cygned 9y ago

Using Docker for Clojure and JavaScript development here. I actually don't have these issues. There is a performance loss, sure, but not nearly as much as you describe it.

ledgerdev 9y ago
I would say just check out the threads for the sort of experiences people are reporting across pretty much every stack from rails to symphony. In my case above it was actually jvm clojure building an uberjar, probably worst case scenario. REPL was usable because it didn't do a any mounted volume access, just network access.
- cygned 9y ago
  I noticed that lein-ring with autoreload is magnitudes slower. We now turn it off for microservices not being worked on. Anyway, I have read a lot about those problems and I hope it gets better at some point - especially for Docker on Windows, which is a pain in the neck for our developers (who now work with a Linux VM running Docker; ...)

silentOpen 9y ago

Many developer use cases do not demand heavy bind mount file access. For example, incremental builds of static languages typically work fine. docker/for-mac#77 is related to "bind mount" performance but docker/for-mac#668 is virtual block device performance. Have you posted a reproduction workload that demonstrates the performance problems you are having? Docker 17.04 includes a `cached` bind mount flag that relaxes consistency of the mount in exchange for significantly reducing guest-host roundtrips especially for inefficient workloads that repeatedly access the same files.

edsrzf 9y ago
Could you please link to some docs for the cached flag you mentioned? I can't find anything about it.
- yallop 9y ago
  Documentation for 'cached' is on its way. There'll be a blog post up soon with a friendly introduction, and some representative benchmarks. In the meantime there's a drier but more detailed specification of the behaviour of 'cached' waiting in a pull request here: https://github.com/yallop/docker.github.io/blob/d9a57867/docker-for-mac/osxfs-caching.md
lobster_johnson 9y ago
We're seeing the same issue. We've been using shared folders with VMware for a long time, which are also slow (but not this slow). There's a case for keeping the Docker environment stateless and expendable (wipe to restart), and keep certain things (PostgreSQL databases, for example) on the host machine. Currently, that's impossible because of the aforementioned issue. I haven't tried the "cached" flag since it's still in beta, however.

bdcravens 9y ago

While not ideal, docker-sync has improved the file access issue substantially: http://docker-sync.io/ http://docker-sync.io/