يستخدم PostgreSQL إحصائيات متراكمة حول توزيع قيم البيانات في الجداول المستهدفة لتحديد خطة تنفيذ الاستعلام الأكثر فعالية.
يتم تحديثه عن طريق تشغيل أوامر
ANALYZE و
VACUUM ANALYZE بشكل صريح أو في الخلفية من خلال عملية
autov Vacuum / autanalyze . لكن إذا لم يكن للإحصاءات وقت للتحديث - فقد تحدث مشكلة.
كيفية اكتشاف وإصلاح مثل هذه المشكلة؟
الخيار الرئيسي عندما يمكن أن يحدث مثل هذا الموقف على الإطلاق هو إذا تغيرت مجموعة البيانات بشكل كبير في الجدول. أي أنه
دفع عددًا كبيرًا من INSERT / UPDATE / DELETE أو ببساطة "سكب" البيانات في جدول فارغ - على سبيل المثال ،
عند الاستعادة من نسخة احتياطية .
المساعدة من أجل
أداة الاسترداد القياسية
pg_restore حتى بوضوح:
بعد الاسترداد ، يكون من المنطقي تشغيل ANALYZE لكل جدول تمت استعادته حتى يتلقى المحسن إحصائيات حديثة.
لذلك ، إذا كنت تفعل شيئًا مشابهًا مع قاعدة البيانات - لا تكون كسولًا ،
فقم بتشغيل
ANALYZE على الفور للجداول الأكثر "غامقًا" أو لقاعدة البيانات بأكملها.
نحدد وجود مشكلة
ما الذي يبدو عليه الوضع "السيئ" بالضبط؟ عادة ما يكون مثل هذا:
يُظهر عمود
النسبة فقط العلاقة "في بعض الأحيان" بين عدد السجلات المخططة على أساس الإحصاءات ورقم القراءة الفعلي:
Bitmap Heap Scan on ... (... rows=14831 ...) (actual ... rows=9 ...)
كلما زادت القيمة ، كلما زادت الإحصائيات الحالة الحقيقية في الجدول. عادة ، لا
يتجاوز المئات عادة ، في هذا المثال ،
ألف ونصف المرات .
هذا يؤدي إلى اختيار خطة غير فعالة ، ونتيجة لذلك ، فإن
أعنف الحمل على القاعدة . لإزالته بسرعة ، تحتاج فقط إلى الاستماع إلى توصيات الدليل
وتصفح ANALYZE على الجداول الرئيسية.
فيما يلي تحميل وحدة المعالجة المركزية على خادم قاعدة البيانات قبل وبعد هذه العملية للمثال أعلاه:
جدول محدث بشكل متكرر
ولكن ماذا لو كان الجدول يغير بالفعل عددًا كبيرًا من السجلات؟ على سبيل المثال ، هذا نوع من قائمة انتظار التخزين المؤقت أو المعالجة حيث تتم إضافة سجلات جديدة باستمرار ويتم حذف السجلات القديمة.
في هذه الحالة ، ستساعدنا
معلمات التكوين التالية:
autov Vacuum_naptime (عدد صحيح)
يعين الحد الأدنى للتأخير بين تشغيلي التنظيف التلقائي لقاعدة بيانات واحدة. يقوم البرنامج الخفي للتنظيف التلقائي بمسح قاعدة البيانات في الفاصل الزمني المحدد ويصدر أوامر VACUUM و ANALYZE عند الحاجة للجداول في قاعدة البيانات هذه. إذا تم تحديد هذه القيمة بدون وحدات ، فسيتم اعتبارها مضبوطة بالثواني. بشكل افتراضي ، يكون التأخير دقيقة واحدة (دقيقة واحدة). يمكن تعيين هذه المعلمة فقط في postgresql.conf أو في سطر الأوامر عند بدء تشغيل الخادم.
autov Vacuum_analyze_threshold (عدد صحيح)
يحدد الحد الأدنى لعدد المجموعات المضافة أو المعدلة أو المحذوفة التي سيتم فيها تنفيذ ANALYZE لجدول واحد. القيمة الافتراضية هي 50 كوبًا. يمكن تعيين هذه المعلمة فقط في postgresql.conf أو في سطر الأوامر عند بدء تشغيل الخادم. ومع ذلك ، يمكن تجاوز هذه القيمة للجداول المحددة عن طريق تغيير إعدادات التخزين الخاصة بها.
autov Vacuum_analyze_scale_factor (النقطة العائمة)
يحدد النسبة المئوية لحجم الجدول الذي سيتم إضافته إلى autov Vacuum_analyze_threshold عند تحديد عتبة أمر ANALYZE. القيمة الافتراضية هي 0.1 (10٪ من حجم الجدول). يمكنك تعيين هذه المعلمة فقط في postgresql.conf أو في سطر الأوامر عند بدء تشغيل الخادم. ومع ذلك ، يمكن تجاوز هذه القيمة للجداول المحددة عن طريق تغيير إعدادات التخزين الخاصة بها.
SSZB
في بعض الأحيان عند إعداد الخادم ،
يتم "
تحطيم "
autov Vacuum_naptime إلى "مرة واحدة يوميًا" (1d) بحيث
تتحول وحدات AutoVACUUM إلى قاعدة البيانات بشكل متكرر وتناول موارد أقل.
في بعض الأحيان ، على الرغم من أنه نادر جدًا ، يمكن تبريره - على سبيل المثال ، إذا كان لديك
الآلاف من الجداول / الأقسام في قاعدة بيانات واحدة (حتى لو كانت موضوعة في أنماط مختلفة).
نظرًا لأن التعريف الدقيق للجداول المحددة من القائمة بأكملها يحتاج إلى معالجة ، أثناء تهيئة عملية التعبئة التلقائية ،
يمكن أن يستغرق نصيبًا كبيرًا من الموارد وإبطاء الخادم .
فقط في هذه الحالة ، ستواجه مشكلات في جدول تم تعديله بشكل متكرر.
هنا - إما تعيين فاصل إطلاق أكثر ملاءمة ، أو مطاردة ANALYZE وفقًا لهذا الجدول في الوضع "اليدوي" لبعض الأسباب المطبقة (على سبيل المثال ، مؤقت خارجي أو بعد نهاية المرحلة التالية من معالجة قائمة الانتظار).
الرفيق ، والحفاظ على الإحصاءات حتى الآن!