مشاركة عبر

الضبط التلقائي في قاعدة بيانات Azure ل PostgreSQL - الخادم المرن

  • مقالة

ينطبق على: قاعدة بيانات Azure ل PostgreSQL - خادم مرن

توفر هذه المقالة نظرة عامة على ميزة الإخلاء التلقائي لقاعدة بيانات Azure لخادم PostgreSQL المرن وأدلة استكشاف الأخطاء وإصلاحها للميزة المتوفرة لمراقبة انتفاخ قاعدة البيانات وحظر الإخلاء التلقائي. كما يوفر معلومات حول مدى مسافة قاعدة البيانات عن حالة الطوارئ أو الالتفاف.

ما التفريغ التلقائي

Autovacuum هي عملية خلفية PostgreSQL تقوم تلقائيا بتنظيف المجموعات الميتة وتحديث الإحصائيات. يساعد على الحفاظ على أداء قاعدة البيانات عن طريق تشغيل مهمتي صيانة رئيسيتين تلقائيا:

  • فراغ - يحرر مساحة على القرص عن طريق إزالة المجموعات الميتة.
  • ANALYZE - يجمع الإحصائيات لمساعدة محسن PostgreSQL على اختيار أفضل مسارات التنفيذ للاستعلامات.

لضمان عمل الإخلاء التلقائي بشكل صحيح، يجب دائما تعيين معلمة خادم الإخلاء التلقائي إلى ON. عند التمكين، يقرر PostgreSQL تلقائيا متى يتم تشغيل فراغ أو تحليل على جدول، ما يضمن بقاء قاعدة البيانات فعالة ومحسنة.

التفريغ التلقائي الداخلي

يقرأ Autovacuum الصفحات التي تبحث عن المجموعات الميتة، وإذا لم يتم العثور على أي منها، فإن الإخلاء التلقائي يتجاهل الصفحة. عندما يعثر التفريغ التلقائي على مجموعات خامدة، فإنه يزيلها. تستند التكلفة إلى:

المعلمة ‏‏الوصف‬
vacuum_cost_page_hit تكلفة قراءة صفحة موجودة بالفعل في المخازن المؤقتة المشتركة ولا تحتاج إلى قراءة قرص. تعيَّن القيمة الافتراضية على 1.
vacuum_cost_page_miss تكلفة إحضار صفحة غير موجودة في المخازن المؤقتة المشتركة. تعيَّن القيمة الافتراضية على 10.
vacuum_cost_page_dirty تكلفة الكتابة إلى صفحة عند العثور على مجموعات ميتة فيها. تعيَّن القيمة الافتراضية على 20.

يعتمد مقدار الإخلاء التلقائي للعمل على معلمتين:

المعلمة ‏‏الوصف‬
autovacuum_vacuum_cost_limit مقدار الإخلاء التلقائي للعمل يتم في مدة واحدة.
autovacuum_vacuum_cost_delay عدد المللي ثانية التي يكون الإخلاء التلقائي نائما بعد أن يصل إلى حد التكلفة المحدد بواسطة المعلمة autovacuum_vacuum_cost_limit .

في جميع الإصدارات المدعومة حاليا من Postgres، تكون القيمة الافتراضية ل autovacuum_vacuum_cost_limit هي 200 (في الواقع، تعيين إلى -1، ما يجعلها مساوية لقيمة العادية vacuum_cost_limit، والتي تكون افتراضيا 200).

بالنسبة إلى autovacuum_vacuum_cost_delay، في إصدار Postgres 11، يتم تعيينه افتراضيا إلى 20 مللي ثانية، بينما في إصدارات Postgres 12 وما فوقه يتم تعيينه افتراضيا إلى 2 مللي ثانية.

يقوم التفريغ التلقائي بالتنشيط 50 مرة (50*20 ms=1000 ms) كل ثانية. في كل مرة ينشط فيها التفريغ التلقائي، فإنه يقرأ 200 صفحة.

