يستغرق Precompiling assets 20 دقيقة

أقوم بإعادة بناء الصورة على قطرة Digital Ocean وشيء ما يستغرق وقتًا طويلاً:

I, [2024-01-10T09:47:14.854311 #1]  INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (492.75) is less than 2048MB. Setting --max-old-space-size=2048.
[WARN] (broccoli-terser-sourcemap) Minifying "assets/admin.js" took: 25461ms (more than 20,000ms)
[WARN] (broccoli-terser-sourcemap) Minifying "assets/plugins/chat.js" took: 47818ms (more than 20,000ms)
Purging temp files
Bundling assets
I, [2024-01-10T10:06:07.644096 #3264]  INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js

القطرة لديها 1 جيجابايت من ذاكرة الوصول العشوائي وبخلاف ذلك تعمل Discourse بشكل جيد. هل أفعل شيئًا خاطئًا؟ هل يمكنني فعل شيء لتسريع إعادة البناء؟ شكرا لك!

أعتقد أن هذا سيجعلك مقيدًا جدًا بالذاكرة الآن.

لقد وصل الأمر إلى النقطة التي أوصي فيها بحد أدنى 4 جيجابايت لمثيل Discourse (بالإضافة إلى مساحة التبديل!) (حتى مع 2 جيجابايت + 2 جيجابايت من مساحة التبديل أجد التحديثات عبر الإنترنت بطيئة بشكل مؤلم).

شكرا لك! للأسف هذا حوالي أربعة أضعاف السعر لتحسين قد أشعر به فقط أثناء التحديثات. أيضًا، لا يزال دليل التثبيت السحابي يقول:

الافتراضي لـ 1 جيجابايت من ذاكرة الوصول العشوائي يعمل بشكل جيد لمجتمعات Discourse الصغيرة. نوصي بـ 2 جيجابايت من ذاكرة الوصول العشوائي للمجتمعات الأكبر.

هل نعرف من أين يأتي ضغط الذاكرة في هذه الخطوة؟ ربما يكون من الممكن مقايضة نسبة ضغط أسوأ أو شيء ما مقابل متطلبات ذاكرة أقل؟

إنها قادمة من ember-cli.
أنت بالفعل تواجه مفاضلة بين الوقت والمساحة (نقص مساحة الذاكرة يتسبب في استغراق العملية وقتًا أطول).

موضوع ذو صلة:

أعتقد أنه بالنسبة لتحديثي التالي على خادمي، سأستخدم مرونة مزود الاستضافة للانتقال إلى ذاكرة وصول عشوائي أكبر قبل التحديث، والعودة إلى الحد الأدنى الحالي فورًا بعد ذلك. هناك قدر ضئيل من وقت التوقف الإضافي، ولكن إذا كان إعادة البناء أسرع بكثير، فقد يكون ذلك فوزًا إجماليًا. يجب أن تكون النفقات الإضافية أقل من دولار واحد أو ربما سنت واحد فقط، مقابل ساعة إضافية من ذاكرة الوصول العشوائي (في حالتي، من 6 دولارات شهريًا إلى 12 دولارًا شهريًا، يتم شحنها بالساعة على Digital Ocean بسنت واحد وسنتين على التوالي).

كما هو مذكور في الموضوع المرتبط، فإن إعادة التشغيل مفيدة في بعض الأحيان على أي حال، لذا فهي وقت جيد لتحديث حزم نظام التشغيل وإعادة التشغيل، بالنسبة لي.

آمل أن يؤدي هذا إلى تآكل وتلف أقل لي أيضًا.

قد أختار في الواقع الانتقال من 1 جيجابايت إلى 8 جيجابايت، مما سيكلف 6 سنتات إضافية لكل ساعة، لمنحي حرية حذف ملف التبديل الخاص بي مؤقتًا، وتخفيف أزمة مساحة القرص.

كل شيء يصل إلى ذروته في وقت التحديث - بين الأوقات، يبدو التكوين الأدنى الحالي كافيًا.

يمكنني بالتأكيد تحمل 6 سنتات لكل دورة ترقية.

هذا رائع جدًا! من هو موفر الاستضافة الخاص بك؟

Digital Ocean في إحدى الحالات (1 جيجا رام)، و Hetzner في الحالة الأخرى (2 جيجا رام).

هل يسمحان كلاهما بزيادة ذاكرة الوصول العشوائي عبر الإنترنت وفي مكانها مؤقتًا؟

أم تحتاج إلى التبديل بين “القطرات” / المثيلات؟

أم مجرد إعادة تشغيل؟

لا،

إنه إيقاف - تغيير الحجم - بدء - إعادة بناء - إيقاف - تغيير الحجم مرة أخرى - بدء

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

بالنظر إلى أن وقت إعادة البناء على جهاز بسعة 1 جيجابايت يستغرق وقتًا طويلاً، فقد يكون من الأفضل القيام بذلك، لأنه سيكون معطلاً لمدة 30 دقيقة على أي حال!

وبالتأكيد، إذا كنت مستعدًا للقيام بذلك، فحتى ترقية جهاز بسعة 16 جيجابايت مؤقتًا قد تكون مناسبة من حيث التكلفة

أعتقد أن الكثيرين سيقدرون وقتهم أكثر ويجب عليهم البدء في التفكير في 4 جيجابايت + بشكل دائم.

بالتأكيد هو جزء من مقايضة بين التكلفة والوقت. بالنسبة لي، لقد التزمت بالفعل بقضاء ساعة في رعاية الأطفال للترقيات، وأنا أعرف تمامًا كيفية القيام برقصة مسؤول النظام هذه، لذا فقد تم حجز الوقت بالفعل. أفضل الحفاظ على تكلفة التشغيل الشهرية بأقل قدر ممكن، حتى لو استغرق الأمر بعض الوقت - سيكون لدى الآخرين مقايضات مختلفة.

بالتأكيد، إذا كان إنفاق المال سهلاً، فاحصل على مثيل كبير ومريح!

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

I, [2024-01-10T16:07:58.323464 #1]  INFO -- : cd /var/www/discourse && su discourse -c 'bundle exec rake themes:update assets:precompile'
110:M 10 Jan 2024 16:08:52.047 * 100 changes in 300 seconds. Saving...
110:M 10 Jan 2024 16:08:52.048 * Background saving started by pid 3276
3276:C 10 Jan 2024 16:08:52.384 * DB saved on disk
3276:C 10 Jan 2024 16:08:52.386 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 0 MB
110:M 10 Jan 2024 16:08:52.449 * Background saving terminated with success
Purging temp files
Bundling assets
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
MaxMind IP database updates require a license
Please set DISCOURSE_MAXMIND_LICENSE_KEY to one you generated at https://www.maxmind.com
I, [2024-01-10T16:12:14.362017 #3300]  INFO -- : Writing /var/www/discourse/public/assets/break_string-cc617154cd957804f2f6a1f3bc68258c9cdca3d4b9a322bf777d145fed04790e.js

هنا نرى أن ember (العمود 12) يستخدم 2.5 جيجابايت من ذاكرة الوصول العشوائي (العمود 6) وأكثر من وحدة معالجة مركزية واحدة (العمود 3)

# ps auxfc|egrep -A29 containerd
root      1097  0.2  0.5 1510892 44924 ?       Ssl  16:00   0:01 containerd
root      4507  0.1  0.0 717892  7556 ?        Sl   16:03   0:00  \_ containerd-shim
root      4530  0.1  0.3 312292 30512 ?        Ssl  16:03   0:00      \_ pups
systemd+  4609  0.0  0.3 213236 28608 ?        S    16:03   0:00          \_ postmaster
systemd+  4617  0.0  0.8 213340 67288 ?        Ss   16:03   0:00          |   \_ postmaster
systemd+  4618  0.0  0.0 213236  5876 ?        Ss   16:03   0:00          |   \_ postmaster
systemd+  4619  0.0  0.1 213236 10076 ?        Ss   16:03   0:00          |   \_ postmaster
systemd+  4620  0.0  0.1 213904  8860 ?        Ss   16:03   0:00          |   \_ postmaster
systemd+  4621  0.0  0.0  68004  5592 ?        Ss   16:03   0:00          |   \_ postmaster
systemd+  4622  0.0  0.0 213796  7100 ?        Ss   16:03   0:00          |   \_ postmaster
message+  4682  0.2  0.4  87976 35724 ?        Sl   16:03   0:00          \_ redis-server
1000      7722  1.1  0.0      0     0 ?        Z    16:07   0:01          \_ esbuild <defunct>
root      7736  0.0  0.0   2476   520 ?        S    16:07   0:00          \_ sh
root      7737  0.0  0.0   9296  4156 ?        S    16:07   0:00          |   \_ su
1000      7738  8.3  0.0   2476   580 ?        Ss   16:07   0:12          |       \_ sh
1000      7835  0.4  0.9 929524 78416 ?        Sl   16:08   0:00          |           \_ node
1000      7857  0.0  0.0   2484   524 ?        S    16:08   0:00          |               \_ sh
1000      7858  156 30.5 67413228 2491796 ?    Sl   16:08   3:37          |                   \_ ember
1000      7876 39.0  1.7 11486300 145476 ?     Ssl  16:08   0:44          |                       \_ node
1000      7882 36.7  1.5 11466956 122648 ?     Ssl  16:08   0:41          |                       \_ node
1000      7889 37.1  4.1 11647592 340908 ?     Ssl  16:08   0:42          |                       \_ node
1000      7761  1.5  0.0      0     0 ?        Z    16:08   0:02          \_ esbuild <defunct>

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

تعديل: أخذت نسخة احتياطية قبل أن أبدأ وأخرى بعد الانتهاء من المهمة، وكانت تفصل بينهما 35 دقيقة. لذا لم يكن وقت التعطل كما رآه المستخدمون أطول من ذلك.

تعديل: لاحظ أن لوحة تحكم Digital Ocean تقول إن عملية تغيير الحجم قد تستغرق دقيقة واحدة لكل جيجابايت من البيانات على القرص - في حالتي 14 جيجابايت فقط، وكما تبين، دقيقتان فقط لكل تغيير حجم. ولكن إذا كان لديك قدر كبير من البيانات على المثيل، فقد تستغرق هذه الرقصة لتغيير الحجم وقتًا أطول. (ثم مرة أخرى، إذا كان لديك قدر كبير من البيانات، فربما لا تحاول تشغيلها في أقل من 4 جيجابايت من ذاكرة الوصول العشوائي).

لا تزال ذاكرة الوصول العشوائي (RAM) بسعة 4 جيجابايت غير كافية في بعض الحالات. على سبيل المثال، لدي مساحة رملية بذاكرة وصول عشوائي (RAM) بسعة 8 جيجابايت مع حركة مرور قليلة جدًا ولكنها إعداد متعدد المواقع للسماح بوجود 5 مساحات رملية يمكن التخلص منها. فشل إعادة البناء اليوم بسبب الخطأ 137 (OOM) وقد جربت الحيلة التي اقترحها @richard أعلاه. ومع ذلك، لتوفير عناء القيام بذلك في كل مرة، قمت بإنشاء مساحة مبادلة أكبر (4 جيجابايت) والتي يبدو أنها سمحت بإعادة البناء في الوقت الحالي. يبدو أننا نقوم فقط بترقية الخوادم في العام الماضي لأن عمليات إعادة بناء discourse تستهلك ذاكرة وصول عشوائي (RAM) بشكل كبير لسبب ما.

مثير للاهتمام. هل لديك إعدادات النواة كما هو موضح في MKJ’s Opinionated Discourse Deployment Configuration؟

(من المفيد دائمًا وجود مساحة تبديل، 2 جيجابايت أو 4 جيجابايت أو أي مساحة قرص حرة تسمح بها. لدي مساحة تبديل دنيا لأن لدي مساحة قرص دنيا.)

بالتفكير في هذا، فإن الفائدة تقتصر حقًا على عمليات إعادة البناء الكاملة - لا يمكنني حاليًا استخدام الترقيات عبر الإنترنت في تكوين 2+2 … ولا أعتقد أنني سأقوم برقصة الترقية/الخفض هذه لمجرد تحديث مكون إضافي واحد على سبيل المثال …

أشعر شخصيًا أن الترقية الدائمة إلى 4 جيجابايت على الأقل هي الطريقة الوحيدة …

ملاحظة: أنا لا أتذمر حقًا بشأن الاضطرار إلى مواكبة العصر … ولكن ربما يجب أن نبدأ في عكس الواقع في الوثائق والنصائح للمسؤولين؟

إنه للأسف يجعل Discourse أقل سهولة قليلاً للأشخاص الجدد، وخاصة الشباب

أنا بالفعل مع هذه الفكرة: احتفظ بالحد الأدنى الحالي للتكوين الموصى به كهدف وابحث عن تعديلات في الكود أو تغييرات في المصدر للحفاظ على الأمور تحت السيطرة. إنه تغيير كبير في العرض إذا كان الحد الأدنى للتكوين الآن ضعف السعر. ولهذا السبب أشرت في مكان آخر إلى أن متطلبات الذاكرة المفرطة هي خطأ.

أواجه الآن ترقيات فاشلة عند محاولة الترقية إلى أحدث إصدار:

...[@embroider/webpack]
Killed
error Command failed with exit code 137.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:210:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:111:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/commands/runner/runner_command.rb:43:in `load'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.2.2/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.2.2/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/thor-1.2.2/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/command/base.rb:87:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/command.rb:48:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/railties-7.0.5.1/lib/rails/commands.rb:18:in `<main>'
internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb:37:in `require'
internal:/usr/local/lib/ruby/site_ruby/3.2.0/rubygems/core_ext/kernel_require.rb:37:in `require'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/bootsnap-1.16.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
bin/rails:18:in `<main>'
Spinning up 1 Unicorn worker(s) that were stopped initially

أفترض أن هذا خطأ نفاد الذاكرة؟ هل يعني هذا أن الأجهزة ذات سعة 1 جيجابايت قد انتهت رسميًا؟

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

تعديل: للتوضيح، الذاكرة = ذاكرة الوصول العشوائي (RAM) + مساحة التبديل (swap). ذاكرة الوصول العشوائي سريعة ومساحة التبديل رخيصة.