ログにDistributedMutexのエラー警告が頻繁に表示される

ありがとうございます、その追加情報は役立ちます。

ARM64 で動作しているとのことですので、それが関連している可能性があります。Discourse の ARM/aarch64 コンテナサポートは、歴史的に x86_64 と比較して特別な処理が必要とされてきたため、トピックのタイトルまたは最初の投稿でそれを明確に明記することをお勧めします。

AI プラグインの結果も興味深いですね。AI プラグインを無効にした後に警告が消え、再度有効にしても直ちに再発しなかったことから、これは一貫して再現するプラグインのバグではなく、何らかの一回限りの初期化、キャッシュのウォーミングアップ、モデル/プロバイダーの設定、またはバックグラウンドの状態が原因だった可能性があります。

現時点では引き続き観察を続けることをお勧めしますが、再度発生した場合は、以下を記録してみてください。

  1. 機密コンテンツを削除した正確な API エンドポイントとペイロードの形状
  2. 警告が再起動/再ビルド後の最初の API 投稿でのみ表示されるのか、それともすべての API 投稿で表示されるのか
  3. クライアント側のリクエスト所要時間
  4. AI プラグインを無効にすることで、複数のテストにおいて警告が確実に消えるかどうか
  5. x86_64 でも同様の現象が発生するか、それとも ARM64 のみか(テスト可能な場合)

クライアント側のリクエスト所要時間を確認するには、curl を使用してタイミング情報を出力できます。例えば以下のようにします。

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"

リクエスト自体に 2 秒以上かかっている場合、ミューテックス警告は単に投稿作成パスが Discourse の想定よりも時間がかかったことを報告しているだけである可能性が高いです。一方、リクエストが非常に高速なのに警告が表示される場合は、より興味深い現象と言えます。

ハードウェアは単一ユーザーサイトとしては十分すぎる性能を持っているようですので、これは単純なリソース不足ではなく、アーキテクチャ/デプロイメント/プラグインパス固有の問題である可能性があります。