Hello! Im running rancher desktop 1.19.3 on a maco...
# rancher-desktop
a
Hello! Im running rancher desktop 1.19.3 on a macos 15.5 and it is running out of CPU for phpfpm
Copy code
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      3104 99.9  0.2 587884 64304 ?        Rsl  17:59   0:10 /usr/bin/qemu-x86_64 /usr/sbin/php-fpm8.4 php-fpm8.4 -F
This is within the the docker container i use within rancher - not sure how to prevent it from eating up all the CPU
f
It looks like you are using an x86_64 container on an arm64 mac. Emulating the Intel CPU will be very slow; you will probably have better luck by using
VZ
emulation and enabling Rosetta. Even better would be to use a native arm64 container.
a
I had VZ emulation enabled and the the QEMU but i enabled rosetta now and will try that How do i use the native arm64 container?
f
How did you start your docker container?
a
docker-compose up
f
Oh, but what is the image you are using? I suspect you may be running the bitnami image, which is only published for x86_64
See if you can use
php:8.2-fpm
instead?
a
All the images under the image tab are related to my project
we just upgraded to php8.4
Im trying to figure out if this is a ranch or macos or php8.4 incompatibility
f
But who build the images. It looks like they were only built for Intel and not for Arm
a
how do i check this from the UI?
f
On second looks, I think the fact that it is using
/usr/bin/qemu-x86_64
is built into your image, so switching to Rosetta is probably not going to change anything.
You will have to check with whoever provides the docker images for your project.
a
I remember needing to turn of rosetta in the past because it caused other issues
Ok - so the dockerfile in my project will need to be updated rather than the settings on rancher desktop?
f
I'm pretty sure. It looks like it is intentionally being built to use QEMU emulation. So you will have to check with whoever is responsible for creating the image.
a
And I should inform them that this image is not compatible and needs to be updated to use arm64?
Currently I have this setup - should it be set to QEMU to match my image on the project?
f
The commandline you quoted above shows that it is running an x86_64 executable by emultating the CPU in software, which will obviously be slow and take a lot of CPU:
Copy code
/usr/bin/qemu-x86_64 /usr/sbin/php-fpm8.4 php-fpm8.4 -F
a
I think I have enough to bring back to my team - thank you for the help and will ping here if I need further help
f
You can look into your compose file to see if you have something like
--platform linux/x86_64
in there. That would tell it to load an Intel image (maybe because there is no arm64 one)
I may be wrong that the qemu call is in the container; please try enabling Rosetta and see if that reduces the CPU usage
Rosetta is not an emulator, but actually translates Intel CPU instructions to ARM instructions. Once the translation is done, execution should be much faster
a
all of our platforms are pointed to
linux/x86_64
so yeh you are right there!
f
This probably means you don't have an ARM variant. In which case QEMU/Rosetta are your only options.
I know this is a bit confusing, but when you use VZ without Rosetta, then QEMU is still being used to emulate containers running Intel code. It just isn't being used to run the VM itself.
But Rosetta is generally a better choice if you regularly run Intel containers. It has the side-effect of slowing down the VM by about 10% for running ARM code, but that doesn't matter if you mostly run Intel code.
a
I enabled rosetta and VZ but now
/usr/sbin/php-fpm8.4 php-fpm8.4 -F
is not present at all
f
But does the application work?
Maybe the commandline is hidden from
ps
etc
a
the application does not work and i get this error:
Copy code
2025/06/26 18:54:00 [crit] 909#909: *7 connect() to unix:/var/run/php/php8.4-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 172.19.0.1, server: *.<http://splashthat.com|splashthat.com>, request: "GET / HTTP/2.0", upstream: "<fastcgi://unix>:/var/run/php/php8.4-fpm.sock:", host: "<http://splashlocal.com|splashlocal.com>"
Im restarting the php-fpm8.4 service within the container
interesting - it keeps running and stopping
f
I'm sorry, this is kind of the end of what I can help with. You should have all the info you need to figure out the rest with your team
a
Yep - thank you!
f
You are welcome!