Hacker News Reader

Comment by aledalgrande | Hacker News Reader

These are real problems with docker, but do we wanna talk about docker for Mac? A total performance disaster.

https://github.com/docker/for-mac/issues?q=is%3Aissue+is%3Ao...

I have no idea how, but Docker for Mac was taking up a whopping 65GB of space in one of the cache folders in ~/Library, although I had uninstalled it months ago. I wish I had taken a screenshot, but I was honestly dumbfounded. I had used it maybe once, ever.

EDIT: It turns out I’m not making this up/an edge case, at least 940 people have run into this too: https://github.com/docker/for-mac/issues/371

I have that problem too. Solution seemed to be to set up an alias to clean out old images, volumes, etc and run that every so often

Not just in MacOS. Over time, Docker can eat all your storage.

Because it keeps around all of the images you use as well as the containers after they are stopped so you can resume them. there is a command that auto automatically removes all unused images and containers you can use.

True. But there are situations where things get ~corrupted, and it becomes ~impossible to recover without basically nuking everything. But then, I was running containers with resource limits and long-term storage. So I could have thousands of lightweight "VMs" per physical server.

The issue linked is that is doesn't actually reclaim the space - you either have to wipe it out or do that workaround mentioned to resize it manually.

those scripts are now built into docker with `docker system prune`

“docker system prune” is a recipe for pegging my cpu for the next few hours.

man nice

For those who downvoted this, I’m pretty sure GP is referring to the “nice” command line tool, used to give a task a certain priority: https://en.wikipedia.org/wiki/Nice_(Unix)

If that is the case then you likely have something misconfigured, or are running on seriously underpowered hardware or in a VM that needs more resources allocated to it.

It used to be, with docker for Mac v2 it became fast for me. Problem is I don't wanna be wiping out dozens of images, figure out which ones I wanna keep etc. I want a configuration setting saying "keep X versions" and the rest will automatically get pruned.

Little changed after I ran this script. My ~/Library/Containers/com.docker.docker/ is a whopping 64.01 GB.

Running 'docker system prune' only recovers: Total reclaimed space: 1.986GB

But when I check ~/Library/Containers/com.docker.docker/ for size after prune it still says 64.01 GB.

Am I doing something wrong or is 'docker system prune' useless?

docker prune -a is probably what you’re looking for. (I’m not responsible for data loss)

The 64GB is reserved space for the disk image. It doesn’t actually mean there is 64GB of data inside it.

See here: https://docs.docker.com/docker-for-mac/space/

Yap I confirm. 64 GB on my mac.. what da! Proof: https://www.flickr.com/photos/semerda/48720232588/

Seriously. It's absolute trash. I don't even want to think about how much time I've lost waiting for startup and teardown operations.

Edit: Before you downvote me too heavily, go give the issues list a thorough read. Some of the problems are quite bad. Perhaps I could have said it in a nicer, but really, it's bad, and it's been bad for a good long while now.

I hate how the Docker team called it native. Docker for Mac/Windows still run in a hypervisor because so much of Docker is specific to Linux/cgroups. There was a FreeBSD port of Docker that attempted to implement a lot of the Docker API using zfs+jails but it went unmaintained and was never ported to the newer modular Docker implementation.

You're always going to get that performance hit with the hypervisor layer there.

Docker for Windows is coming to use the WSL2, beta is already out.

Calling it “Docker for Windows” is still highly inappropriate and misleading. It is super confusing.

WSL 2 itself uses a hypervisor though, so this is sort of a moot point.

Is this correct? I thought the headline feature of WSL2 was that unlike WSL it didn't use the hypervisor.

Edit: I looked it up. WSL2 continues to use a VM.

https://devblogs.microsoft.com/commandline/announcing-wsl-2/

> Is this correct? I thought the headline feature of WSL2 was that unlike WSL it didn't use the hypervisor.

No, the headline feature of WSL2 is it uses a real Linux kernel under a hypervisor, as opposed to WSL1's approach of a kernel driver running inside the NT kernel which partially emulates the Linux syscall API.

> Edit: I looked it up. WSL2 continues to use a VM.

More accurately, WSL2 starts using a VM, whereas WSL1 didn't. WSL2 runs the Linux kernel inside a VM. WSL1 runs Linux processes under the NT kernel (albeit as a special type of lightweight process called a picoprocess), with an emulation layer to translate Linux syscalls into NT kernel calls.

You've got it backwards.

WSL was a translation layer between Linux and Windows, WSL2 uses Hyper-V (I believe with some special sauce to handle integration).

WSL2 doesn't continue to use a VM, it is new in that it uses a VM. WSL1 did not use a VM, it directly interfaced with the NT executive.

> Docker for Mac/Windows still run in a hypervisor because so much of Docker is specific to Linux/cgroups.

As I understand it, that what you describe is true of Docker for Mac, but not Docker for Windows which uses Windows' built-in container support (analogous to cgroups).

https://stefanscherer.github.io/how-to-run-lightweight-windo...

As far as I understand it, that only applies to Windows-based containers running on Win 10 Pro/Enterprise or Win Server 2016.

This is true. Linux containers still require the VM running in Hyper-V in the background.

I preferred the old mac solution where they didn’t try to hide the vm from you. It was much more straightforward.

I personally disagree. I hated the whole docker-machine rubbish and exporting of the env vars.

That doesn't make the performance problems of docker-for-mac any less nasty though.

I just recently switched to using vscode with the remote ssh plugin and setup an ubuntu vm on my windows machine and performance is like 100x better.

Docker for mac is basically dead to me now, going to finish migrating my projects over to the VM and uninstall it from my laptop.

Have you tried running the Vscode + Linux Subsystem + Docker on Windows stack? It's been pretty good so far (a good writeup on this is at https://nickjanetakis.com/blog/setting-up-docker-for-windows...)

Thanks for sharing that link, author here.

Yeah I don't know why but on Windows the volume performance generally seems to be a lot better than Mac.

I have nothing but good things to say even on 5 year old hardware. Massive web apps (including using webpack) are very very speedy with volumes with a number of different stacks (flask, rails, phoenix, webpack, node).

I still use that set up years later and it's really solid.

For all of it's slowness, and constantly filling my hard drive with old builds because that's the workflow for some reason, it solves the real problem of MacOS constantly breaking packages. That alone makes it worth it.

Yeah. I have to run docker system prune from time to time.

Docker for Mac is a performance nightmare. It requires state of the art $3400 macbook pro to run properly, and even then still takes seconds (or 10s of seconds) to spin up, start local servers, etc. Build processes that would've run locally take 3-10x longer running on docker for mac. The whole thing can be quite frustrating.

Wondering if it's worthwhile just rolling my own vm and run whatever i want in there. I'd lose all the ability to bind to my host's ports, but would be able to control the daemon a bit better.

Reply on news.ycombinator.com