وهذا يعني أنه يمكن إجراء التفريغ التلقائي في ثانية واحدة:

  • ~80 MB/Sec [ (200 صفحة/vacuum_cost_page_hit) * 50 * 8 KB لكل صفحة] إذا تم العثور على جميع الصفحات ذات المجموعات الخامدة في المخازن المؤقتة المشتركة.
  • ~8 MB/Sec [ (200 صفحة/vacuum_cost_page_miss) * 50 * 8 KB لكل صفحة] إذا تمت قراءة جميع الصفحات ذات المجموعات الخامدة من القرص.
  • ~4 MB/Sec [ (200 صفحة/vacuum_cost_page_dirty) * 50 * 8 KB لكل صفحة] يمكن أن يكتب التفريغ التلقائي ما يصل إلى 4 MB/sec.

مراقبة الإخلاء التلقائي

استخدم الاستعلامات التالية لمراقبة التفريغ التلقائي:

select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;

تساعد الأعمدة التالية في تحديد ما إذا كان التفريغ التلقائي يصل إلى نشاط الجدول:

المعلمة ‏‏الوصف‬
dead_pct النسبة المئوية للمجموعات الميتة بالمقارنة مع المجموعات الحية.
last_autovacuum تاريخ آخر مرة تم فيها إخلاء الجدول تلقائيا.
last_autoanalyze تاريخ آخر مرة تم فيها تحليل الجدول تلقائيا.

متى يحدث التفريغ التلقائي لمشغل PostgreSQL

يتم تشغيل إجراء التفريغ التلقائي (إما من ANALYZE أو VACUUM) عندما يتجاوز عدد المجموعات الخامدة عدداً معيناً يعتمد على عاملين: العدد الإجمالي للسجلات في أحد الجداول، بالإضافة إلى حد التصحيح. يتم تشغيل ANALYZE، بشكل افتراضي، عند تغيير 10٪ من الجدول بالإضافة إلى 50 صفا، بينما يتم تشغيل فراغ عند تغيير 20٪ من الجدول بالإضافة إلى 50 صفا. نظرا لأن عتبة فراغ تصل إلى ضعف عتبة ANALYZE ، يتم تشغيل ANALYZE قبل فراغ. لإصدارات >PG =13؛ يتم تشغيل ANALYZE بشكل افتراضي عند إدراج 20٪ من الجدول بالإضافة إلى 1000 صف.

المعادلات الدقيقة لكل إجراء هي:

  • Autoanalyze = autovacuum_analyze_scale_factor * المجموعات + autovacuum_analyze_threshold أو autovacuum_vacuum_insert_scale_factor * المجموعات + autovacuum_vacuum_insert_threshold (لإصدارات >PG = 13)
  • Autovacuum = autovacuum_vacuum_scale_factor * tuples + autovacuum_vacuum_threshold

على سبيل المثال، إذا كان لدينا جدول يحتوي على 100 صف. ثم توفر المعادلة التالية معلومات حول وقت تشغيل التحليل والتفريغ:

للحصول على التحديثات/الحذف: Autoanalyze = 0.1 * 100 + 50 = 60
Autovacuum = 0.2 * 100 + 50 = 70

تحليل المشغلات بعد تغيير 60 صفا على جدول، ومشغلات فراغ عند تغيير 70 صفا على جدول.

بالنسبة للإدخالات: Autoanalyze = 0.2 * 100 + 1000 = 1020

تحليل المشغلات بعد إدراج 1020 صفا في جدول

فيما يلي وصف المعلمات المستخدمة في المعادلة:

المعلمة ‏‏الوصف‬
autovacuum_analyze_scale_factor النسبة المئوية لعمليات الإدراج/التحديثات/الحذف التي تؤدي إلى تشغيل ANALYZE على الجدول.
autovacuum_analyze_threshold تحديد الحد الأدنى لعدد المجموعات المدرجة/المحدثة/المحذوفة لتحليل جدول.
autovacuum_vacuum_insert_scale_factor النسبة المئوية لعمليات الإدراج التي تؤدي إلى تشغيل ANLYZE على الجدول.
autovacuum_vacuum_insert_threshold تحديد الحد الأدنى لعدد المجموعات المدرجة لتحليل جدول.
autovacuum_vacuum_scale_factor النسبة المئوية للتحديثات/الحذف التي تؤدي إلى تشغيل فراغ على الجدول.

