فشل التهيئة بسبب قاتل نفاد الذاكرة

مرحبًا يا أصدقاء،

أريد تحديث نظام Discourse الخاص بي باستخدام الأمر ./launcher rebuild app. كان يعمل بشكل جيد لمدة عام تقريبًا. أقوم بالتحديث كل 2-4 أسابيع إذا لزم الأمر.

أعمل على نظام Ubuntu 18.04.5 LTS

***@***:~# lsb_release -a
لا توجد وحدات LSB متاحة.
معرف الموزع: Ubuntu
الوصف:    Ubuntu 18.04.5 LTS
الإصدار:        18.04
الاسم الرمزي:       bionic

اليوم يتوقف مع الخطأ التالي:

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake themes:update assets:precompile' failed with return #<Process::Status: pid 726 exit 1>
موقع الفشل: /pups/lib/pups/exec_command.rb:112:in `spawn'
فشل التنفيذ مع المعاملات {"cd"=>"$home", "hook"=>"assets_precompile", "cmd"=>["su discourse -c 'bundle exec rake themes:update assets:precompile'"]}
db6d1b1dd685de69942a3df05c9cbd622860faaa286b042635878519d5b69b7b
** فشل التمهيد ** يرجى التمرير للأعلى والبحث عن رسائل الخطأ السابقة، قد يكون هناك أكثر من خطأ.
قد يساعد ./discourse-doctor في تشخيص المشكلة.

كان أول خطأ قبل هذه الرسالة هو:

<--- JS stacktrace --->

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
 1: 0xa04200 node::Abort() [node]
 2: 0x94e4e9 node::FatalError(char const*, char const*) [node]
 3: 0xb7978e v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xb79b07 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xd34395  [node]
 6: 0xd46c01 v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
 7: 0xd0c472 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]
 8: 0xd086c2 v8::internal::FactoryBase<v8::internal::Factory>::AllocateRawArray(int, v8::internal::AllocationType) [node]
 9: 0xd08774 v8::internal::FactoryBase<v8::internal::Factory>::NewFixedArrayWithFiller(v8::internal::Handle<v8::internal::Map>, int, v8::internal::Handle<v8::internal::Oddball>, v8::internal::AllocationType) [node]
10: 0xf4ef4b v8::internal::OrderedHashTable<v8::internal::OrderedHashSet, 1>::Allocate(v8::internal::Isolate*, int, v8::internal::AllocationType) [node]
11: 0xf4f0df v8::internal::OrderedHashTable<v8::internal::OrderedHashSet, 1>::Rehash(v8::internal::Isolate*, v8::internal::Handle<v8::internal::OrderedHashSet>, int) [node]
12: 0x103eb98 v8::internal::Runtime_SetGrow(int, unsigned long*, v8::internal::Isolate*) [node]
13: 0x1401219  [node]
Aborted (core dumped)
rake aborted!
Errno::ENOENT: No such file or directory @ rb_file_s_size - /var/www/discourse/public/assets/discourse/tests/test_helper-a9cbc4e1abdd1f2e9afced86d051cbd63c2e224dafe782533646a01592cc1f42.js
/var/www/discourse/lib/tasks/assets.rake:290:in `size'
/var/www/discourse/lib/tasks/assets.rake:290:in `block (4 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:181:in `block in concurrent?'
/var/www/discourse/lib/tasks/assets.rake:281:in `block (3 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:272:in `each'
/var/www/discourse/lib/tasks/assets.rake:272:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:181:in `concurrent?'
/var/www/discourse/lib/tasks/assets.rake:269:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rake-13.0.3/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tasks: TOP => assets:precompile
(See full trace by running task with --trace)
I, [2021-04-26T13:10:13.996101 #1]  INFO -- : Downloading MaxMindDB...
Compressing Javascript and Generating Source Maps

I, [2021-04-26T13:10:14.018697 #1]  INFO -- : Terminating async processes
I, [2021-04-26T13:10:14.020721 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 55
I, [2021-04-26T13:10:14.022854 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 172
172:signal-handler (1619442614) Received SIGTERM scheduling shutdown...
2021-04-26 13:10:14.023 UTC [55] LOG:  received fast shutdown request
2021-04-26 13:10:14.030 UTC [55] LOG:  aborting any active transactions
2021-04-26 13:10:14.043 UTC [55] LOG:  background worker "logical replication launcher" (PID 64) exited with exit code 1
2021-04-26 13:10:14.045 UTC [59] LOG:  shutting down
2021-04-26 13:10:14.073 UTC [55] LOG:  database system is shut down
172:M 26 Apr 2021 13:10:14.122 # User requested shutdown...
172:M 26 Apr 2021 13:10:14.123 * Saving the final RDB snapshot before exiting.
172:M 26 Apr 2021 13:10:14.270 * DB saved on disk
172:M 26 Apr 2021 13:10:14.271 # Redis is now ready to exit, bye bye...

لا يعمل Discourse بعد ذلك. يعمل فقط إذا قمت بإعادة تشغيل الخادم، لكنني لا أستطيع بعد ذلك تشغيل rebuild app مرة أخرى. نفس الخطأ.

هل يمكنك مساعدتي في حل هذه المشكلة؟

مع أطيب التحيات

خادمك يستنفد الذاكرة أثناء عملية التمهيد. هل يمكنك مشاركة مخرجات free -m؟

إعجاب واحد (1)
**@**:~# free -m
              total        used        free      shared  buff/cache   available
Mem:            985         777          70          49         136          44
Swap:          2047         228        1819

هـم، أتساءل عن نفاد الذاكرة حتى بعد إعادة التشغيل. لم أقم أيضًا بتثبيت أي شيء إضافي منذ آخر تحديث.

لدي نفس المشكلة. الذاكرة غير كافية لـ nodejs.
استخدمت “export NODE_OPTIONS=”–max_old_space_size=4096 --some_other_option""، لكن هذا لم يُسفر عن نتائج.

كان لدي نفس تتبع المكدس أيضًا عند محاولة إعادة البناء. التثبيت جديد نسبيًا، وأنا أستخدمه فقط للتطوير والاختبار، لذا لا يزال يجب أن يكون هناك مساحة جيدة أعتقد ذلك؟

نظام التشغيل: Ubuntu 20.04.1 LTS
مخرجات free -m:

root@discourse-test-environment:/var/discourse# free -m
              total        used        free      shared  buff/cache   available
Mem:            981         136         581           0         263         698
Swap:          2047         113        1934
إعجاب واحد (1)

هذا أقل قليلاً من الحد الأدنى البالغ 1 جيجابايت. يمكنك محاولة زيادة مساحة الذاكرة المؤقتة (swap) قليلاً، لكنني أنصح بزيادة ذاكرة الوصول العشوائي (RAM).

إذا كنت تتلقى هذا الخطأ، فأنت بحاجة إلى مزيد من ذاكرة الوصول العشوائي (أو ربما الذاكرة المؤقتة، لكن ذاكرة الوصول العشوائي أفضل).

3 إعجابات

حسناً، لكن هل يمكنك إخبارنا بالسبب وراء هذا السلوك الجديد؟ لقد عمل هذا الإعداد بنجاح لأكثر من عام. فما الذي يجعل ديسكورت مختلفاً الآن عما كان عليه في الماضي؟

إعجاب واحد (1)

شكرًا على التوصية. نعم، الأمر غريب بعض الشيء؛ فعادةً ما كنتُ أكتفي بملف تبديل افتراضي بحجم 2 جيجابايت على خادم Digital Ocean بتكلفة 5 دولارات. سأتابع الأمر لأرى ما إذا كان هذا سيصبح أكثر شيوعًا مع آخر التحديثات أو ما شابه.

على أي حال، قمتُ بإضافة مساحة تبديل أكبر بكثير (4 جيجابايت) في ملف منفصل من هنا.

لكن التحديث فشل لا يزال. ربما تكون ذاكرة الوصول العشوائي (RAM) الإضافية ضرورية لا مفر منها. هذا أمر غير متوقع لأن الخادم يستضيف حاليًا موضوعًا واحدًا ومستخدمًا واحدًا فقط. كما أتساءل: هل هناك أي إجراء يجب اتخاذه لضمان أن يعرف Discourse استخدام مساحة التبديل، أم أنها متاحة افتراضيًا؟

إليك مخرجات أمر free -m الجديدة:

              total        used        free      shared  buff/cache   available
Mem:            981         138         576           0         266         703
Swap:          6143         109        6034
إعجاب واحد (1)

نعم، أنا أيضًا على Digital Ocean Droplet مع 1 vCPU و 1GB vRAM :slight_smile:

إعجاب واحد (1)

لقد قمت بزيادة ذاكرة التبديل إلى 3 جيجابايت. لا يزال الأمر لا يعمل مع نفس الخطأ.

إعجاب واحد (1)

أستطيع إعادة بناء مثيلي الاختباري باستخدام 2.5 جيجابايت فقط من الذاكرة العشوائية (RAM) والذاكرة الافتراضية (swap). ومع ذلك، من الممكن أن تتطلب مثيلتك الخاصة ذاكرة أكثر من ذلك.

هل لديك أي إضافات مثبتة؟ أشك في أن واحدة منها هي المسببة لاستهلاك هائل للذاكرة أثناء التجميع.

هل يمكنك إعادة البناء دون استخدام الإضافات ومعرفة ما إذا كان ذلك يحل المشكلة؟

شكرًا لك على المشاركة-

بدافع الفضول، ما هو توزيع الذاكرة العشوائية مقابل مساحة التبديل؟ وهل تحسب فقط المساحة “الحرة” في كليهما أم إجمالي حجم ملف التبديل + إجمالي الذاكرة العشوائية للمثيل؟

أوه، بالتأكيد - لقد نسيت أن أذكر أنني كنت أتمنى تثبيت إضافة مصادقة OpenID Connect لـ Discourse.

كما أن لدي حاليًا إضافة مستكشف البيانات مثبتة بالفعل.


  • جربت مرة أخرى مع إضافة مستكشف البيانات وإضافة مدير Docker فقط دون جدوى، ونفس تتبع المكدس (stacktrace) الذي شاركتُه من قبل.
  • جربت مرة أخرى دون أي إضافات (فقط مدير Docker) ولم تنجح إعادة البناء.

سأواصل البحث لأنني لم أقم بأي تغييرات منذ التثبيت الأصلي باستثناء محاولة إضافة إضافة ConnectID.

أواجه مشكلة قد تكون مرتبطة بـ Trouble with `tests/test_helper`? - #2.

لقد حاولت إعادة بناء التطبيق بدون أي إضافات. لا يوجد تغيير. نفس الخطأ.

لا أفهم هذا، لكنه يبدو وكأنه خطأ. أحاول إجراء عملية bootstrap على هذا الموقع. لا توجد إضافات غير قياسية. لقد قمت بنقل الأصول من دلو واحد إلى آخر وهو يعمل بشكل كامل. كنت أقوم بإعادة بناء واحدة إضافية لإضافة DISCOURSE_S3_UPLOAD_BUCKET إلى ENV حتى لا تظهر في واجهة المستخدم. عندما فشل هذا في المرة الأولى، قمت بإلغاء التعليق عن هذا السطر وحاولت مرة أخرى بنفس التكوين الذي عمل قبل 3 أيام.


تم ضغط embed-application-9cef8308c816fc1d83137e63d6c556c6cc2b68fe2b6e5ce16cca6766ba2c0ae4.js بنجاح: 0.17 ثانية

844614.350963717 جاري الضغط: discourse/tests/test_helper-8590b31b8e73c4172aeea4a4a6bd1930ccbce2547a20d831a30d457ba092a631.js
terser '/var/www/discourse/public/assets/discourse/tests/_test_helper-8590b31b8e73c4172aeea4a4a6bd1930ccbce2547a20d831a30d457ba092a631.js' -m -c -o '/var/www/discourse/public/assets/discourse/tests/test_helper-8590b31b8e73c4172aeea4a4a6bd1930ccbce2547a20d831a30d457ba092a631.js' --source-map "base='/var/www/discourse/public/assets/discourse/tests',root='/assets/discourse/tests',url='https://CORRECT_CDN_ADDRESS.b-cdn.net/assets/discourse/tests/test_helper-8590b31b8e73c4172aeea4a4a6bd1930ccbce2547a20d831a30d457ba092a631.js.map'"
تم القتل
rake aborted!
Errno::ENOENT: لا يوجد ملف أو دليل @ rb_file_s_size - /var/www/discourse/public/assets/discourse/tests/test_helper-8590b31b8e73c4172aeea4a4a6bd1930ccbce2547a20d831a30d457ba092a631.js
/var/www/discourse/lib/tasks/assets.rake:290:in `size'
/var/www/discourse/lib/tasks/assets.rake:290:in `block (4 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:181:in `block in concurrent?'
/var/www/discourse/lib/tasks/assets.rake:281:in `block (3 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:272:in `each'
/var/www/discourse/lib/tasks/assets.rake:272:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/assets.rake:181:in `concurrent?'
/var/www/discourse/lib/tasks/assets.rake:269:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rake-13.0.3/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
المهام: TOP => assets:precompile
(راجع التتبع الكامل بتشغيل المهمة مع --trace)
I, [2021-04-26T18:38:36.072881 #1]  INFO -- : جاري تحديث شريط تحميل Discourse...
جاري تحميل MaxMindDB...
جاري ضغط جافا سكريبت وتوليد خرائط المصادر

تساءلت عما إذا كانت هناك مشكلة في عنوان URL الخاص بـ CDN، لكن جميع الأسطر أعلاه تضمنته وعملت بشكل جيد.

هل يعني هذا وجود خطأ في CSS في قالبهم؟ إذا كان الأمر كذلك، فيا لها من مشكلة. يوجد فقط بعض CSS في القالب الرئيسي الخاص بهم. أيضًا هذه المكونات: https://github.com/discourse/DiscoTOC.git و https://github.com/davidtaylorhq/discourse-loading-slider.git

هل هذه قطرة بأقل حجم؟ يبدو أن هذا الملف صعب نسبيًا على Terser للضغط، حيث يسبب ضغطًا كبيرًا على الذاكرة.

أوه. إنها أصغر مما توقعت. إنه موقع أعتقد أنكم أنشأتموه منذ بضع سنوات (عندما كنتم لا تزالون تديرون موقعًا خارج بنيتكم التحتية).

root@community:/var/discourse# free -h
              total        used        free      shared  buff/cache   available
Mem:           1.9G        1.2G        101M        259M        655M        354M
Swap:          2.0G        1.2G        773M

أه، حسنًا. إنه قطرة (droplet) من DigitalOcean بسعة 2 جيجابايت، ولديّ وصول إلى لوحة التحكم الخاصة بهم. سأخبرهم أننا بحاجة للترقية إلى 4 جيجابايت ونقلهم إلى معالج AMD.

تحرير: لكن إذا كان الهدف مجرد ضغط ملف واحد، أليس من المفترض أن تكون قطرة 2 جيجابايت كافية؟

هذا الملف المساعد للاختبار يُسبب ضغطًا كبيرًا على عملية الضغط.

  • يستخدم UglifyJS 1.5 جيجابايت من ذاكرة الوصول العشوائي لضغطه.

  • يستخدم Terser شيئًا يزيد قليلاً عن 1 جيجابايت. يستغرق 40 ثانية. للمقارنة، يستغرق نفس الخادم 8 ثوانٍ فقط على Ember+jQuery :scream:

@eviltrout هل يجب أن يكون هذا الملف موجودًا في بيئة الإنتاج أصلاً؟

آه، يبدو أنه ناتج عن هذا التغيير من @Osama

-rw-r--r-- 1 discourse discourse  14M Apr 26 19:13 _test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js
-rw-r--r-- 1 discourse discourse 6.6M Apr 26 19:14 test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js
-rw-r--r-- 1 discourse discourse 1.1M Apr 26 19:14 test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js.br
-rw-r--r-- 1 discourse discourse 1.5M Apr 26 19:14 test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js.gz
-rw-r--r-- 1 discourse discourse 5.7M Apr 26 19:14 test_helper-f4c4b5bf0657eab910d85b9a65b4bddbbbe2ce2ba603b17fe11b3d633d324e34.js.map
8 إعجابات

فقط لإضافة نقطة بيانات أخرى - لا تزال أعاني من فشل إعادة البناء بعد إزالة مكوني السمة. لذا أستخدم السمة الافتراضية Light فقط.

أيضًا، من أين يأتي هذا المخرجات؟ أود التحقق من ذلك وتصحيحه قليلاً من جانبي أيضًا. هل هذا يشبه خيار التفصيل في أمر ./launcher rebuild app؟

سيستغرق إصلاح هذا بشكل صحيح بعض الوقت، لذا سأقوم بإلغاء هذا التغيير مؤقتًا.

9 إعجابات