لديك الكثير من الذاكرة المبادلة (swap) ولكن جزءًا كبيرًا منها قيد الاستخدام بالفعل. نظرًا لأن إعداد الحاوية المزدوجة يقلل من وقت التوقف عن العمل، فربما يكون الاستدعاء الحالي للخادم لا يزال قيد التشغيل وقد تراكم لديه استخدام كبير للذاكرة ربما بسبب تسرب.
ربما يساعد إعادة التشغيل قبل التحديث. ربما قم بقياس استخدام الذاكرة المبادلة قبل وبعد إعادة التشغيل.
لدي نوع من تسرب/توسع الذاكرة في أحد خوادمي. بناءً على اقتراح @RGJ المعقول، قمت بجدولة إعادة تشغيل عبر cron كل 7 أيام في صباح يوم الاثنين الباكر (أوروبا الغربية)
(نعتقد أننا نعرف الإضافة (plugin) التي بها المشكلة ولكنني لم أستثمر الوقت لمعرفة سبب تسرب/توسع الذاكرة)
يبدو أن هذا قتل بسبب نفاد الذاكرة (OOM kill): أنا أستخدم حوالي 2 جيجابايت من ذاكرة الوصول العشوائي (RAM)، وفي عمليات إعادة بناء الحاويات المكونة من حاويتين، يتسبب تداخل التطبيق القديم مع البناء الجديد في تجاوز الذاكرة للحد الأقصى. بالفعل، يتم استخدام حوالي 3 جيجابايت من الذاكرة المبادلة (Swap) قبل التمهيد، لذا يتم إنهاء عملية بناء Ember (التي تتطلب ذاكرة كبيرة) بإشارة SIGKILL. إن إيقاف الحاوية قيد التشغيل (أو إجراء عملية إعادة بناء بحاوية واحدة) يتجنب التداخل وينجح. الخطوة التالية هي التأكد عبر dmesg ومن ثم إما إعادة التشغيل قبل عمليات إعادة البناء / أو التحقيق فيما يدفع الذاكرة المبادلة للارتفاع بمرور الوقت / أو إضافة ذاكرة وصول عشوائي (فالذاكرة المبادلة وحدها لا تبدو كافية لإنقاذه بمجرد استخدامه بكثافة بالفعل).
يبدو هذا أقل كأنه مشكلة pnpm أو Ember، وأكثر كأنه نفاد ذاكرة المضيف ببساطة.
التفصيل الرئيسي هو SIGKILL. هذا يعني عادةً أن نظام التشغيل تدخل وقام بإنهاء العملية (غالبًا عبر قاتل نفاد الذاكرة OOM killer)، وليس أن ember build -prod فشل من تلقاء نفسه.
على المضيفات الصغيرة، يمكن أن تصل عمليات بناء Ember للإنتاج إلى بضعة غيغابايت من ذاكرة الوصول العشوائي بسهولة. حتى مع تفعيل الذاكرة المبادلة (swap)، بمجرد استخدام معظمها، لا يزال بإمكان النواة أن تقرر إنهاء عملية node المتعطشة للذاكرة.
بعض الأمور التي تشير إلى هذا الاتجاه:
يتم استخدام الذاكرة المبادلة بكثافة بالفعل عند حدوث الفشل.
يكون الفشل أكثر احتمالاً عندما تعمل حاوية أخرى في نفس الوقت.
إذا أوقفت الحاوية الأخرى قبل تشغيل التهيئة (bootstrap)، فإن عملية البناء نفسها تنجح.
لذا، تساعد الذاكرة المبادلة قليلاً، لكنها تؤجل المشكلة في الغالب. إيقاف الحاويات الأخرى يقلل من ضغط الذاكرة بما يكفي لإنهاء عملية البناء.
ما ساعد / قد يساعد:
تجنب تشغيل عمليات بناء متعددة للتهيئة أو الأصول بالتوازي.
إيقاف الحاويات الأخرى أثناء ember build -prod.
تحديد استخدام ذاكرة Node (على سبيل المثال NODE_OPTIONS=--max_old_space_size=1024) لتقليل الاستخدام الأقصى.
إذا أمكن، زيادة ذاكرة الوصول العشوائي للمضيف (4 غيغابايت أو أكثر) يجعل هذا الأمر أكثر موثوقية بكثير.
نأمل أن يساعد هذا في شرح سبب شعورك بأنه عشوائي بعض الشيء وسبب نجاح الأمر عند إيقاف حاوية أخرى.
يبدو أن المزيد من الـ swap سيساعد. لن يضر. بدلاً من النظر إلى إجمالي الـ swap والقول إنه يبدو كثيراً، انظر إلى الـ swap المتاح وتأكد من أن لديك مساحة لإعادة البناء.
تبدو فكرة جيدة! هل تعيد تشغيل الخادم أم الحاوية فقط؟
على أي حال، لقد حدث لي مرة أخرى على خادم آخر بحجم 2 جيجابايت + 3 جيجابايت. ثم أعدت تشغيل web_only وحاولت مرة أخرى وعمل بشكل جيد. أعتقد أنني سأضيف إلى أدواتي لإعادة تشغيل web_only، ربما إذا كانت الذاكرة ضمن تعريف معين لـ “منخفضة”.
لقد رأينا حالة واحدة حيث ساعد إعادة تشغيل لينكس (Linux). أعلم أنه ليس بالطريقة التي نحب أن ننظر بها إلى لينكس (Linux) عادةً، ولكن لا تزال هناك إمكانية للتجزئة، وهناك إمكانية لتسرب الذاكرة.