استخدم الاستعلام التالي لسرد الجداول في إحدى قواعد البيانات وحدد الجداول المؤهلة لعملية التفريغ التلقائي:

 SELECT *
      ,n_dead_tup > av_threshold AS av_needed
      ,CASE
        WHEN reltuples > 0
          THEN round(100.0 * n_dead_tup / (reltuples))
        ELSE 0
        END AS pct_dead
    FROM (
      SELECT N.nspname
        ,C.relname
        ,pg_stat_get_tuples_inserted(C.oid) AS n_tup_ins
        ,pg_stat_get_tuples_updated(C.oid) AS n_tup_upd
        ,pg_stat_get_tuples_deleted(C.oid) AS n_tup_del
        ,pg_stat_get_live_tuples(C.oid) AS n_live_tup
        ,pg_stat_get_dead_tuples(C.oid) AS n_dead_tup
        ,C.reltuples AS reltuples
        ,round(current_setting('autovacuum_vacuum_threshold')::INTEGER + current_setting('autovacuum_vacuum_scale_factor')::NUMERIC * C.reltuples) AS av_threshold
        ,date_trunc('minute', greatest(pg_stat_get_last_vacuum_time(C.oid), pg_stat_get_last_autovacuum_time(C.oid))) AS last_vacuum
        ,date_trunc('minute', greatest(pg_stat_get_last_analyze_time(C.oid), pg_stat_get_last_autoanalyze_time(C.oid))) AS last_analyze
      FROM pg_class C
      LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
      WHERE C.relkind IN (
          'r'
          ,'t'
          )
        AND N.nspname NOT IN (
          'pg_catalog'
          ,'information_schema'
          )
        AND N.nspname !~ '^pg_toast'
      ) AS av
    ORDER BY av_needed DESC ,n_dead_tup DESC;

إشعار

لا يأخذ الاستعلام في الاعتبار أنه يمكن تكوين الإخلاء التلقائي على أساس كل جدول باستخدام الأمر "تغيير الجدول" DDL.

مشكلات التفريغ التلقائي الشائعة

راجع القائمة التالية للمشاكل الشائعة المحتملة في عملية الإخلاء التلقائي.

عدم مواكبة الخادم المشغول

تقدر عملية التفريغ التلقائي تكلفة كل عملية إدخال/إخراج، وتجمع إجمالي كل عملية تقوم بها وتتوقف مؤقتاً بمجرد الوصول إلى الحد الأعلى للتكلفة. autovacuum_vacuum_cost_delay وautovacuum_vacuum_cost_limit هما معلمتي الخادم المستخدمتين في العملية.

بشكل افتراضي، يتم تعيين autovacuum_vacuum_cost_limit إلى –1، ما يعني أن حد تكلفة التفريغ التلقائي هو نفس قيمة المعلمة vacuum_cost_limit، والتي يتم تعيينها افتراضياً إلى 200. vacuum_cost_limit هو تكلفة التفريغ اليدوي.

إذا autovacuum_vacuum_cost_limit تم تعيين إلى -1، فإن autovacuum يستخدم المعلمة vacuum_cost_limit ، ولكن إذا تم autovacuum_vacuum_cost_limit تعيين نفسه إلى أكبر من -1 ثم autovacuum_vacuum_cost_limit يتم النظر في المعلمة.

في حالة عدم متابعة الإخلاء التلقائي، قد يتم تغيير المعلمات التالية:

