إذًا، شكرًا جزيلاً! يبدو أن إيقاف الخدمات يدويًا داخل الحاوية قد نجح، وتمكنت من إعادة بناء الحاوية المزدوجة للترقية (مع تعديل متغيرات اللغة كما نوقش أعلاه - ملاحظة جانبية: لقد اطلعت على وثائق التثبيت ولا أعتقد أنها تذكر اللغات؛ ربما يكون هذا إضافة جيدة).
للأسف، كان تحليل العمليات الإشكالية غير حاسم. الشيء الوحيد الذي أراه هو أشياء متعلقة بـ Postgres مثل WalWriter و AutoVacuum وما إلى ذلك. الدليل الوحيد لدي هو أنه عندما أقوم بإعادة تشغيل النظام وأيضًا بعد تغييرات الفهرس عند التحديثات، أرى عادةً حمل وحدة معالجة مركزية مرتفع لـ Postgres لمدة نصف ساعة تقريبًا.
وعندما تحققت من pg_stat_activity اليوم بعد إعادة التشغيل، رأيت استعلامين طويلين الأمد (على الأقل إذا كان فهمي للأعمدة صحيحًا):
SELECT "posts"."id" FROM "posts" INNER JOIN "topics" ON "topics"."deleted_at" IS NULL AND "topics"."id" = "posts"."topic_id" LEFT JOIN post_search_data ON post_id = posts.id WHERE "posts"."deleted_at" IS NULL AND (posts.raw != '') AND (topics.deleted_at IS NULL) AND (post_search_data.locale IS NULL OR post_search_data.locale != 'de' OR post_search_data.version != 5) ORDER BY posts.id DESC LIMIT 20000
و
SELECT "optimized_images".* FROM "optimized_images" WHERE "optimized_images"."upload_id" = 13 AND "optimized_images"."height" = 32 AND "optimized_images"."width" = 32 LIMIT 1
بعد الـ 30 دقيقة المذكورة، اكتمل الاستعلام الأول على ما يبدو وأصبح حمل وحدة المعالجة المركزية من Postgres طبيعيًا الآن.
لست متأكدًا من سبب استغراق هذين الاستعلامين وقتًا طويلاً، والأقل من ذلك سبب ظهور الاستعلام الثاني في pg_stat_activity بعد أكثر من ساعة، ولكن ربما تكون مثل هذه الاستعلامات طويلة الأمد قد منعت خدمة Postgres من الإغلاق بشكل صحيح عند محاولة إعادة بنائها سابقًا.
إذا كان لديك أي فكرة هنا، فسيكون ذلك محل تقدير كبير. ولكن ربما يكون هذا أيضًا شيئًا قد يدخل في موضوع آخر (إذا كان الأمر كذلك، فقط أخبرني، وسأقوم بتحرير هذا المنشور).
لقطات شاشة ذات صلة:
