بينما سارت الأمور بشكل عام على ما يرام، رأيت مشاكل تظهر بعد ذلك مع عمليات بوستجريس التي تعمل بشكل جامح وتستخدم 100٪ من نواة واحدة. أعداد متفاوتة من العمليات على الرغم من ذلك. حاولت بعض الأشياء من إعادة البناء إلى إعادة التشغيل. حاليًا أحاول تشغيل rake db:validate_indexes الذي يعمل بالفعل لبضع ساعات دون أي ردود فعل. لست متأكدًا مما إذا كنت قد فعلت هذا من قبل وما إذا كان من المفترض أن يحدث بشكل أسرع.
استخدام المنتدى يعمل بشكل جيد بشكل أساسي ولكنه بالتأكيد أبطأ. بعض المهام التي تستغرق وقتًا طويلاً مثل سحب ملفات تعريف المستخدمين للمستخدمين الأكثر نشاطًا يستغرق وقتًا أطول بشكل ملحوظ من المعتاد.
أنا متأكد تمامًا من وجود بعض المشاكل مع قاعدة البيانات ولكنني أواجه صعوبة في معرفة أي منها.
يجب أن أقول إن قاعدة بياناتنا ضخمة جدًا - نحن عند حوالي 150 جيجابايت بعد الاستعادة وبعد إنشاء الفهرس. من مراقبة عملية الاستعادة لم أر أي أخطاء وكان إنشاء الفهرس يسير على ما يرام في نظري.
أي فكرة حول كيفية معالجة هذا؟ إنها 3 عمليات بوستجريس في الوقت الحالي - كانت 6 قبل إعادة تشغيل قمت بها قبل بضع ساعات - لقد رأيت بالفعل استخدام جميع النوى الـ 16 بعد الاستعادة أيضًا.
تعديل: لاحظت للتو الآن أن 3 عمليات سايدكيق مشغولة بـ “فهرسة الفئات للبحث”. هل يمكن أن يكون كل هذا مجرد إعادة بناء فهرس البحث؟ إذا كان الأمر كذلك، فهل يمكن حل هذا بطريقة أخرى؟ عندما نقوم باستعادة النظام المباشر، ستكون هذه مشكلة كبيرة إذا أدت إلى تدهور الأداء بهذه الطريقة على مدى ساعات أو حتى أيام.
في الوقت الحالي، هناك مهمة sidekiq واحدة فقط تعمل مع “Jobs::BackfillBadge” ولكن لا تزال 7 عمليات postgres تسد وحدة المعالجة المركزية بنسبة 100% باستمرار. فضولي حقًا لمعرفة ما يحدث هناك.
لست متأكداً مما إذا كان يقوم بشيء ما ولكنه موجود هناك لمدة 30 دقيقة بالفعل.
لقد وضعت المنتدى للقراءة فقط وأعدت تشغيل الجهاز الافتراضي لإنهاء عمليات Postgres السبع التي كانت “عالقة” هناك من قبل. بعد فترة وجيزة من إعادة التشغيل، عادت عمليتا Postgres هاتان ولم تتغيرا. لا شيء يعمل حاليًا في sidekiq.
آها! نصيحة معقولة من خبير! لذا ربما كنت على حق في أن 8 جيجابايت / 25٪ ليست كافية، وعلى الرغم من أن 16 جيجابايت أكثر من 40٪، إلا أنها قد تكون لا تزال اقتراحًا جيدًا لأن . . . .
يا شباب. كما ذكرت، هذا خادم اختبار - لا يوجد عليه أي حركة مرور. هذا الخادم بالتأكيد ليس جيدًا بما يكفي للاستخدام الإنتاجي ولكن هذه ليست المشكلة هنا. السؤال هو لماذا نرى عمليات postgres عالقة بهذه الطريقة (باستخدام 100٪ من وحدة المعالجة المركزية) وتبطئ الأمور بشكل كبير. كنا نشغل خادم الاختبار بسعة أقل حتى قبل أيام قليلة - تم زيادته فقط بسبب نقص مساحة القرص للاستعادة.
تعمل آلة الإنتاج بذاكرة وصول عشوائي (RAM) بسعة 128 جيجابايت مع نفس إعدادات المخزن المؤقت المشترك دون أي مشاكل - لذلك لا أعتقد أن هناك مشكلة عامة في هذه الإعدادات وحجم المخزن المؤقت المشترك - خاصة ليس جهاز اختبار خاص بدون حركة مرور.
ولكن على أي حال - سأقوم فقط بإعادة إجراء الاستعادة ومعرفة ما إذا كان قد حدث خطأ ما حيث يبدو أنه لا يوجد تفسير جيد للسلوك.
توصي Postgres