المعلمة ‏‏الوصف‬
autovacuum_vacuum_cost_limit افتراضي: 200. قد يتم زيادة حد التكلفة. يجب مراقبة استخدام CPU والإدخال/الإخراج في قاعدة البيانات قبل إجراء التغييرات وبعدها.
autovacuum_vacuum_cost_delay إصدار Postgres 11 - الافتراضي: 20 ms. قد يتم تقليل المعلمة إلى 2-10 ms.
إصدارات Postgres Versions 12 وما يليها - Default: 2 ms.

إشعار

  • autovacuum_vacuum_cost_limit يتم توزيع القيمة بشكل متناسب بين عمال الإخلاء التلقائي قيد التشغيل، بحيث إذا كان هناك أكثر من واحد، فإن مجموع الحدود لكل عامل لا يتجاوز قيمة المعلمةautovacuum_vacuum_cost_limit.
  • autovacuum_vacuum_scale_factor هي معلمة أخرى يمكن أن تؤدي إلى تفريغ على جدول استنادا إلى تراكم المجموعة الميتة. الافتراضي: 0.2، النطاق المسموح به: 0.05 - 0.1. يختص عامل المقياس بحمل العمل ويجب تعيينه اعتماداً على كمية البيانات في الجداول. وقبل تغيير القيمة، تحقق من حمل العمل ووحدات تخزين الجدول الفردية.

تشغيل التفريغ التلقائي باستمرار

قد يؤثر تشغيل الإخلاء التلقائي باستمرار على استخدام وحدة المعالجة المركزية و IO على الخادم. فيما يلي بعض الأسباب المحتملة:

maintenance_work_mem

يستخدم البرنامج الخفي للتفريغ التلقائي autovacuum_work_mem الذي يتم تعيينه افتراضياً إلى -1 أي أن autovacuum_work_mem سيكون له نفس قيمة المعلمة maintenance_work_mem. يفترض هذا المستند أنه تم تعيين autovacuum_work_mem إلى -1 بينما يستخدم البرنامج الخفي للتفريغ الذاتي maintenance_work_mem.

إذا كان maintenance_work_mem منخفضا، فقد يتم زيادته إلى ما يصل إلى 2 غيغابايت على قاعدة بيانات Azure لخادم PostgreSQL المرن. تتمثل إحدى القواعد العامة لعنصر التحكم المصغر في تخصيص 50 MB لـ maintenance_work_mem لكل 1 GB من ذاكرة RAM.

عدد قواعد البيانات الكبير

يحاول التفريغ التلقائي بدء تشغيل عامل على كل قاعدة بيانات كل autovacuum_naptime ثانية.

على سبيل المثال، إذا كان الخادم يحتوي على 60 قاعدة بيانات وتم autovacuum_naptime تعيينه إلى 60 ثانية، فسيبدأ عامل الإخلاء التلقائي كل ثانية [autovacuum_naptime/عدد قواعد البيانات].

من الجيد زيادتها autovacuum_naptime إذا كان هناك المزيد من قواعد البيانات في نظام المجموعة. وفي الوقت نفسه، يمكن جعل عملية التفريغ التلقائي أكثر دقة عن طريق زيادة autovacuum_cost_limit وتقليل المعلمات autovacuum_cost_delay وزيادة autovacuum_max_workers من الإعداد الافتراضي 3 إلى 4 أو 5.

أخطاء نفاد الذاكرة

يمكن أن تتسبب قيم maintenance_work_mem الدقيقة بشكل دوري في حدوث أخطاء نفاد الذاكرة في النظام. من المهم فهم ذاكرة الوصول العشوائي المتوفرة على الخادم قبل إجراء أي تغيير على المعلمة maintenance_work_mem .

التفريغ التلقائي متطور للغاية

إذا كان الإخلاء التلقائي يستهلك المزيد من الموارد، يمكن القيام بالإجراءات التالية:

معلمات التفريغ التلقائي

تقييم المعلمات autovacuum_vacuum_cost_delay،و autovacuum_vacuum_cost_limit، وautovacuum_max_workers. قد يؤدي تعيين معلمات الإخلاء التلقائي بشكل غير صحيح إلى سيناريوهات يصبح فيها الإخلاء التلقائي معطلة للغاية.

