أولئك الذين يحاولون تجربة PostgreSQL 15 القادمة سيلاحظون عملية خلفية واحدة أقل:

postgres    1710       1  0 04:03 ?        00:00:00 /usr/pgsql-15/bin/postmaster -D /var/lib/pgsql/15/data/postgres    1711    1710  0 04:03 ?        00:00:00 postgres: logger postgres    1712    1710  0 04:03 ?        00:00:00 postgres: checkpointer postgres    1713    1710  0 04:03 ?        00:00:00 postgres: background writer postgres    1715    1710  0 04:03 ?        00:00:00 postgres: walwriter postgres    1716    1710  0 04:03 ?        00:00:00 postgres: autovacuum launcher postgres    1717    1710  0 04:03 ?        00:00:00 postgres: logical replication launcher

لنقارنها مع PostgreSQL 14:

postgres    1751       1  0 04:04 ?        00:00:00 /usr/pgsql-14/bin/postmaster -D /var/lib/pgsql/14/data/postgres    1752    1751  0 04:04 ?        00:00:00 postgres: logger postgres    1754    1751  0 04:04 ?        00:00:00 postgres: checkpointer postgres    1755    1751  0 04:04 ?        00:00:00 postgres: background writer postgres    1756    1751  0 04:04 ?        00:00:00 postgres: walwriter postgres    1757    1751  0 04:04 ?        00:00:00 postgres: autovacuum launcher postgres    1758    1751  0 04:04 ?        00:00:00 postgres: stats collector postgres    1759    1751  0 04:04 ?        00:00:00 postgres: logical replication launcher

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

ما هي وظيفة جامع الإحصائيات؟

قد يتساءل المستخدمون المبتدئون عما هو عليه ولماذا هو مطلوب لـ PG 14 وما قبله. سيتم الخلط بين بعض المستخدمين على الأقل حول مجموعة الإحصائيات على مستوى الجدول (ANALYZE) المستخدمة لخطط الاستعلام. لكن هذا مختلف. تتعقب PostgreSQL كل نشاط كل عملية للحصول على إحصاءات تراكمية ، مثل عدد المرات التي تم فيها فحص جدول أو فهرس ، أو آخر مرة تم فيها تشغيل الفراغ أو الفراغ التلقائي على طاولة ، أو عدد مرات تشغيل الفراغ التلقائي على طاولة ، إلخ. تتوفر جميع البيانات التي تم جمعها بواسطة جامع الإحصائيات من خلال طرق عرض pg_stat_ * المختلفة.

سؤال

نظرًا لأن كل واجهة خلفية للجلسة هي عملية منفصلة في PostgreSQL ، فإن جمع الإحصائيات ونقلها ليس بالأمر الهين. ترسل كل خلفية معلومات حول الأنشطة التي يقومون بها إلى عملية واحدة "جامع الإحصائيات".

كان هذا الاتصال عبر مآخذ UDP. هناك الكثير من المشاكل في هذا النهج ، فهو ليس نموذجًا قابلًا للتطوير.

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

كان من الصعب حقًا فهم الخطأ الذي حدث إذا واجه جامع الإحصائيات مشكلة في جهاز معين.

تأثير سلبي آخر لـ "جامع الإحصائيات" هو الإدخال / الإخراج الذي يسببه. إذا قمت بتمكين DEBUG level 2 ، فقد ترى الرسائل التي تستمر في الظهور في سجل PostgreSQL ، مثل:

2022-08-22 03:49:57.153 UTC [736] DEBUG:  received inquiry for database 02022-08-22 03:49:57.153 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/global.stat"2022-08-22 03:49:57.153 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/db_0.stat"2022-08-22 03:49:57.168 UTC [1278] DEBUG:  autovacuum: processing database "postgres"2022-08-22 03:49:57.168 UTC [736] DEBUG:  received inquiry for database 138812022-08-22 03:49:57.168 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/global.stat"2022-08-22 03:49:57.168 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/db_13881.stat"2022-08-22 03:49:57.169 UTC [736] DEBUG:  writing stats file "pg_stat_tmp/db_0.stat"

هذا يمكن أن يسبب الكثير من الإدخال / الإخراج إلى نقطة التحميل حيث يوجد دليل البيانات. هذا هو المكان الذي تشير إليه قيمة المعلمة stats_temp_directory. في العديد من الأنظمة ستكون pg_stat_tmp في دليل البيانات.

على Ubuntu / Debian ، سيكون في / var / run / postgresql ، على سبيل المثال:

