I’m currently running SmokePing in a container on a Mac mini – using Docker for Mac, and of course HyperKit. And after a couple of hours of running Hyperkit suddenly consumes all CPU allocated to it, and freezes the container. Nothing short of killing Hyperkit will stop or restart the container.
And trying to read up on this reveals a lot of postings with this problem, but very few (if any) consistent solutions.
What seems to be a common thread is the use of the MacOs filesystem to persist data from the applications running in the container. In my case Smoking stores all its configuration and data files in a configurable place in the hosts filesystem through a setup like this :
docker create –name smokeping -e PUID=1000 -e PGID=1000 -e TX=Europe/London -p 82:80 -v /Users/gisvold/docker/smokeping/config:/config \
-v /Users/gisvold/docker/smokeping/data:/data –restart unless-stopped linuxserver/smokeping
Running “top” inside the container show no real cpu usage in the container
And it does not increase significantly up until the moment it freezes the container and my terminal session is terminated by the container.
So it looks like Hyperkit is the problem here, and reading documentation there seems to be a possibility that the use of the MacOs filesystem to store the data files may be the culprit, but with one new theory I have on why.
It runs out that there is a new configuration for syncing filesystem data between the host OS and the container.
According to the official documentation of Docker for Mac,
Docker 17.04 CE Edge adds support for two new flags to the docker run -v, –volume option, cached and delegated, that can significantly improve the performance of mounted volume access on Docker for Mac.
There are 3 different flags that you can use in the –volume option:
consistent: perfect consistency (host and container have an identical view of the mount at all times)
cached: the host’s view is authoritative (permit delays before updates on the host appear in the container)
delegated: the container’s view is authoritative (permit delays before updates on the container appear in the host)
So I have tried the following new configurations :
docker create –name smokeping -e PUID=1000 -e PGID=1000 -e TX=Europe/London -p 82:80 -v /Users/gisvold/docker/smokeping/config:/config:cached \
-v /Users/gisvold/docker/smokeping/data:/data:cached –restart unless-stopped linuxserver/smokeping
This did not help, so the last option was :
docker create –name smokeping -e PUID=1000 -e PGID=1000 -e TX=Europe/London -p 82:80 -v /Users/gisvold/docker/smokeping/config:/config:delegated \
-v /Users/gisvold/docker/smokeping/data:/data:delegated –restart unless-stopped linuxserver/smokeping
In addition to this I excluded the data directory from Time Machine backups – as there are around 80 RRD database files there – and this means that they change constantly, and all of them are therefore being backed up every hour, or rather every 2 hours, coinciding with the extremely high CPU load.
For now the container has been running with very low Cpu usage < 4% – but it has only been 4 hours so I’m not going to break out the champagne yet.