إذا كان الإخلاء التلقائي مزعجا للغاية، ففكر في الإجراءات التالية:

  • زيادة autovacuum_vacuum_cost_delay وتقليل autovacuum_vacuum_cost_limit إذا تم تعيينه أعلى من الإعداد الافتراضي 200.
  • تقليل عدد autovacuum_max_workers إذا تم تعيينه أعلى من الافتراضي 3.

عدد كبير جداً من عمال التفريغ التلقائي

زيادة عدد عمال الإخلاء التلقائي لا يزيد من سرعة الفراغ. لا ينصح بوجود عدد كبير من عمال الإخلاء التلقائي.

تؤدي زيادة عدد عمال الإخلاء التلقائي إلى زيادة استهلاك الذاكرة، واعتمادا على قيمة maintenance_work_mem ، قد يتسبب في تدهور الأداء.

لا تحصل كل عملية عامل تفريغ تلقائي سوى على (1/autovacuum_max_workers) من إجمالي autovacuum_cost_limit، لذلك فإن وجود عدد كبير من العمال يؤدي إلى إبطاء كل واحد.

وإذا زاد عدد العمال، ينبغي زيادة autovacuum_vacuum_cost_limit أيضاً و/أو تخفيض autovacuum_vacuum_cost_delay لجعل عملية التفريغ أسرع.

ومع ذلك، إذا قمنا بتعيين المعلمة على مستوى autovacuum_vacuum_cost_delay الجدول أو autovacuum_vacuum_cost_limit المعلمات، إعفاء العمال الذين يعملون على تلك الجداول من النظر فيها في خوارزمية الموازنة [autovacuum_cost_limit/autovacuum_max_workers].

الحماية المتضمنة في معرف عملية التفريغ التلقائي (TXID)

عند تشغيل قاعدة بيانات في حماية التفافية لمعرف المعاملة، يمكن ملاحظة رسالة خطأ مثل الخطأ التالي:

Database isn't accepting commands to avoid wraparound data loss in database 'xx'
Stop the postmaster and vacuum that database in single-user mode.

إشعار

رسالة الخطأ هذه نتيجة مراقبة طويلة الأمد. عادة، لا تحتاج إلى التبديل إلى وضع المستخدم الفردي. وبدلاَ من ذلك، يمكنك تشغيل أوامر التفريغ VACUUM المطلوبة وتنفيذ ضبط «VACUUM» للتشغيل السريع. بينما لا يمكنك تشغيل أي لغة معالجة بيانات (DML)، لا يزال بإمكانك تشغيل التفريغ VACUUM.

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

حمل العمل الثقيل

قد يتسبب حمل العمل في ظهور عدد كبير جداً من المجموعات الخامدة في فترة قصيرة تجعل من الصعب على التفريغ التلقائي المتابعة. تزداد المجموعات الخامدة في النظام على مدى فترة ما يؤدي إلى تدهور أداء الاستعلام ويؤدي إلى الموقف الالتفافي. قد يكون أحد أسباب ظهور هذا الموقف هو عدم تعيين معلمات الإخلاء التلقائي بشكل كاف وأنه لا يواكب خادم مشغول.

العمليات طويلة الأمد

لا تسمح أي معاملة طويلة الأمد في النظام بإزالة المجموعات الميتة أثناء تشغيل الإخلاء التلقائي. حيث إنها تمنع عملية التفريغ. ينتح عن إزالة العمليات طويلة الأمد تحرير المجموعات الخامدة للحذف عند تشغيل التفريغ التلقائي.

يمكن الكشف عن العمليات طويلة الأمد باستخدام الاستعلام التالي:

    SELECT pid, age(backend_xid) AS age_in_xids,
    now () - xact_start AS xact_age,
    now () - query_start AS query_age,
    state,
    query
    FROM pg_stat_activity
    WHERE state != 'idle'
    ORDER BY 2 DESC
    LIMIT 10;