postgres=# show stats_temp_directory ;          stats_temp_directory           ----------------------------------------- /var/run/postgresql/14-main.pg_stat_tmp(1 row)

الجديد في PostgreSQL 15

ابدأ في استخدام الذاكرة المشتركة الديناميكية لجمع الإحصائيات بدلاً من استخدام الملفات وأنظمة الملفات.

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

يتم الآن تخزين الإحصائيات في الذاكرة المشتركة. يتم تخزين الإحصائيات الخاصة بالعناصر المرقمة المتغيرة في جدول تجزئة dshash (مدعوم بذاكرة مشتركة ديناميكية). يتم تخزين الإحصائيات ذات الأرقام الثابتة في الذاكرة المشتركة العادية.

يحتوي ملف الرأس الخاص بـ pgstat.c على نظرة عامة على البنية.

لم تعد هناك حاجة إلى جامع الإحصائيات ، قم بإزالته.

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

على ما يبدو ، المعلمة stats_temp_directory مفقودة. لذلك ، لا نحتاج إلى دليل pg_stat_tmp ، الموجود في دليل البيانات (أو في أي مكان آخر) ، حيث يتم إنشاء جميع ملفات الإحصاء وقراءتها. ومع ذلك ، يتم الاحتفاظ بهذا الدليل لأن العديد من الامتدادات التي تعتمد عليه ، مثل pg_stat_statements ، ليست معطلة.

يظل الدليل فارغًا حتى يتم تحميل مكتبة الملحقات. على سبيل المثال ، إذا قمنا بتحميل مكتبة pg_stat_statements ، فسيظهر ملف في الدليل.

$ ls pg_stat_tmp/pgss_query_texts.stat

بالطبع ، الإضافات ليست مجانية ، ولديها أيضًا تكاليف مقابلة.

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

يحدث تناسق القراءة لأن الإحصائيات يتم تحديثها في نفس الوقت الذي يحاول فيه شخص ما القراءة. لذا ، تقدم PostgreSQL 15 معاملاً جديدًا: stats_fetch_consistency ، والذي يمكن أن يأخذ ثلاث قيم من لا شيء ، أو ذاكرة تخزين مؤقت أو لقطة:

· "لا شيء" هو الأكثر كفاءة. ومع ذلك ، لن يتم توفير تناسق القراءة. لكن بالنسبة لمعظم الاستخدام يجب أن يكون جيدًا. 

تضمن "ذاكرة التخزين المؤقت" أن عمليات الوصول المتكررة تسفر عن نفس القيمة ، وهو أمر ضروري للحالات التي تتضمن على سبيل المثال عمليات الصلات الذاتية.

"اللقطة" مفيدة عند فحص الإحصائيات بشكل تفاعلي ، ولكنها أكثر تكلفة.

افتراضات على "ذاكرة التخزين المؤقت"

إذا كانت في الذاكرة المشتركة ، فكيف يمكن الاحتفاظ بها بعد إعادة التشغيل؟

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

هل سيؤثر هذا التغيير على المراقبة / البرمجة النصية الخاصة بي؟

ستستمر طرق عرض المراقبة pg_stat_ * في العمل. ومع ذلك ، تأكد من الحصول على القيمة المناسبة لـ stats_fetch_consistency. كما ذكر أعلاه ، فإن دليل pg_stat_tmp محجوز للإمتدادات فقط.

آخر

كثير من الناس ، مثلي ، يستخدمون أحداث انتظار postgresql لفهم postgresql وأين تقضي الجلسات وقتهم. تحلل أدوات جمع البيانات وتحليلها ، مثل pg_gather ، المشكلات باستخدام أحداث الانتظار.


لمراقبة postgresql بشكل أفضل ، تم تقديم ثلاثة أحداث انتظار جديدة:

PgStatsDSA: انتظر إحصائيات الوصول الديناميكي لمخصص الذاكرة المشتركة

PgStatsHash: انتظر الوصول إلى جدول إحصائيات تجزئة الذاكرة المشتركة

PgStatsData: في انتظار الوصول إلى إحصائيات الذاكرة المشتركة

مع انتهاء كل النفقات العامة لمجمع الإحصائيات وصيانته ، فإن الأنظمة الفرعية الأخرى (مثل الفراغ التلقائي) لديها عمل أقل للقيام به.

بالإضافة إلى ذلك ، من المتوقع أن تؤدي أدوات المراقبة التي تستفسر عن الإحصائيات بشكل متكرر إلى تقليل حمل النظام بشكل كبير.