أنا أجرب تشغيل Discourse على مثيلات AWS المستندة إلى graviton نظرًا لأنها جذابة من حيث السعر. أفهم أن دعم aarch64 تجريبي، ولكن رسالة البناء تقول بالإبلاغ عن المشكلات، لذا فهذه هي. أعتقد أن الكثيرين يشغلون Discourse على AWS، لذا نأمل أن يفيد هذا الآخرين أيضًا.
لقد قمت بتشغيل تثبيت موجود على arm64 بعد إعادة بناء وبعض الفحوصات الأساسية للتأكد من تحميل الواجهة الأمامية. ومع ذلك، يُظهر ./launcher logs web_only أن rails.stderr.log يتم ملؤه باستمرار بهذه:
ERROR: ld.so: object '/usr/lib/libjemalloc.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/usr/lib/libjemalloc.so.1' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
وبالفعل، لا يوجد /usr/lib/libjemalloc.so.1 على arm64 كما هو الحال في صور x86، ولكن يوجد /usr/lib/libjemalloc.so.2. لقد تتبعت اختلاف الإصدار في arm64 إلى هذا:
ملاحظة جانبية: تحية على التوثيق الجيد للتغيير.
أعتقد أن رسالة الخطأ تأتي من الإشارة المحددة إلى /usr/lib/libjemalloc.so.1 غير الموجود هنا:
يبدو أن تجاوز $RUBY_ALLOCATOR السريع والبدائي في templates/web.template.yml قد أوقف رسالة الخطأ بنجاح، لذا يبدو أن rails (puma؟) يعمل الآن مع libjemalloc المناسب.
ومع ذلك، لا أعرف ما إذا كان الإصلاح المناسب قد يتطلب تغييرات أكثر من هذا وما إذا كان مثل هذا التغيير قد يكون له آثار أخرى على أنظمة الإنتاج. ومع ذلك، أردت المشاركة في حال أثر ذلك على الآخرين الذين يحاولون استخدام Discourse مع arm64 في AWS. ربما يمكن لفريق Discourse إلقاء نظرة أيضًا؟
كما يوضح الرابط الذي قدمه @merefield، كنت أعمل بنشاط على صورة الحاوية aarch64 ونفد الوقت لدي يوم الجمعة الماضي.
أعتقد أنني غطيت جميع الأماكن أخيرًا، والخطوة التالية هي تغيير متغير البيئة (ENV) للرابط الرمزي الرئيسي الذي ينتهي بـ .so والذي سيعمل على كل من x64 و ARM64.
يا لها من توقيت محظوظ بالنسبة لي إذن. كنت أعتزم تجربة arm64 منذ فترة طويلة، لكنني لم أقم بذلك إلا اليوم، تمامًا كما كنت تعمل على ذلك.
يسعدني المساعدة في الاختبار عندما تكون جاهزًا، إذا كنت ترغب في اختبار التغييرات على مثيل graviton2.
بالحديث عن ذلك، نظرًا لأن إصدار jemalloc المخصص يمكن أن يسبب مشاكل (ولكنه لا يزال مطلوبًا لبعض إعدادات Raspberry Pi)، فهل سيكون من المنطقي اتخاذ قرار الإصدار بناءً على البحث عن PAGESIZE المحدد على الجهاز الذي يتم فيه بناء الصورة؟ السبب الذي يجعلني أقترح ذلك هو أن مثيل graviton2 الذي أختبر به لديه PAGESIZE = 4k. سيظل هناك حاجة إلى إصدار أحدث من jemalloc لبعض الحالات، ولكنه قد يقلل من الاختلافات بين إعدادات صور arm64 و x64.
لقد اختبرته على Graviton قبل بضع سنوات، وهو يعمل بشكل جيد. العمل الذي أقوم به الآن هو أيضًا جعله متوافقًا مع منصات ARM الأحدث ذات حجم الصفحات غير القياسي. التغييرات كلها متوافقة مع الإصدارات السابقة للمنصات القديمة، لذلك لا ينبغي أن يتغير أي شيء بالنسبة لتلك المنصات.
يمكنني التأكيد على أنه يتم بناؤه بشكل جيد بدون تغييرات محلية على graviton2 وأنه لا توجد أخطاء jemalloc في السجلات التي يمكنني رؤيتها. شكراً لمعالجتك هذا الأمر.
سأستمر في اللعب به حيث قد ننقل خادم الإنتاج الخاص بنا إلى arm64 إذا كان مستقراً بما فيه الكفاية. إذا واجهت شيئاً آخر، فسأبلغ عنه.