4 ms·

I've noticed some pretty extreme performance penalties with Docker for Mac. Wherein VirtualBox would spin <60% CPU idling a bunch of services (MySQL, RabbitMQ,

by bryanh 10y ago

I've noticed some pretty extreme performance penalties with Docker for Mac. Wherein VirtualBox would spin <60% CPU idling a bunch of services (MySQL, RabbitMQ, Redis, Elasticsearch, Memcached, several Python daemons) - Docker for Mac's driver hovers around 100% (spiking often to 200/300%) with another 20-30% (spiking to 50-80%) on the osxfs. I'm going to guess it'll get better in time. It would be nice to get some insight into just what is burning CPU cycles. The experience besides that was really top notch IMO.

avsm 10y ago
[I work on Docker for Mac] The early betas focussed on feature completeness rather than performance for filesystem sharing. In particular, we have implemented a new "osxfs" that implements bidirectional translation between Linux and OSX filesystems, including inotify/FSEvents and uid/guid mapping between the host and the container. Getting the semantics right took a while, and all the recent betas have been steadily gaining in performance as we implement more optimisations in the data paths. If you do spot any pathological "spinning cases" where a particular container operation appears to spiking the CPU more than it should be in, we'd like to know about it so we can fix it. Reproducible Dockerfiles on the Hub are particularly appreciated so that we can add them to the regression tests.
- bryanh 10y ago
  Thanks for the reassurance - I figured this was the case!
- cstrahan 10y ago
  > In particular, we have implemented a new "osxfs" ... Are we going to see these changes rolled back upstream in xhyve?
- chamoda 10y ago
  Previously I had permission issues (Only root can write to host) when mounted a folder with OSX filesystem. Hope this would fix those issues. I'm talking about this issue https://github.com/boot2docker/boot2docker/issues/581 https://github.com/boot2docker/boot2docker/issues/581
  - bryanh 10y ago
    It does fix those issues.
girvo 10y ago
Oh, really? I've been running boot2docker-xhyve for months now, and performance-wise it's been far better than VirtualBox. I wonder if its a quirk of how Docker for Mac is set up?
kawera 10y ago
This is a known issue and they are investigating. For now, when it spikes to 200%+, the only solution is to restart the whole thing.
djs55 10y ago
(I work for Docker on Docker for Mac) Our approach is to focus on functionality and correctness first, and then improve performance over time. We're building up a suite of performance benchmarks to help us track progress-- are there particular benchmarks that you would recommend we add? I'll certainly add "CPU load while idling" to the list.
- bryanh 10y ago
  Maybe something like a Django, Rails, etc. DEBUG=True dev server - they tend to poll for file changes which could really tax your osxfs implementation at "idle".
- molecule 10y ago
  > Our approach is to focus on functionality and correctness first, and then improve performance over time. Just my two cents: I think that the interface and features are excellent and a joy to use, but performance was a show-stopper that forced me to quit using the Beta for Rails-application development: - a simple request that took ~1/3 of a second using VirtualBox and Docker Machine took six seconds on Docker for Mac - a more complex request went from one second to twelve seconds I didn't have a chance to dig into it, but I would guess that it has something to do w/ osxfs and the many files that Rails loads, as it reminded me of the difference between using sharing files via VirtualBox's own file sharing vs. NFS, the latter being a significant improvement.
  - ddollar 10y ago
    I've noticed this as well. It seems like the docker.local hostname can sometimes take a long time to resolve. If I resolve that hostname and visit the IP directly it generally works great. Definitely check out the beta forums as most of the issues I've found have already been reported with workarounds.
- pstadler 10y ago
  I'm wondering how Docker for Mac handles conflicting entries in /etc/exports. This is currently still a problem when using dlite and vagrant on the same host[1]. [1] https://github.com/nlf/dlite/issues/176 https://github.com/nlf/dlite/issues/176

by bryanh 10y ago

avsm 10y ago

[I work on Docker for Mac] The early betas focussed on feature completeness rather than performance for filesystem sharing. In particular, we have implemented a new "osxfs" that implements bidirectional translation between Linux and OSX filesystems, including inotify/FSEvents and uid/guid mapping between the host and the container. Getting the semantics right took a while, and all the recent betas have been steadily gaining in performance as we implement more optimisations in the data paths. If you do spot any pathological "spinning cases" where a particular container operation appears to spiking the CPU more than it should be in, we'd like to know about it so we can fix it. Reproducible Dockerfiles on the Hub are particularly appreciated so that we can add them to the regression tests.

bryanh 10y ago
Thanks for the reassurance - I figured this was the case!
cstrahan 10y ago
> In particular, we have implemented a new "osxfs" ... Are we going to see these changes rolled back upstream in xhyve?
chamoda 10y ago
Previously I had permission issues (Only root can write to host) when mounted a folder with OSX filesystem. Hope this would fix those issues. I'm talking about this issue https://github.com/boot2docker/boot2docker/issues/581 https://github.com/boot2docker/boot2docker/issues/581
- bryanh 10y ago
  It does fix those issues.

girvo 10y ago

Oh, really? I've been running boot2docker-xhyve for months now, and performance-wise it's been far better than VirtualBox. I wonder if its a quirk of how Docker for Mac is set up?

kawera 10y ago

This is a known issue and they are investigating. For now, when it spikes to 200%+, the only solution is to restart the whole thing.

djs55 10y ago

(I work for Docker on Docker for Mac) Our approach is to focus on functionality and correctness first, and then improve performance over time. We're building up a suite of performance benchmarks to help us track progress-- are there particular benchmarks that you would recommend we add? I'll certainly add "CPU load while idling" to the list.

bryanh 10y ago
Maybe something like a Django, Rails, etc. DEBUG=True dev server - they tend to poll for file changes which could really tax your osxfs implementation at "idle".
molecule 10y ago
> Our approach is to focus on functionality and correctness first, and then improve performance over time. Just my two cents: I think that the interface and features are excellent and a joy to use, but performance was a show-stopper that forced me to quit using the Beta for Rails-application development: - a simple request that took ~1/3 of a second using VirtualBox and Docker Machine took six seconds on Docker for Mac - a more complex request went from one second to twelve seconds I didn't have a chance to dig into it, but I would guess that it has something to do w/ osxfs and the many files that Rails loads, as it reminded me of the difference between using sharing files via VirtualBox's own file sharing vs. NFS, the latter being a significant improvement.
- ddollar 10y ago
  I've noticed this as well. It seems like the docker.local hostname can sometimes take a long time to resolve. If I resolve that hostname and visit the IP directly it generally works great. Definitely check out the beta forums as most of the issues I've found have already been reported with workarounds.
pstadler 10y ago
I'm wondering how Docker for Mac handles conflicting entries in /etc/exports. This is currently still a problem when using dlite and vagrant on the same host[1]. [1] https://github.com/nlf/dlite/issues/176 https://github.com/nlf/dlite/issues/176