Thanks, that extra detail is useful.
Since you are running on ARM64, that may be relevant. Discourse’s ARM/aarch64 container support has historically had some special handling compared with x86_64, so I would mention that clearly in the topic title or first post.
The AI plugin result is also interesting. Since the warning disappeared after disabling the AI plugin, but did not immediately return after re-enabling it, this might have been caused by some one-time initialisation, cache warm-up, model/provider setup, or background state rather than a consistent reproducible plugin bug.
At this point I would keep observing, but if it happens again I would try to capture:
- the exact API endpoint and payload shape, with any private content removed;
- whether the warning appears on the first API post after restart/rebuild only, or every API post;
- the client-side request duration;
- whether disabling the AI plugin reliably removes the warning across multiple tests;
- whether the same happens on x86_64 or only ARM64, if you are able to test that.
For checking client-side request duration, you can use curl with timing output, for example:
curl -s -o /dev/null \
-w "total=%{time_total}s connect=%{time_connect}s starttransfer=%{time_starttransfer}s\n" \
-X POST "https://your-site.example.com/posts.json" \
-H "Api-Key: YOUR_API_KEY" \
-H "Api-Username: YOUR_USERNAME" \
--data-urlencode "title=API timing test" \
--data-urlencode "raw=Small plain text API test post" \
--data-urlencode "category=1"
If the request itself is taking around 2 seconds or more, then the mutex warning is probably just reporting that the post-create path took longer than Discourse expected. If the request is very fast but the warning still appears, that would be more interesting.
The hardware looks more than sufficient for a single-user site, so this may be architecture/deployment/plugin-path specific rather than simple under-provisioning.