شكرًا لك، هذه التفاصيل الإضافية مفيدة.
بما أنك تعمل على معمارية ARM64، فقد يكون ذلك ذا صلة. دعم حاويات Discourse لمعماريتي ARM/aarch64 كان تاريخيًا يتطلب معالجة خاصة مقارنة بـ x86_64، لذا أنصحك بذكر ذلك بوضوح في عنوان الموضوع أو في المنشور الأول.
نتيجة إضافة الذكاء الاصطناعي مثيرة للاهتمام أيضًا. بما أن التحذير اختفى بعد تعطيل الإضافة، لكنه لم يعد يظهر فورًا بعد إعادة تمكينها، فقد يكون ذلك ناتجًا عن عملية تهيئة لمرة واحدة، أو تدفئة الذاكرة المؤقتة، أو إعداد النموذج/المزود، أو حالة خلفية، وليس عن خلل متكرر في الإضافة.
في هذه المرحلة، أنصحك بالاستمرار في المراقبة، ولكن إذا تكررت المشكلة، حاول التقاط ما يلي:
- نقطة نهاية الـ API الدقيقة وشكل البيانات المرسلة، مع إزالة أي محتوى خاص؛
- ما إذا كان التحذير يظهر فقط في أول طلب API بعد إعادة التشغيل/إعادة البناء، أم في كل طلب API؛
- مدة الطلب من جانب العميل؛
- ما إذا كان تعطيل إضافة الذكاء الاصطناعي يزيل التحذير بشكل موثوق عبر عدة اختبارات؛
- ما إذا كان الأمر نفسه يحدث على 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"
إذا كان الطلب نفسه يستغرق حوالي ثانيتين أو أكثر، فمن المرجح أن تحذير القفل (mutex) يبلغ فقط عن أن مسار إنشاء المنشور استغرق وقتًا أطول مما توقعت Discourse. أما إذا كان الطلب سريعًا جدًا وظل التحذير يظهر، فستكون هذه النتيجة أكثر إثارة للاهتمام.
يبدو أن الأجهزة كافية تمامًا لموقع مستخدم واحد، لذا قد تكون المشكلة محددة بالمعمارية أو طريقة النشر أو مسار الإضافة، وليست مجرد نقص في الموارد.