إصلاح مشكلة ارتفاع استهلاك الذاكرة في قاعدة بيانات PostgreSQL باستخدام برنامج Matrix Synapse

قد يبدو خادم Matrix Synapse المنزلي سليمًا لعدة أيام، ثم فجأةً يستهلك PostgreSQL معظم ذاكرة الوصول العشوائي (RAM) المتاحة للجهاز. الأعراض المعتادة مألوفة: يبدأ حجم الذاكرة الافتراضية (swap) بالازدياد، وتتباطأ عمليات مزامنة العملاء، وتتراكم مهام الاتحاد، ويصبح من الصعب إدارة خادم كان يُعتبر في الأصل متواضعًا. الخطوة الأولى المهمة هي عدم افتراض وجود تسريب في PostgreSQL. قد ينجم الاستخدام العالي للذاكرة عن عدة مصادر مستقلة، بما في ذلك ذاكرة التخزين المؤقت المشتركة، وذاكرة العمل لكل استعلام، والعديد من قواعد البيانات الخلفية، وعمليات الصيانة، والاستعلامات غير الفعالة الناتجة عن إحصائيات قديمة أو تغييرات متكررة في الجداول.

توصي وثائق Synapse باستخدام PostgreSQL في بيئات الإنتاج، وتُتيح عناصر تحكم في مجمع اتصالات قاعدة البيانات، مثل `connection.com` cp_minو`connection.com` cp_max. في المقابل، يُحذّر PostgreSQL من إمكانية استخدام إعدادات مثل `connection.com` work_memمن قِبل عمليات متعددة ضمن استعلام واحد، ومن قِبل جلسات متعددة في الوقت نفسه. هذا التداخل هو ما يجعل إعدادًا يبدو غير ضار عند استخدامه بمعزل عن غيره مُكلفًا خلال فترات الذروة. الحل الأمثل هو قياس الأداء أولًا، ثم تقليل التزامن غير الضروري ثانيًا، ثم ضبط سلوك الذاكرة والصيانة فقط عند الحاجة.

الخطوة 1: تأكد من أن PostgreSQL هو مصدر ضغط الذاكرة بالفعل

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

free -h
ps aux --sort=-%mem | head -n 15

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

التعليق: يقوم فحص الذاكرة الأولي بمقارنة ذاكرة الوصول العشوائي المتاحة على مستوى المضيف مع عمليات PostgreSQL و Synapse قبل تغيير أي تكوين.

بعد ذلك، افحص إعدادات PostgreSQL التي من المرجح أن تؤثر على الذاكرة:

SHOW shared_buffers;
SHOW work_mem;
SHOW maintenance_work_mem;
SHOW autovacuum_work_mem;
SHOW max_connections;

توضح وثائق استهلاك موارد PostgreSQL الفرق الرئيسي بينهما. shared_buffersهي ذاكرة تخزين مؤقتة مشتركة على مستوى الخادم. في المقابل، work_memهي حدٌّ لعمليات الفرز أو التجزئة الفردية قبل نقلها إلى ملفات مؤقتة؛ إذ يمكن أن يحتوي استعلام معقد على عدة عمليات من هذا القبيل، ويمكن للعديد من الجلسات تشغيلها في وقت واحد. تُشير وثائق PostgreSQL حاليًا إلى أن work_memالقيمة الافتراضية هي 4 ميجابايت، وتُلاحظ أن الاستخدام الإجمالي قد يكون أضعاف هذه القيمة.

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

الخطوة الثانية: حساب اتصالات قاعدة بيانات Synapse والعثور على العمل النشط

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

SELECT state,
       usename,
       application_name,
       count(*) AS connections
FROM pg_stat_activity
GROUP BY state, usename, application_name
ORDER BY connections DESC;

ثم افحص الاستعلامات النشطة طويلة الأمد:

SELECT pid,
       usename,
       state,
       now() - query_start AS running_for,
       wait_event_type,
       wait_event,
       left(query, 180) AS query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY query_start;

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

التعليق: pg_stat_activityيسهل التجميع التمييز بين العديد من الخوادم الخلفية الخاملة ومجموعة أصغر من جلسات قواعد البيانات النشطة.

الخطوة 3: ضبط حجم مجموعة اتصالات Synapse PostgreSQL

يُمرر Synapse معظم وسائط قاعدة البيانات إلى PostgreSQL، بينما يستخدم الخيارات التي تبدأ بـ لمجموعة اتصالات Twisted الخاصة به. يُظهر دليل Synapse PostgreSQLcp_ الحالي مثالًا باستخدام و . اعتبر هذه القيم أمثلة فقط، وليست قيمًا عامة.cp_min: 5cp_max: 10

تحقق من databaseالكتلة في homeserver.yaml:

database:
  name: psycopg2
  args:
    user: synapse_user
    password: "your-secret"
    dbname: synapse
    host: 127.0.0.1
    cp_min: 5
    cp_max: 10

