حاولت الترقية عند المطالبة من 3.2.0.beta3-dev إلى 3.2.0.beta3 وتعطلت نسخة Discourse الخاصة بي بسبب نفاد الذاكرة أثناء بناء Ember للأصول. حاولت ./launcher rebuild app بنفس النتيجة.
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 0xb83f50 node::Abort() [ember]
2: 0xa94834 [ember]
3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ember]
4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ember]
5: 0xf42265 [ember]
6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [ember]
7: 0xf2ee4e v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
8: 0xf30217 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
9: 0xf113ea v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [ember]
10: 0x12d674f v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [ember]
11: 0x17035b9 [ember]
Aborted (core dumped)
error Command failed with exit code 134.
I, [2023-11-26T17:19:26.345389 #1] INFO -- : yarn run v1.22.19
$ /var/www/discourse/app/assets/javascripts/node_modules/.bin/ember build
Environment: development
WARNING: ember-test-selectors: You are using an unsupported ember-cli-babel version. data-test properties are not automatically stripped from your JS code.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
أعمل على خادم DigitalOcean بسعة 1 جيجابايت لمنظمة غير ربحية، لذلك لا يمكنني تحمل تكلفة ترقيته بذاكرة أكبر. 1 جيجابايت هو الحد الأدنى لحجم Discourse وكانت الإصدارات السابقة تعمل دون مشاكل. هل لديك أي أفكار حول كيفية جعله يعمل مرة أخرى؟
مرحباً وأهلاً بك @andreid
كان موقع الاختبار الخاص بي بحجم 1 جيجابايت يعاني أيضًا من مشاكل في الذاكرة أثناء إعادة البناء مؤخرًا. لقد قمت بترقيته مؤقتًا إلى 2 جيجابايت فقط لتجاوز المشكلة.
يجب أن يكون إضافة 1 جيجابايت من مساحة التبديل (swap) مطابقًا وظيفيًا لإضافة 1 جيجابايت من ذاكرة الوصول العشوائي (RAM)، إذا كانت لديك مساحة قرص كافية لذلك. (من المحتمل أن يستغرق ترقية التشغيل وقتًا أطول، ولكن هذا يتعلق بالأداء وليس بالوظيفة. ما تريده هو تجنب حالة نفاد الذاكرة.)
لدي معلومات إضافية في حال ساعدت في تخفيف المشكلة من جانب Discourse. بدأت نسختي (DigitalOcean ~1GB droplet w/ 2GB swap) مؤخرًا تستغرق وقتًا أطول بكثير لإعادة البناء والإبلاغ عن نفس الخطأ القاتل حوالي 3 من كل 4 مرات (يبدو أن الحظ يتحسن بعد تشغيل ./launcher cleanup، لكن ليس لدي حجم عينة كافٍ لتأكيد ذلك).
قبيل خطأ نفاد الذاكرة المؤقتة، تم تسجيل هذه الأسطر:
Node.js heap_size_limit (491.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (491.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
أنا خارج نطاق خبرتي هنا، لذا أعتذر إذا أخطأت في شيء ما. يشير بعض البحث السريع إلى أن ember-cli يعتمد على node.js وهذا هو السبب في اعتقادي أن هذا الأمر ذو صلة. يمكن تعيين العلامة --max-old-space-size بشكل محتمل أعلى من ذاكرة الوصول العشوائي (ستنتقل ببساطة إلى مساحة التبديل، والتي كما ذكرنا لا بأس بها في هذه الحالة)، لذلك ربما يكون 1024 سقفًا اصطناعيًا نصطدم به ولا يمكن احتواء عمليات إعادة بناء Discourse بعد الآن.
ملاحظات جانبية: على ما يبدو أن --optimize-for-size هي علامة node.js تساعد في تقليل استخدام الذاكرة (لست متأكدًا مما إذا كان Discourse/ember يستخدمها، ربما يتم استخدامها بالفعل)، وهناك حكاية تفيد بأن جامع القمامة لم يتم تشغيله لبعض استخدامات node.js، مما قد يكون مشكلة.
إذا كان أي من هذا ذا صلة ويمكن التحكم فيه من جانب Discourse لاستخدام ember/node.js، فقد يكون من المفيد لشخص ما النظر فيه. إذا لم يكن كذلك، فلا تقلق، سأقوم بتطبيق حل ترقية 2GB المؤقت المقترح أعلاه.
هذه نقطة جيدة جدًا! حاليًا، نزيدها إلى 1024 ميجابايت على الأجهزة ذات الذاكرة العشوائية المنخفضة هنا. يمكننا بالتأكيد التجربة بزيادتها إلى 1500 أو 2000 ومعرفة ما إذا كان ذلك سيساعد.
إذا كان لديك الوقت/الرغبة في تجربتها بنفسك، يمكنك تكوينها عن طريق إضافة متغير جديد إلى قسم env: في ملف app.yml الخاص بك:
تعديل: هذا هو الإعداد الافتراضي لـ Discourse الآن. لا حاجة للتكوين بنفسك
نظرًا لأن الخطأ الفادح لا يحدث في كل مرة، ويستغرق إعادة البناء حوالي 25 دقيقة مؤخرًا (بزيادة عن 5-10 دقائق)، فقد يستغرق الأمر بعض الوقت قبل أن أعرف ما إذا كان زيادة هذا الرقم يحل مشكلة الذاكرة لمواصفات الخادم هذه.
ولكن، يمكنني بالفعل التأكيد على أن تحذيري Node.js heap_size_limit لم يعودا يظهران في سجل إعادة البناء، وكانت إعادة البناء الأولى ناجحة، لذا فهذا واعد.
تعديل: لقد تمكنت من إعادة البناء عدة مرات الآن دون مشاكل، وذلك بفضل إعداد NODE_OPTIONS أعلاه في ملف app.yml الخاص بي. يا للروعة!
تعديل2: يجب أن يشق هذا الحل طريقه إلى Discourse عن طريق زيادة هذا الرقم السحري (رابط من منشور ديفيد) حتى تتمكن الأجهزة الأخرى ذات ذاكرة الوصول العشوائي المنخفضة من الاستمرار في العمل. إذا قرأ أي شخص هذا ويعرف كيفية القيام بذلك، فسيكون ذلك رائعًا. :ابتسامة:
قمنا بتشغيل ./launcher rebuild app عدة مرات وفشلت مع مشاكل مختلفة.
أولاً، واجهنا مشاكل مع bundle install يشكو من rbtrace (ينتهي بـ حدث خطأ أثناء تثبيت rbtrace (0.5.0)، ولا يمكن لـ Bundler المتابعة.)
ثم في النهاية واجهنا مشكلة نفاد الذاكرة (OOM):
I, [2023-12-12T07:50:59.497921 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (1010.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (1010.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
<--- Last few GCs --->
[3683:0x5dab130] 279104 ms: Scavenge 981.3 (1037.1) -> 974.5 (1037.1) MB, 8.3 / 0.0 ms (average mu = 0.699, current mu = 0.681) allocation failure;
[3683:0x5dab130] 279136 ms: Scavenge 981.8 (1037.1) -> 975.0 (1037.1) MB, 8.0 / 0.0 ms (average mu = 0.699, current mu = 0.681) allocation failure;
[3683:0x5dab130] 282606 ms: Mark-sweep 994.8 (1050.6) -> 987.7 (1048.9) MB, 3316.1 / 0.0 ms (average mu = 0.593, current mu = 0.501) allocation failure; GC in old space requested
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 0xb83f50 node::Abort() [ember]
2: 0xa94834 [ember]
3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ember]
4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ember]
5: 0xf42265 [ember]
6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, [snip]
Aborted (core dumped)
error Command failed with exit code 134.
وأخيرًا، تشغيلها باستخدام ./discourse_doctor تمكن من تجاوز ذلك في النهاية (لماذا رغم ذلك؟ المزيد من الأشياء في الذاكرة المؤقتة في عمليات التشغيل اللاحقة مما جعلها تستخدم ذاكرة أقل؟ )
I, [2023-12-12T08:02:50.556442 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (1010.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (1010.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
110:M 12 Dec 2023 08:07:50.026 * 100 changes in 300 seconds. Saving...
110:M 12 Dec 2023 08:07:50.030 * Background saving started by pid 3706
3706:C 12 Dec 2023 08:07:51.292 * DB saved on disk
3706:C 12 Dec 2023 08:07:51.294 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 1 MB
110:M 12 Dec 2023 08:07:51.334 * Background saving terminated with success
Purging temp files
Bundling assets
لكن هذا كان احتكاكًا لم يكن ينبغي أن نواجهه. نأمل أن يتحسن هذا في المستقبل.
للعلم:
# free -h
total used free shared buff/cache available
Mem: 1.9Gi 1.3Gi 87Mi 138Mi 593Mi 394Mi
Swap: 2.0Gi 337Mi 1.7Gi
يبدو أن تعديل متغير البيئة NODE_OPTIONS الخاص بنا هو كل ما هو مطلوب، لذا أظن أن أحد تبعيات التطبيق أو تغييرًا في V8 جعل قيمتنا السابقة هناك لا تعمل بعد الآن.
يبدو جيدًا بالنسبة لي! من الواضح أن عمليات إعادة البناء التي تستغرق 30 دقيقة أو أكثر لا تزال غير مثالية، لذا آمل أن نتمكن من تحسين الأمور في المستقبل القريب. لكن هذا يبدو حلاً جيدًا لوقف النزيف.
تجدر الإشارة إلى أن الزيادة في إصدار postgres 16 مقارنة بالإصدار 13 تستهلك مساحة أقل وهي محسّنة بشكل أفضل بكثير. يمكن أن يؤدي هذا إلى تقليل إجمالي ذاكرة الخادم المستهلكة.
لقد واجهت مشكلة إعادة بناء مماثلة اليوم (حاويتان) مع إعداد 2 جيجابايت + 2 جيجابايت مبادلة، لموقع صغير.
توسيعها إلى 2 جيجابايت + 4 جيجابايت مبادلة قد تجاوزها هذه المرة.
هذا هو الإعداد الافتراضي لـ Discourse الآن. لا حاجة للتكوين بنفسك
)