QEMU Docker process stuck 100%: `docker top` shows using 0%

I am running the Symfony PHP server inside of a Docker image on my M1 Macbook. This setup is dog slow. I decided to try and find out why, so I ran htop on my own machine, showing the QEMU process belong to Docker using well over 100%.
cpu usage

Running docker htop <containername> aux shows the cpu usage of the processes in the container, which shows them idling at around 0%. How can they use 0% and the QEMU process be stuck at 100%?

In my head, QEMU is used for emulation, so I assumed that this was caused by some kind of x86 → ARM thing, but the image turns out to be for the ARM architecture, so that is not it:

$ docker image inspect pete-build | jq .[0].Architecture
"arm64"

Any ideas on how I can understand where my cpu cycles go?

The Symfony process is probably using some file watchers, so maybe it is a file system thing where polling for changes trashes the performance? Really on thin ice, but while the other containers consume a lot of cpu (like 10-20%) doing nothing, it is still way off.

Symfony specific

This happens when running the Symfony process, not when just running bash. Say I do this:

docker run --rm -ti   pete-build:latest /bin/bash

This will not use any cpu at all. If I then execute ./bin/console server:run the cpu hits the roof

$  docker run --rm -ti  pete-build:latest /bin/bash
www-data@91f7880bd3f2:~/pete$ ./bin/console server:run

 [OK] Server listening on http://127.0.0.1:8000


 // Quit the server with CONTROL-C.

PHP 7.2.34 Development Server started at Fri Oct  8 20:56:48 2021
Listening on http://127.0.0.1:8000
Document root is /var/www/pete/web
Press Ctrl-C to quit.

Details

$ uname -p
arm

$ uname -a
Darwin air.lan 21.1.0 Darwin Kernel Version 21.1.0: Sat Sep 11 12:27:45 PDT 2021; root:xnu-8019.40.67.171.4~1/RELEASE_ARM64_T8101 arm64

$ docker --version
Docker version 20.10.8, build 3967b7d

$ ps -ef $docker_qemu_pid 
  UID   PID  PPID   C STIME   TTY           TIME CMD
  501 30022 30016   0 tor02am ??       342:45.59 /Applications/Docker.app/Contents/MacOS/qemu-system-aarch64 -accel hvf -cpu host -machine virt,highmem=off -m 4096 -smp 4 -kernel /Applications/Docker.app/Contents/Resources/linuxkit/kernel -append page_poison=1 vsyscall=emulate panic=1 nospec_store_bypass_disable noibrs noibpb no_stf_barrier mitigations=off   vpnkit.connect=tcp+bootstrap+client://192.168.65.2:63329/6eb5d8bbe41a0f0e622644d6a5ff4481a3126f7280deda105a956cebc7392c2b console=ttyAMA0 -initrd /Applications/Docker.app/Contents/Resources/linuxkit/initrd.img -serial pipe:/var/folders/83/6fm56kn147z53l3yxrnq3_th0000gn/T/qemu-console040454967/fifo -drive if=none,file=/Users/my-user/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw,format=raw,id=hd0 -device virtio-blk-pci,drive=hd0,serial=dummyserial -netdev socket,id=net1,fd=3 -device virtio-net-device,netdev=net1,mac=02:50:00:00:00:01 -vga none -nographic -monitor none

CPU USAGE: https://i.imgur.com/oSXPJLD.png

(double posted on SuperUser)

The cpu usage is high on x86 when running the Symfony server, as well, btw, but idling at about 35-50% on a beefy iMac. Doing docker top on the container shows similar values as on ARM; cpu usage of the process is about 2%.


On the Symfony Slack they are familiar with Docker’s abysmal I/O performance on macOS, so got some good tips to try out there, like using docker-sync and mutagen. Alternatively use FPM to lower CPU. Only tried out docker-sync, which had no real effect - at least on my M1 processor.

Now trying out getting Vagrant to run on M1, which is yet another adventure all unto itself :smile: