RedXon

Alright, just another status update (for you, anyone interested and anyone seeing this post in the future with a similar problem).

After the overlay2 didn't bring the desired effect, I switched back to a docker image. I tested it for what is now aproximately just under 24 hours and it seems to be good. I see the dockerd processes in htop but they each consume just 0.1% memory, where before (with natie and overlay2 docker storage in a folder) it would creep up until it was well over 40% memory and rising until it would just crash and be killed by the linux oom-killer.

I don't have all the containers up yet just the ones I did the testing before (so the arr suite, plex, nextcloud and some databases) and so far so good. I just started the LLM containers, my GIT, immich and some others again so I'm sitting at 39 running containers with just about 45% memory usage and 39% usage of the docker.img file. Seems to be working so far.

The reason I intially switched away from docker.img maybe for some background is that a few years ago (I've been using Unraid since about 2016 or longer I guess) I got fed up with the way unRaid handeled containers, the Appstore etc. as I was used to working with compose and at that point also kubernetes. So I switched all my containers to a few VMs and run everything with compose. On the VMs naturally I could use docker volumes among other things as the volumes would be in a folder, not in an image with limited file size. The VMs did have downsied though, as mounting the array in the VM was always not an ideal solution for some tasks.

A bit later I figured out a good workflow for me to run compose directly on unRaid so I switched everything back to running on the host itself although with compose. Because I missed some docker volumes and I did have many images (with that many containers that I had at the time) my docker.img got full very fast, which is why I switched to the folder method as I thought it was better than the other one. But now that I have fixed almost all of the docker volumes to folder mounts on /mnt/cache/appdata though I should not run in to the problem of a full docker image again I hope. So fingers crossed this will work for good now.

And still while writing this long paragraph (which to be fair probably no one asked for and will skip anyway) I started the rest of all the containers I was running before (so at the time my problems started) and so far I can report no memory leaks or high CPU load as I had before. The dockerd service is sitting happily at an average of 1-2% CPU load and 0.1-0.2% memory load as it did like before the problems started. I will investigate for a few more days and mark as solved if it doesn't happen again.

So TL;DR for anyone else I guess:
If you're running ZFS cache on unRaid 7.1.x and using a docker folder seeing this task use a lot of ressources in htop:
/usr/bin/dockerd -p /var/run/dockerd.pid --log-opt max-size=500m --log-opt max-file=1 --log-level=fatal --storage-driver=btrs
Then you might as well try to switch to a docker image again and see if it works.

Some other users reported having this issue when the container mounts were not on /mnt/cache/appdata but on /mnt/user/appdata instead, pointing to the fact that the dockerd process is not happy with having slow I/O, so another option for the affected would be to check that and also storage integrity.