العبارات المعدة

إذا كانت هناك عبارات معدة لم يتم الالتزام بها، فإنها ستمنع إزالة المجموعات الميتة.
يساعد الاستعلام التالي في العثور على عبارات معدة غير ملتزمة:

    SELECT gid, prepared, owner, database, transaction
    FROM pg_prepared_xacts
    ORDER BY age(transaction) DESC;

استخدم COMMIT PREPARED أو ROLLBACK PREPARED لتثبيت هذه العبارات أو العودة إلى الحالة السابقة.

فتحات النسخ المتماثل غير المستخدمة

تمنع فتحات النسخ المتماثل غير المستخدمة التفريغ التلقائي من المطالبة بالمجموعات الخامدة. يساعد الاستعلام التالي في تحديد فتحات النسخ المتماثل غير المستخدمة:

    SELECT slot_name, slot_type, database, xmin
    FROM pg_replication_slots
    ORDER BY age(xmin) DESC;

استخدم pg_drop_replication_slot() لحذف فتحات النسخ المتماثل غير المستخدمة.

عندما يتم تشغيل قاعدة البيانات في الحماية الالتفافية لمعرف المعاملة، تحقق من وجود أي أدوات حظر كما ذكرنا سابقا، وقم بإزالة أدوات الحظر يدويا للإلغاء التلقائي للمتابعة والإكمال. يمكنك أيضا زيادة سرعة الإخلاء التلقائي عن طريق تعيين autovacuum_cost_delay إلى 0 وزيادة autovacuum_cost_limit إلى قيمة أكبر من 200. ومع ذلك، لا تنطبق التغييرات على هذه المعلمات على عمال الإخلاء التلقائي الحاليين. قم إما بإعادة تشغيل قاعدة البيانات أو إنهاء العمال الحاليين يدوياً لتطبيق تغييرات المعلمة.

متطلبات مخصصة للجداول

قد يتم تعيين معلمات الإخلاء التلقائي للجداول الفردية. إنه مهم بشكل خاص للجداول الصغيرة والكبيرة. على سبيل المثال، بالنسبة لجدول صغير يحتوي على 100 سجل فقط، يؤدي التفريغ التلقائي إلى تشغيل عملية VACUUM عند تغيير 70 سجلاً (كما هو محسوب سابقاَ). إذا كان هذا الجدول يتم تحديثه بشكل متكرر، فقد ترى مئات عمليات الإخلاء التلقائي يوميا، مما يمنع الإخلاء التلقائي من الاحتفاظ بجداول أخرى لا تكون النسبة المئوية للتغييرات عليها كبيرة. بدلًا من ذلك، يحتاج الجدول الذي يحتوي على مليار سجل إلى تغيير 200 مليون سجل لتشغيل عمليات التفريغ التلقائي. يؤدي تعيين معلمات التفريغ التلقائي تعييناً مناسباً إلى منع مثل هذه السيناريوهات.

لتعيين إعداد التفريغ التلقائي لكل جدول، قم بتغيير معلمات الخادم كما في الأمثلة التالية:

    ALTER TABLE <table name> SET (autovacuum_analyze_scale_factor = xx);
    ALTER TABLE <table name> SET (autovacuum_analyze_threshold = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_scale_factor = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_threshold = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_cost_delay = xx);
    ALTER TABLE <table name> SET (autovacuum_vacuum_cost_limit = xx);

أحمال عمل الإدراج فقط

في إصدارات PostgreSQL <= 13، لا يتم تشغيل الإخلاء التلقائي على الجداول ذات حمل عمل الإدراج فقط، حيث لا توجد مجموعات ميتة ولا توجد مساحة حرة تحتاج إلى استرداد. ومع ذلك، يتم تشغيل التحليل التلقائي لأحمال العمل المدرجة فقط نظرا لوجود بيانات جديدة. وتتمثل عيوبها في:

  • لم يتم تحديث خريطة الرؤية للجداول، وبالتالي فإن أداء الاستعلام، خاصة عندما يكون هناك عمليات فحص للفهرس فقط، يبدأ في المعاناة بمرور الوقت.
  • يمكن أن تعمل قاعدة البيانات في الحماية المضمنة في معرف العملية.
  • لم يتم تعيين بت التلميح.

