rake:rebake يتعطل مع أخطاء: PG::ConnectionBad: PQsocket

[j127]

لقد قمت بترحيل منتدى يحتوي على 200,000 مشاركة إلى خادم جديد. تم وضع الموقع المباشر في وضع القراءة فقط حتى لا يكون هناك وقت تعطل.

لقد قمت باستعادة النسخة الاحتياطية على نطاق فرعي مختلف حتى لا يرى المستخدمون شاشات التثبيت أو أي مشاكل قد تحدث أثناء الاستعادة - شيء مثل dev.example.com.

بمجرد اكتمال الاستعادة، قمت بتوجيه نظام أسماء النطاقات (DNS) إلى الخادم الجديد وغيرت النطاق في ملف app.yml إلى forum.example.com العادي.

بعد ذلك، كانت جميع الرموز التعبيرية في المشاركات الأساسية تشير إلى خادم dev.example.com، لذلك قمت بتشغيل rake:rebake.

لقد تمكن من معالجة حوالي 1,000-2,000 مشاركة قبل أن يتعطل مع أخطاء حول اتصال قاعدة البيانات.

إليك بعض المقتطفات:

/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/cli.rb:34:in `dispatch'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/cli.rb:28:in `start'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/exe/bundle:45:in `block in <top (required)>'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/exe/bundle:33:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
     1999 / 200968 (  1.0%)
Failed to rebake (topic_id: 78730, post_id: 210607)
PG::ConnectionBad: PQsocket() can't get socket descriptor

/var/www/discourse/lib/tasks/posts.rake:108:in `rebake_posts_all_sites'
/var/www/discourse/lib/tasks/posts.rake:7:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'

Caused by:
PG::ConnectionBad: PQsocket() can't get socket descriptor

في الوقت الحالي، أقوم بتحميل الصور عن طريق إعادة توجيه النطاق dev.example.com إلى النطاق forum.example.com، ولكنه مجرد حل مؤقت.

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

[pfaffman (Jay Pfaffman)]

أولاً، انظر تغيير اسم النطاق أو إعادة تسمية Discourse (على الرغم من أن هناك حلاً آخر وهو النسخ الاحتياطي ثم الاستعادة باستخدام اسم المضيف الجديد).\n\nتخميني هو أنك تنفد اتصالات قاعدة البيانات، ولكن هذا ليس الخطأ السريع الذي أتوقعه.\n\nهل هذا تثبيت قياسي أم أنك تستخدم خادم PG آخر؟

[j127]

شكراً على الروابط. إنه تثبيت Docker قياسي على DigitalOcean droplet (“Premium AMD”، 4 جيجابايت من ذاكرة الوصول العشوائي، 2 vCPUs).

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

ثم قمت بتشغيل هذا النوع من الأوامر:

discourse remap dev.example.com forum.example.com

تعطل هذا الأمر مع هذا النوع من الأخطاء:

Error: ERROR:  duplicate key value violates unique constraint "unique_post_links"
DETAIL:  Key (topic_id, post_id, url)=(78821, 207117, https://forum.example.com/t/the-slug/78946/7) already exists.

لذلك قمت بحذف منشور مؤقتًا كان يربط بعنوان URL المذكور (https://forum.example.com/t/the-slug/78946/7)، وقمت بتشغيل الأمر مرة أخرى، وعمل دون تعطل.

ثم قمت بتشغيل rake posts:rebake مرة أخرى.

فشل في عدد قليل من المشاركات مثل هذه، لكنه استمر (لقد قمت بإعادة بناء HTML لهذه المشاركات يدويًا):

Rebaking post markdown for 'default'
     2273 / 200996 (  1.1%)
Failed to rebake (topic_id: 66586, post_id: 210353)
JavaScript was terminated (either by timeout or explicitly)

أخيرًا، تعطل قبل أن يصل إلى 11000 مشاركة بأخطاء مثل هذه:

/usr/local/bin/bundle:25:in `<main>'
    10996 / 200996 (  5.5%)