إذا قمتَ سابقًا بزيادة عدد اتصالات Synapse cp_maxبشكلٍ pg_stat_activityكبير، ولاحظتَ وجود عددٍ كبيرٍ منها غير نشط، فقم بتخفيضه تدريجيًا وراقب زمن استجابة الطلبات. في بيئة Synapse التي تعتمد على العمال، تذكّر أن طلبات قاعدة البيانات تأتي من عمليات Synapse متعددة، لذا قيّم العدد الإجمالي للاتصالات بدلًا من تقييم كل عامل على حدة. يؤكد دليل تكوين Synapsecp_ أن الخيارات تُستخدم لتكوين مجموعة الاتصالات.

بعد تعديل الإعدادات، أعد تشغيل عملية أو عمليات Synapse المتأثرة وفقًا لطريقة النشر، ثم نفّذ استعلام عدد الاتصالات مرة أخرى. لا تُقلّل حجم مجموعة الاتصالات حتى تبدأ الطلبات بالتراكم في قائمة الانتظار لمجرد توفير بضعة ميغابايتات. فصغر حجم مجموعة الاتصالات قد يُحوّل تزامن قاعدة البيانات إلى تأخير في التطبيق.

التعليق: يكشف Synapse عن ذلك cp_minفي cp_maxتكوين قاعدة بيانات PostgreSQL، مما يسمح للمسؤولين بالحد من التزامن غير الضروري في الواجهة الخلفية.

الخطوة الرابعة: ضبط ذاكرة PostgreSQL بشكل متحفظ

بمجرد أن يصبح عدد الاتصالات مناسبًا، راجع إعدادات ذاكرة PostgreSQL في ضوء ذاكرة الوصول العشوائي (RAM) المتاحة فعليًا لقاعدة البيانات. تشير PostgreSQL إلى أنه على خادم قاعدة بيانات مخصص مزود بذاكرة وصول عشوائي لا تقل عن 1 جيجابايت، فإن حوالي 25% من ذاكرة النظام تُعد نقطة بداية مناسبة shared_buffers. هذه التوصية خاصة بخادم قاعدة بيانات مخصص. إذا كانت Synapse، والخادم الوكيل العكسي، وRedis، ونظام المراقبة، وPostgreSQL تشترك في جهاز افتراضي صغير واحد، فإن PostgreSQL لا يمتلك الجهاز بالكامل، لذا ضع ذلك في اعتبارك عند تحديد الميزانية.

الإعداد الذي قد يُفاجئ المسؤولين هو work_mem. تجنب ضرب قيمة work_memفي max_connectionsوالتعامل معها كحجز مُسبق؛ فـ PostgreSQL لا يُخصصها مُسبقًا بهذه الطريقة. بدلًا من ذلك، فكّر من منظور عمليات الاستعلام المُتزامنة. قد يستخدم استعلام واحد عدة عُقد فرز أو تجزئة، وقد تستخدم عمليات التجزئة مُضاعفات work_mem. إذا قمت بتعيين قيمة work_memإلى رقم كبير جدًا على مستوى النظام بسبب بطء أحد التقارير، فقد يؤدي اندفاع الاتحاد أو فترة تزامن كثيفة إلى ذروة استخدام ذاكرة أكبر بكثير من المُتوقع.

من الأفضل الحفاظ على القيمة العامة منخفضة، ورفعها فقط لجلسة إدارية محددة عندما يستفيد استعلام معروف من ذاكرة أكبر. قبل تغيير القيم، احتفظ بإعداداتك الحالية، ولاحظ أي المعلمات تتطلب إعادة تشغيل PostgreSQL. shared_buffersعلى سبيل المثال، تُعدّ هذه المعلمة إعدادًا لبدء تشغيل الخادم. يجب جدولة التغييرات بحيث يمكنك مقارنة الذاكرة، وزمن الاستجابة، وسلوك الملفات المؤقتة قبل التغيير وبعده.

تحقق أيضًا maintenance_work_memمن الإعدادات autovacuum_work_mem. يُشير PostgreSQL إلى أن عمليات التنظيف التلقائي (autovacuum) يمكنها تخصيص ذاكرة الصيانة بشكل متزامن. إذا autovacuum_work_memتُركت الإعدادات على سلوكها الافتراضي، maintenance_work_memفقد يؤدي حجم كبير غير معتاد إلى زيادة تكلفة تشغيل عدة عمليات تنظيف تلقائي متزامنة. لا تُعطّل التنظيف التلقائي لتوفير ذاكرة الوصول العشوائي (RAM)؛ فعادةً ما يُؤدي ذلك إلى تضخم الجداول، وإحصائيات قديمة، وتراجع الأداء، على حساب مشكلة مؤقتة في الذاكرة.

الخطوة 5: تحقق من سلامة المكنسة الكهربائية، ثم تحقق من الإصلاح تحت الحمل الفعلي