الحلول

إصدارات <Postgres = 13

باستخدام ملحق pg_cron، يمكن إعداد مهمة cron لجدولة تحليل التفريغ الدوري على الجدول. يعتمد تكرار مهمة cron على حمل العمل.

للحصول على إرشادات خطوة بخطوة باستخدام pg_cron، راجع الملحقات.

إصدارات Postgres 13 والإصدارات الأحدث

يتم تشغيل الإخلاء التلقائي على الجداول مع حمل عمل الإدراج فقط. تساعد معلمتا الخادم الجديدتان autovacuum_vacuum_insert_threshold وautovacuum_vacuum_insert_scale_factor في التحكم في الوقت الذي يمكن فيه تشغيل التفريغ التلقائي في جداول الإدراج فقط.

أدلة استكشاف الأخطاء وإصلاحها

باستخدام إرشادات استكشاف الأخطاء وإصلاحها للميزة المتوفرة على مدخل خادم Azure Database for PostgreSQL المرن، من الممكن مراقبة الانتفاخ على مستوى قاعدة البيانات أو المخطط الفردي جنبا إلى جنب مع تحديد أدوات الحظر المحتملة لعملية الإخلاء التلقائي. يتوفر دليلان لاستكشاف الأخطاء وإصلاحها الأول هو مراقبة الإخلاء التلقائي التي يمكن استخدامها لمراقبة الانتفاخ في قاعدة البيانات أو مستوى المخطط الفردي. الدليل الثاني لاستكشاف الأخطاء وإصلاحها هو موانع الإخلاء التلقائي والالتفاف، مما يساعد على تحديد حاصرات الإخلاء التلقائي المحتملة. كما يوفر معلومات حول مدى مسافة قواعد البيانات الموجودة على الخادم عن حالة الالتفاف أو حالة الطوارئ. كما تشارك أدلة استكشاف الأخطاء وإصلاحها التوصيات للتخفيف من المشكلات المحتملة. كيفية إعداد أدلة استكشاف الأخطاء وإصلاحها لاستخدامها اتبع إرشادات استكشاف أخطاء الإعداد وإصلاحها.

توصيات Azure Advisor

توصيات Azure Advisor هي طريقة استباقية لتحديد ما إذا كان الخادم يحتوي على نسبة انتفاج عالية أو أن الخادم يقترب من سيناريو التفاف المعاملات. يمكنك أيضا تعيين تنبيهات للتوصيات باستخدام تنبيهات Create Azure Advisor على التوصيات الجديدة باستخدام مدخل Microsoft Azure

تذكر فيما يلي التوصيات:

  • نسبة الطفو العالية: يمكن أن تؤثر نسبة الطفو العالية على أداء الخادم بعدة طرق. تتمثل إحدى المشكلات المهمة في أن محسن محرك PostgreSQL قد يكافح لتحديد أفضل خطة تنفيذ، ما يؤدي إلى انخفاض أداء الاستعلام. لذلك، يتم تشغيل توصية عندما تصل النسبة المئوية للانتفاط على الخادم إلى حد معين لتجنب مشكلات الأداء هذه.

  • التفاف المعاملة: هذا السيناريو هو أحد أخطر المشكلات التي يمكن أن يواجهها الخادم. بمجرد أن يكون الخادم في هذه الحالة، قد يتوقف عن قبول أي معاملات أخرى، مما يتسبب في أن يصبح الخادم للقراءة فقط. ومن ثم، يتم تشغيل توصية عندما نرى أن الخادم قد تجاوز عتبة 1 مليار عملية.

المحتوى ذو الصلة