在 Docker 上诊断 Mac 的高 CPU 使用率

This is a small dTrace script I use to find where the kernel is spending its time (it's from Solaris, and dates back to the early days of Solaris 10):

#!/usr/sbin/dtrace -s


profile:::profile-1001hz
/arg0/
{
@[ stack() ] = count();
}

It simply samples kernel stack traces and counts each one it encounters in the @ aggregation.

Run it as root:

... # ./kernelhotspots.d > /tmp/kernel_hot_spots.txt

Let it run for a decent amount of time while you're having CPU issues, then hit CTRL-C to break the script. It will emit all the kernel stack traces it encountered, the most common last. If you need more (or less) stack frames from the default with

    @[ stack( 15 ) ] = count();

That will show a stack frame 15 calls deep.

The last few stack traces will be where your kernel is spending most of its time. That may or may not be informative.

This script will do the same for user-space stack traces:

#!/usr/sbin/dtrace -s


profile:::profile-1001hz
/arg1/
{
@[ ustack() ] = count();
}

Run it similarly:

... # ./userspacehotspots.d > /tmp/userspace_hot_spots.txt

ustack() is a bit slower - to emit the actual function names, dTrace has to do a lot more work to get them from the address spaces of the appropriate processes.

Disabling System Integrity Protection might help you get better stack traces.

See DTrace Action Basics for some more details.

My suspicion is that the issue is IO related. With MacOS volumes, this involves osxfs where there is some performance tuning you can perform. Mainly, if you can accept fewer consistency checks, you can set the volume mode to delegated for faster performance. See the docs for more details: https://docs.docker.com/docker-for-mac/osxfs-caching/. However, if your image contains a large number of small files, performance will suffer, especially if you also have lots of image layers.

You can also try the following command to debug any process issues within the embedded VM that docker uses:

docker run -it --rm --pid host busybox top

(To exit, use <ctrl>-c)

To track down if it's IO, you can also try the following:

$ docker run -it --rm --pid host alpine /bin/sh
$ apk add sysstat
$ pidstat -d 5 12

That will run inside the alpine container running in the VM pid namespace, showing any IO happening from any process, whether or not that process is inside of a container. The stats are every 5 seconds for one minute (12 times) and then it will give you an average table per process. You can then <ctrl>-d to destroy the alpine container.

From the comments and edits, these stats may check out. A 4 core MBP has 8 threads, so full CPU utilization should be 800% if MacOS is reporting the same as other Unix based systems. Inside the VM there's over 100% load shown in the top command for the average in the past minute (though less from the 5 and 15 averages) which is roughly what you see for the hyperkit process on the host. The instantaneous usage is over 12% from top, not 3%, since you need to add the system and user percentages. And the IO numbers shown in pidstat align roughly with what you see written to the qcow2 image.

If the docker engine itself is thrashing (e.g. restarting containers, or running lots of healthchecks), then you can debug that by watching the output of:

docker events

I have the same problem. My CPU % went back down to normal after I removed all my volumes.

docker system prune --volumes

I also manually removed some named volumes:

docker volume rm NameOfVolumeHere

That doesn't solve the overall issue of not being able to use volumes with Docker for mac. Right now I'm just being careful about the amount of volumes I use and closing Docker desktop when not in use.

Changing the volumes to use a delegated configuration worked for me and resulted in a drastic drop in CPU usage. see the document: https://docs.docker.com/docker-for-mac/osxfs-caching/#delegated

how set in my docker-compose.yml:

version: "3"
services:
my_service:
image: python3.6
ports:
- "80:10000"
volumes:
- ./code:/www/code:cached

For me this worked, macOS 10.15.5, Docker Desktop 2.3.0

EDIT: after a few weeks, my cpu issues have come back - so the below solutions probably aren't worth it

My CPU was always running crazy high, and it wasn't I/O, as determined using docker stats

I did a bunch of stuff, but had it suddenly decrease to reasonable levels and stay that way for over a week now, after doing the following:

• Ensure you have the right # of CPU's set - not what you have, but HALF that amount. Mine was more than half, and I feel this was the real problem, in Preferences | Resources
• decrease # of file shares if possible - Preferences | Resources, /private, /tmp/, /var/folders
• disable use gRPC FUSE for file sharing - Preferences | Resources

to disable use gRPC FUSE for file sharing might not good idea. I found the feedback from another issue made by docker community. see bellow:

So we'll look into that. However,
osxfs will not be supported long term.
We can't maintain two solutions.

hier to docker issue thread

The solution I found was to increase the resources given to Docker. I increased the Memory from 2GB to 8GB, the Swap from 1GB to 2GB, and the disk image size to 160GB. Completely solved the problem for me, and it's an easy one for readers to try.

Had same issue with docker today in Big Sur (tried pruning images, changing to apple virtualization, nothing helped). However, disabling the docker desktop to startup in preferences and never opening the desktop gui seems to fix it for me. Docker now runs with only 10%cpu usage even after starting a few containers. However, once I open the desktop gui it slowly rises again to +90% cpu and keeps on hogging the cpu even after closing the DockerDesktop process. Docker version 20.10.13, build a224086.

There is an open issue here https://github.com/docker/for-mac/issues/6166

It seems there are a few bugs going on

1. For some people (me including) unchecking the "Open Docker Dashboard at startup" and manually restarting docker do the job.

2. For other people increasing resources like CPU and Memory works