مرحباً بالجميع،
لدي بعض الأسئلة حول هذا الخيار. إذن، من الواضح أن هذا الخيار معطل افتراضياً في app.yml و يمكن أن يحسن أداء الفرز، لكنه يزيد من استهلاك الذاكرة لكل اتصال، لكن ماذا يعني ذلك فعلياً؟ هل يعتمد ذلك على عدد الاتصالات؟ ما هو db_work_mem؟ هل يتم تعيينه تلقائياً عند تثبيت Discourse تماماً مثل db_shared_buffers و UNICORN_WORKERS؟ هل تفعيله إجراء أمان أم أنه متقدم؟
يبدو الآن هكذا: #db_work_mem: "40MB"
الخادم هو:
Vultr High Frequency Compute 2 vCore, 4096 MB
شكراً لأي رد! 
هذه مسألة معقدة. يمكنك البحث في توثيق PostgreSQL للحصول على التفاصيل. هناك بعض المواضيع التي تناقش التحسين هنا
تعمل الإعدادات الافتراضية بشكل معقول.
إذا كنت تواجه مشكلة، يمكنك وصف المشكلة وكمية المرور التي تتعامل معها وحجم قاعدة بياناتك.
شكرًا لك يا جاي! في الواقع، أنا مهتم بهذا الأمر فقط. كنت أبحث عن طرق لتحسين أداء المنتدى، ولكن إذا كان ذلك قد يسبب مشاكل، فربما يكون من الأفضل تركه معلقًا (commented out).
إذن، إذا قمت بتفعيله، هل هناك احتمال كبير لنفاد الذاكرة إذا لم يكن الضبط صحيحًا أو إذا زاد حجم الزوار؟ إذا فهمت الأمر بشكل صحيح.
work_mem(integer)يحدد الحد الأقصى الأساسي للذاكرة التي يمكن أن يستخدمها إجراء استعلام (مثل الترتيب أو جدول التجزئة) قبل الكتابة إلى ملفات مؤقتة على القرص. إذا تم تحديد هذه القيمة دون وحدات، فستُعتبر بالكيلوبايت. القيمة الافتراضية هي أربعة ميجابايت (
4MB). لاحظ أنه في حالة الاستعلامات المعقدة، قد يتم تشغيل عدة عمليات ترتيب أو تجزئة بالتوازي؛ فكل عملية يُسمح لها عمومًا باستخدام قدر من الذاكرة يوازي هذه القيمة قبل أن تبدأ في كتابة البيانات إلى ملفات مؤقتة. بالإضافة إلى ذلك، قد تقوم عدة جلسات نشطة بهذه العمليات في وقت واحد. لذلك، قد يكون إجمالي الذاكرة المستخدمة أكبر بكثير من قيمةwork_mem؛ ومن الضروري مراعاة هذه الحقيقة عند اختيار القيمة. تُستخدم عمليات الترتيب فيORDER BYوDISTINCTوالعمليات الاندماجية (merge joins). أما جداول التجزئة فتُستخدم في عمليات الاندماج التجزئي (hash joins)، والتجميع القائم على التجزئة، ومعالجة استعلاماتINالقائمة على التجزئة.عمليات التجزئة عمومًا أكثر حساسية لتوفر الذاكرة مقارنة بالعمليات المكافئة القائمة على الترتيب. يتم حساب الذاكرة المتاحة لجداول التجزئة عن طريق ضرب
work_memفيhash_mem_multiplier. وهذا يسمح للعمليات القائمة على التجزئة باستخدام كمية من الذاكرة تتجاوز المبلغ الأساسي المعتاد لـwork_mem.
في بعض الأحيان، يساعد زيادة ذاكرة العمل إلى ضعف القيمة الافتراضية المعلق عليها. أعتقد أن ذلك مفيد في المواقع الكبيرة حيث تكون الفهارس كبيرة، لكنني لست متأكداً في الغالب. لقد تسببت في تعطل موقع عن طريق رفع القيمة إلى حد مرتفع جداً.
إذا كنت ترغب في تجربة ضبط الإعدادات، يمكنك الاطلاع على إضافة Prometheus وإنشاء رسوم بيانية جميلة باستخدام Grafana.
وجدت هذه الصيغة لحساب db_work_mem.
بشكل افتراضي، يتم تعيينها لـ 100 اتصال.
إجمالي الذاكرة العشوائية * 0.25 / max_connections
لدي 4096 ميجابايت * 0.25 / 100 = ~10 ميجابايت
في قالب postgres.template.yml، القيمة الافتراضية لـ db_work_mem: "10MB"، لذا أعتقد أنها تحسب بهذه الصيغة. أعتقد أن هذه الـ 10 ميجابايت هي الحد الأقصى حاليًا. شكرًا لك جاي