GitLab

Whenever I run GlitchTip in a Docker container on my Mac M1, one of the first log messages I get once the server is up and listening (after the uWSGI workers are spawned) is:

[busyness] 26473184 requests in listen queue, spawning 1 emergency worker(s) (1)!

And from then on, the following log message is output about once every second (date stamp changes, everything else remains the same for every message):

Wed Jun 23 12:32:14 2021 - *** uWSGI listen queue of socket ":8000" (fd: 3) full !!! (26473184/64) ***

There is no way there are 26473184 requests in the queue here - especially not the moment the server starts up. And that 26473184 is consistent - it doesn't vary for me. Increasing somaxconn in the container or increasing the UWSGI_LISTEN environment variable has no effect, btw.

So far, this only happens on my Mac M1. I have no issues running on an Intel Mac I tested. So I'm fairly certain this is because of the ARM architecture.

I don't have a lot of experience with uWSGI, Django, or even Python for that matter. But I tried to investigate this as much as I could.

First I tried to find some other Django apps using uWSGI to run and see if they had similar problems (https://github.com/sissbruecker/linkding and https://github.com/healthchecks/healthchecks, for example). I only found one instance of a similar error: https://github.com/django-oscar/django-oscar. It does the same thing for me, but the number of requests is different (though consistent). But I was having trouble narrowing in on commonalities, so that was a bit of a dead-end for me.

I decided to try to build the docker image myself, so I pulled the gitchtip-backend repo and tried to build from there. That failed because cargo wasn't found at some point during the pip install process -- in particular, it was when it was building symbolic. I eventually got a rust toolchain installed by adding these 2 lines to the Dockerfile:

RUN curl https://sh.rustup.rs -sSf | sh -s -- -y
ENV PATH=/root/.cargo/bin:$PATH

Which gets me further, but ultimately hangs at Building wheel for symbolic (setup.py) ... \, and eventually dies from a timeout. So I think this may all stem from the symbolic package? I found this issue in the symbolic github that seems likely related.

The app still works, by the way. I can log in and post events, etc. But requests are extremely slow, and it leads to ever-increasing resource usage by the glitchtip server - not to mention being blasted by that log message every second.

I would love to figure out how to get this working correctly on ARM, but my expertise in some of these areas is lacking and I'm not sure what to try next. Are others having issues on ARM64? Are there plans to support it? Or is there any guidance on getting things working relatively well on ARM64.

Reproducing:

This should be reproducible by simply using the docker-compose.sample.yml from the documentation site on a Mac with an M1 chip (or potentially some other ARM64 chip).