التحديث يستغرق حوالي 20 دقيقة وتوقفات تحديث التقدم (مؤقتًا) عند خطوة multisite:migrate

الدعم
1

لقد أجريت التحديث الأسبوعي لموقع Discourse الخاص بنا، ووجدت أنه بدلاً من أن يستغرق 1-2 دقيقة كالمعتاد، فقد استغرق الأمر 20 دقيقة هذه المرة. كما أن تحديث التقدم تعطل مؤقتًا مع أخطاء مهلة في وحدة تحكم Chrome في الخطوة $ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate (لقطة الشاشة أدناه).

لقد تمكنت من رؤية ما كان يحدث على الخادم (ضغط على postmaster وأحيانًا على ruby)، وفي النهاية استؤنف تحديث التقدم، ولكن بشكل عام يبدو أن هناك مشكلة محتملة مع عمليات الترحيل الحالية.

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

image
image947×718 61.2 KB

********************************************************
*** Please be patient, next steps might take a while ***
********************************************************
...
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-bbcode is already at latest compatible version
discourse-data-explorer is already at latest compatible version
docker_manager is already at latest compatible version
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
Multisite migrator is running using 1 threads

Migrating default
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: migrating ==========
-- execute("DELETE FROM site_settings WHERE name = 'user_search_similar_results';\n")
   -> 0.0006s
== 20240912061702 DropUserSearchSimilarResultsSiteSetting: migrated (0.0015s) =

== 20240912061806 DropTrgmIndexesOnUsers: migrating ===========================
-- execute("DROP INDEX IF EXISTS index_users_on_username_lower_trgm;\nDROP INDEX IF EXISTS index_users_on_name_trgm;\n")
   -> 1290.7163s
== 20240912061806 DropTrgmIndexesOnUsers: migrated (1290.7169s) ===============

== 20240912212253 IncreaseExternalAvatarUrlLimitTo2000: migrating =============
-- change_column(:single_sign_on_records, :external_avatar_url, :string, {:limit=>2000})
   -> 0.0011s
== 20240912212253 IncreaseExternalAvatarUrlLimitTo2000: migrated (0.0017s) ====

Seeding default
*** Bundling assets. This will take a while *** 
$ bundle exec rake themes:update assets:precompile
Building
Environment: production
building...
...

السجل الكامل: upgrade-log-2024-09-15.txt (124.7 KB)

3

لست متأكدًا من وجود أي شيء يمكننا فعله الآن.

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

هل نفترض أن كل شيء على ما يرام الآن؟

4

نعم، عادت الأمور إلى طبيعتها الآن، لذلك لا توجد مشكلة فورية.

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

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

لذلك السؤال الآخر الذي خطر ببالي لاحقًا هو: هل يتطلب Discourse فعليًا قرص SSD للمجتمعات مثلنا (حوالي 6 آلاف مستخدم، حوالي 2.5 مليون مشاركة)؟ لأن الخادم الحالي لائق (AMD Ryzen 5 3600، 64 جيجابايت من ذاكرة الوصول العشوائي)، ولكنه يحتوي على أقراص دوارة كلاسيكية وإذا كانت هذه مشكلة، فسنحتاج إلى التبديل إلى قرص SSD قبل أن نبدأ العمل.

5

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

6

حسنا، شكرا! لم أكن على علم بأن ضبط قاعدة البيانات سيكون مطلوبًا (نحن نستخدم إعداد الحاوية الواحدة) ولا يوجد الكثير قيد التشغيل على الجهاز (Discourse، Mailcow، Traefik، Crowdsec). لكنني سألقي نظرة فاحصة.
هل هناك أي إرشادات للوثائق ذات الصلة في هذا الصدد؟ الشيء الوحيد الذي أعرفه حاليًا هو https://meta.discourse.org/t/configure-discourse-docker-on-servers-with-more-ram-and-cpu/18569، و db_shared_buffers لدينا بالفعل عند 4096MB.

7

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

يقوم DROP INDEX العادي بالحصول على قفل ACCESS EXCLUSIVE على الجدول، مما يمنع الوصول الآخر حتى يكتمل إسقاط الفهرس.

يجب إصلاح هذا في PERF: Update migration to drop index concurrently. by tgxworld · Pull Request #28955 · discourse/discourse · GitHub.

@schneeland شكراً لك على تخصيص الوقت للإبلاغ عن المشكلة :+1:

إعجابَين (2)