Failed to rebake (topic_id: 76678, post_id: 200988)
PG::ConnectionBad: PQsocket() can't get socket descriptor
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:69:in `exec_params'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:69:in `exec_params'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/activerecord-7.0.4.1/lib/active_record/connection_adapters/postgresql_adapter.rb:768:in `block (2 levels) in exec_no_cache'

بدا أن الخادم بأكمله قد توقف عن العمل لأن Uptime Robot أبلغني أن الموقع معطل.

هل تعتقد أن الخادم ليس قويًا بما يكفي لتشغيل هذا الأمر؟

إنه يعمل بنسبة تزيد عن 80٪ من ذاكرة الوصول العشوائي بشكل طبيعي، ويصل إلى 100٪ أثناء تشغيل الأمر. ربما نفدت الذاكرة.

[Ed_S]

إذا كان لديك قرص محلي، يمكنك إضافة مساحة مبادلة (swap)، مما قد يجنبك استنفاد الذاكرة (سواء كان هذا هو سبب المشكلة هنا أم لا). ماذا يظهر لك الأمر free؟ هل ترى oom أو memory في مخرجات الأمر dmesg؟

[j127]

@Ed_S

ماذا يخبرك الأمر free؟

في الوقت الحالي، يظهر:

              total        used        free      shared  buff/cache   available
Mem:           3.8Gi       2.1Gi       160Mi       1.0Gi       1.6Gi       488Mi
Swap:             0B          0B          0B

@Ed_S

هل ترى oom أو memory في مخرجات الأمر dmesg؟

لا أرى oom، ولكن كلمة memory تظهر في بضعة أماكن تتعلق بحجز الذاكرة وتحريرها.

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

[Ed_S]

إذا كانت لديك مساحة القرص، فمن المؤكد أنه يستحق إضافة 2 جيجابايت من مساحة التبديل.

الشيء الآخر الذي يجب فعله هو مراقبة الاستخدام أثناء تشغيل وظيفتك الكبيرة. سأستخدم vmstat 5 5 وربما أسجل في ملف. أنت تأمل ألا ترى قيمًا كبيرة في أعمدة si أو so، وألا ترى عمود swpd يقترب من حجم مساحة التبديل الخاصة بك.

ربما انظر إلى هذا المنشور:

@Ed_S

لمحاولة التقاط الموقف عن قرب فشله، استخدمت vmstat 5

(يبدو من الممكن أن نظام قاعدة البيانات ينفد من بعض الموارد، لكنني لا أعرف شيئًا عن ذلك.)

[j127]

شكرًا لك، سأجرب هذه الأشياء لاحقًا اليوم. لدي 50 جيجابايت مجانية في الوقت الحالي.

[j127]

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

شكراً لكما على مساعدتكما.

[Ed_S]

يبدو جيدًا! فقط للتسجيل

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

[j127]

@Ed_S

ربما يمكنك إجراء ترقية مؤقتة قابلة للعكس إلى مثيل ذاكرة وصول عشوائي أكبر

فكرت في الأمر، لكن كان عليّ إيقاف تشغيل الخادم، وكان المستخدمون قد مروا بالفعل بفترة “للقراءة فقط” مزعجة ووقت تعطل عندما نقلت الخوادم.

لم أتمكن من الانتهاء منه الليلة الماضية لأنني اضطررت للذهاب إلى النوم، ولكنه يعمل مرة أخرى الآن. 30% حتى الآن بدون أي أخطاء.

[Ed_S]

راقب الأمور باستخدام vmstat أو ما شابه - هذه مهمة طويلة جدًا، لا تريد الاضطرار إلى إعادة تشغيلها. ربما أضيف 2 جيجابايت أخرى من الـ swap، لضمان الأمان.

[j127]

شكرًا، لقد تحققت باستخدام vmstat بشكل متقطع. لقد بدأته في جلسة tmux حتى أتمكن من الانفصال وإغلاق جهاز الكمبيوتر المحمول الخاص بي لفترة من الوقت. ربما استغرق الأمر 8-9 ساعات لتشغيل الأمر، ولكن كل شيء اكتمل بدون أخطاء.