تحسين الأداء، ماذا عن max_wal_size؟

مرحباً،

كان آخر تحديث من الإصدار التجريبي 3 إلى الإصدار التجريبي 4 أكثر “تعقيدًا” من المعتاد بالنسبة لنا وظهر شيء مثل ما يلي بسبب السجلات:
ضع في اعتبارك زيادة معلمة التكوين "max_wal_size".

نظرًا لأنني لست خبيرًا في هذا الشأن، فقد أظهر البحث على جوجل أن هذه المعلمة max_wal_size يمكن أن تكون مهمة جدًا للأداء (تأتي في المرتبة الثانية بعد shared_buffers وفقًا للبعض، انظر أدناه):
ضبط max_wal_size في PostgreSQL | EDB (enterprisedb.com)
ضبط قاعدة بيانات Postgres الخاصة بك لأحمال الكتابة العالية (crunchydata.com)
دليل ضبط وتحسين أداء PostgreSQL - Sematext

أي آراء حول هذا؟ هل يجب تغيير معلمة max_wal_size حتى لو حدث هذا فقط أثناء التحديث؟

للسياق، لدينا منتدى كبير به أكثر من 7 ملايين مشاركة، يستهلك الكثير من الموارد، عدة مرات في الأسبوع مع 400-600 مستخدم متزامن يقومون بالتحديث والنشر والقيام بكل شيء في نفس الوقت. لا توجد مشاكل مع ذلك، :smiley: ولكن في بعض الأحيان نضطر إلى التحسين ومحاولة الحصول على أفضل أداء ممكن لمواردنا (المحدودة).

إعجاب واحد (1)

ما هي قيمة تشغيل SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter; مقابل قاعدة البيانات؟

دعنا نرى ما إذا كنت قد فهمت الأمر بشكل صحيح:

SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter; 
checkpoints_timed | checkpoints_req 
-------------------+-----------------
              4936 |             225
(1 row) 
إعجاب واحد (1)

يبدو أن السبب كان في الغالب بسبب عمليات الترحيل أثناء التحديث، وعلى أساس يومي المنتدى على ما يرام.

لقد قمنا بترحيل بعض عمليات الترحيل الثقيلة هذا الشهر، هل لديك سجل إعادة البناء الخاص بك حولك؟

إعجابَين (2)

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

إعجاب واحد (1)