يبدو هذا أقل كأنه مشكلة pnpm أو Ember، وأكثر كأنه نفاد ذاكرة المضيف ببساطة.
التفصيل الرئيسي هو SIGKILL. هذا يعني عادةً أن نظام التشغيل تدخل وقام بإنهاء العملية (غالبًا عبر قاتل نفاد الذاكرة OOM killer)، وليس أن ember build -prod فشل من تلقاء نفسه.
على المضيفات الصغيرة، يمكن أن تصل عمليات بناء Ember للإنتاج إلى بضعة غيغابايت من ذاكرة الوصول العشوائي بسهولة. حتى مع تفعيل الذاكرة المبادلة (swap)، بمجرد استخدام معظمها، لا يزال بإمكان النواة أن تقرر إنهاء عملية node المتعطشة للذاكرة.
بعض الأمور التي تشير إلى هذا الاتجاه:
- يتم استخدام الذاكرة المبادلة بكثافة بالفعل عند حدوث الفشل.
- يكون الفشل أكثر احتمالاً عندما تعمل حاوية أخرى في نفس الوقت.
- إذا أوقفت الحاوية الأخرى قبل تشغيل التهيئة (bootstrap)، فإن عملية البناء نفسها تنجح.
لذا، تساعد الذاكرة المبادلة قليلاً، لكنها تؤجل المشكلة في الغالب. إيقاف الحاويات الأخرى يقلل من ضغط الذاكرة بما يكفي لإنهاء عملية البناء.
ما ساعد / قد يساعد:
- تجنب تشغيل عمليات بناء متعددة للتهيئة أو الأصول بالتوازي.
- إيقاف الحاويات الأخرى أثناء
ember build -prod. - تحديد استخدام ذاكرة Node (على سبيل المثال
NODE_OPTIONS=--max_old_space_size=1024) لتقليل الاستخدام الأقصى. - إذا أمكن، زيادة ذاكرة الوصول العشوائي للمضيف (4 غيغابايت أو أكثر) يجعل هذا الأمر أكثر موثوقية بكثير.
نأمل أن يساعد هذا في شرح سبب شعورك بأنه عشوائي بعض الشيء وسبب نجاح الأمر عند إيقاف حاوية أخرى.