Hacker News Reader

Comment by bryanh | Hacker News Reader

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.

View on HN

[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.

Thanks for the reassurance - I figured this was the case!

> In particular, we have implemented a new "osxfs" ...

Are we going to see these changes rolled back upstream in xhyve?

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

It does fix those issues.

(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.

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".

> 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.

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.

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

It does not use /etc/exports. We do not change any generic OSX config.

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?

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.

Reply on news.ycombinator.com