يقوم برنامج Synapse بكتابة وتحديث كميات كبيرة من بيانات الأحداث والحالة. يحتاج PostgreSQL إلى تنظيف دوري لاستعادة الصفوف غير المستخدمة لإعادة استخدامها وللحفاظ على تحديث إحصائيات المُخطط. يوصي دليل التنظيف الدوري لـ PostgreSQL باستخدام autovacuum لمعظم عمليات التثبيت.

ابحث عن الجداول التي تحتوي على العديد من الصفوف الميتة المقدرة أو طوابع زمنية قديمة للصيانة:

SELECT relname,
       n_live_tup,
       n_dead_tup,
       last_autovacuum,
       last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

إذا كان هناك جدول معين يحتاج بوضوح إلى الاهتمام، فإن استخدام VACUUM (ANALYZE)أداة يدوية عادية هو عادةً أول أداة يجب مراعاتها:

VACUUM (ANALYZE) your_table_name;

تجنب الانتقال مباشرةً إلى VACUUM VACUUM FULL. يشرح المرجع الرسمي لـ VACUUM أن VACUUMعملية القراءة والكتابة العادية يمكن تشغيلها جنبًا إلى جنب مع عمليات القراءة والكتابة العادية، بينما VACUUM FULLتقوم عملية إعادة كتابة الجدول بحجز ACCESS EXCLUSIVEقفل. استخدم الأخيرة فقط عندما يكون استعادة مساحة القرص يستحق التوقف المخطط له.

كيف تعرف ما إذا كان التغيير قد نجح بالفعل

تحقق من النتيجة على نفس نوع عبء العمل الذي تسبب في المشكلة. لا يقتصر الحل الناجح على مجرد "انخفاض استخدام Postgres لذاكرة الوصول العشوائي فورًا". من المفترض أن تستخدم ذاكرة التخزين المؤقت لقاعدة البيانات الذاكرة. بدلًا من ذلك، ابحث عن ذاكرة متاحة مستقرة، ونمو ضئيل أو معدوم لمساحة التبديل غير المتوقعة، وعدم وجود أحداث نفاد الذاكرة، وعدد اتصالات يتوافق مع التزامن المتوقع، وأوقات استجابة مقبولة لـ Synapse.

• قم بتشغيل free -hقائمة العمليات بنفس مستوى حركة المرور المستخدمة كخط أساس.
• كرر pg_stat_activityاستعلام الاتصال وتأكد من انخفاض عدد الخوادم الخلفية الخاملة إذا قمت بتغيير مجموعة Synapse.
• راقب زمن استجابة الاستعلام والمزامنة بعد خفضه cp_max؛ وقم بعكس التغيير إذا زادت فترات انتظار قاعدة البيانات بشكل ملحوظ.
• تحقق pg_stat_user_tablesبمرور الوقت للتأكد من أن المكنسة الكهربائية الآلية تقوم بالفعل بزيارة الطاولات المزدحمة.
• إذا قمت بتخفيضها work_mem، فراقب ما إذا كانت عمليات الفرز الكبيرة تتسرب بشكل مفرط إلى الملفات المؤقتة قبل تخفيضها أكثر.

إذا استمرّ حجم بيانات PostgreSQL في الازدياد حتى بعد إجراء عمليات تبديل مكثفة للذاكرة على الخادم بعد هذه الفحوصات، فقم بتسجيل قائمة الاستعلامات النشطة أثناء ذروة الاستخدام، ثمّ ادرس عبء العمل بدلاً من تقليص حدود الذاكرة العامة بشكل متكرر. في إصدارات PostgreSQL المدعومة، pg_backend_memory_contextsيمكنك فحص سياقات الذاكرة للخادم الحالي؛ حيث يصف دليل عرض النظام في PostgreSQL هذا العرض وصلاحياته. يُعدّ هذا أكثر فائدة لإجراء تحقيق مركّز في قاعدة البيانات من افتراض أن جميع عمليات نشر Synapse التي تستهلك ذاكرة عالية لها السبب نفسه.

خلاصة القول

بالنسبة لـ Matrix Synapse على PostgreSQL، يُمكن معالجة ارتفاع استهلاك ذاكرة قاعدة البيانات على مراحل لضمان سلامة العملية: التأكد من وجود ضغط حقيقي على ذاكرة الخادم، وحساب جلسات قاعدة البيانات، وتحديد حجم مجموعة Synapse بشكل مناسب، والحفاظ على استهلاك PostgreSQL للذاكرة لكل عملية بشكل مُقتصد، والتأكد من سلامة عملية التنظيف التلقائي (autovacuum). الهدف ليس تقليل استهلاك PostgreSQL إلى أدنى حد ممكن، بل هو استخدام مُتوقع للذاكرة دون تحويل التخزين المؤقت والتزامن الطبيعيين لقاعدة البيانات إلى عمليات تبديل غير ضرورية، أو أحداث نفاد الذاكرة، أو بطء عملاء Matrix.