كيفية إصلاح مشكلة نفاد ذاكرة برنامج Matrix Synapse أثناء المزامنة

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

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

ما معنى "التزامن" في برنامج Matrix Synapse

يستدعي عميل Matrix واجهة برمجة تطبيقات العميل والخادم بشكل متكرر /_matrix/client/v3/syncلتلقي الأحداث الجديدة مثل الرسائل، وحالة الغرفة، وبيانات الحساب، ومعلومات التواجد، وتحديثات الأجهزة. تتضمن عملية المزامنة العادية عادةً sinceرمزًا مميزًا، لذا لا يحتاج Synapse إلا إلى إرجاع التغييرات بعد نقطة المزامنة السابقة.

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

قبل إجراء أي تغييرات، يُرجى مراجعة الأسئلة الشائعة الحالية لمسؤول Synapse ، ومرجع التكوين ، ودليل العامل الرسمي . وتعتمد الخيارات المتاحة لك على إصدار Synapse ونموذج النشر.

قبل أن تُغير أي شيء

• سجل إصدار برنامج Synapse وطريقة تثبيته.
• قم بعمل نسخة احتياطية homeserver.yamlمن ملفات تكوين العامل، وتكوين الوكيل العكسي، وقاعدة بيانات PostgreSQL وفقًا لإجراء النسخ الاحتياطي المعتاد لديك.
• لاحظ ما إذا كان برنامج Synapse يعمل كعملية واحدة، أو في حاويات، أو كعملية رئيسية بالإضافة إلى عمال.
• ابحث عن الحد الأقصى الفعلي للذاكرة. قد يكون للحاوية أو وحدة systemd أو وحدة Kubernetes pod أو الجهاز الظاهري حد أدنى من الخادم الفعلي.
• تأكد من استخدام PostgreSQL في بيئة الإنتاج. تشير وثائق تثبيت Synapse الحالية إلى أن SQLite مخصص للاختبارات، وأداؤه ضعيف في بيئات الإنتاج، خاصةً في المساحات الكبيرة.

الخطوة الأولى: التأكد من أن استنزاف الذاكرة هو الفشل الحقيقي

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

على نظام لينكس، توفر أوامر مثل ما يلي نظرة أولية سريعة:

ps -eo pid,rss,cmd | grep synapse
free -h
journalctl -u matrix-synapse -n 200

إذا كنت تستخدم Docker أو Podman أو Kubernetes أو أي مُجدوِل آخر، فتحقق أيضًا من حد ذاكرة الحاوية أو وحدة التشغيل. قد يتمكن مضيفٌ ذو مساحة تخزين حرة تبلغ عدة غيغابايتات من إيقاف Synapse إذا كانت العملية مقيدة بحدّ cgroup أصغر بكثير.

ابحث عن نمط متكرر. هل يرتفع استهلاك الذاكرة فقط عند تسجيل دخول مستخدم معين على جهاز جديد؟ هل يزداد تدريجيًا على مدار اليوم؟ هل ينمو أحد العمليات الفرعية بينما تبقى العملية الرئيسية مستقرة؟ هذه الملاحظات تميز بين الارتفاع المفاجئ الأولي للمزامنة وبين النمو العام لذاكرة التخزين المؤقت أو تراكم الطلبات.

الخطوة الثانية: تحقق من إعدادات ذاكرة التخزين المؤقت قبل خفضها

ذاكرة التخزين المؤقت هي بيانات يحتفظ بها برنامج Synapse في ذاكرة الوصول العشوائي (RAM) لتجنب إعادة حساب أو تحميل نفس المعلومات بشكل متكرر. يحتوي Synapse على العديد من ذاكرات التخزين المؤقت، بالإضافة إلى ذاكرة تخزين مؤقت للأحداث. تشير وثائق التكوين الحالية إلى قيمة افتراضية caches.global_factorتبلغ 0.5، وقيمة event_cache_sizeافتراضية أخرى تبلغ 10 كيلوبايت قبل تطبيق العامل العام، وانتهاء صلاحية ذاكرة التخزين المؤقت بناءً على الوقت، وقيمة sync_response_cache_durationافتراضية تبلغ دقيقتين.

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

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

event_cache_size: 10K

caches:
  global_factor: 0.25
  expire_caches: true
  cache_entry_ttl: 30m
  sync_response_cache_duration: 0s

هذا مثال توضيحي لحل المشكلات، وليس قيمةً مُوصى بها لكل خادم. يؤدي ضبط القيمة sync_response_cache_durationعلى الصفر إلى تعطيل التخزين المؤقت /syncللاستجابات المكتملة. قد يُوفر ذلك الذاكرة عند الاحتفاظ بالعديد من استجابات المزامنة، ولكنه قد يُزيد من عبء العمل على العملاء الذين يُعيدون الاتصال. اختبره ضمن نطاق حمل العمل الفعلي لديك.

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

الخطوة 3: تأكد من أن قاعدة البيانات لا تُنشئ قائمة انتظار للطلبات

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

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

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

الخطوة الرابعة: عزل عملية المزامنة الأولية على خوادم منزلية أكبر

يمكن تشغيل Synapse كوحدة متكاملة واحدة ، أي كعملية خادم رئيسية واحدة، أو يمكن تقسيم العمل إلى عمليات فرعية ، وهي عمليات Synapse إضافية تشترك في قاعدة بيانات PostgreSQL نفسها. يُناسب نموذج العمليات الفرعية المنشآت الكبيرة التي تحتاج إلى توسيع نطاق أحمال العمل الفردية بشكل مستقل.

توضح وثائق العامل أن العامل العام يمكنه التعامل مع /syncو /initialSync. كما توصي بالنظر في معالجة منفصلة لطلبات المزامنة بدون sinceمعلمات لأن طلبات المزامنة الأولية هذه قد تستهلك موارد كثيرة.

الهندسة المعمارية العملية هي:

• يستقبل الخادم الوكيل العكسي حركة مرور عميل المصفوفة.
• تُرسل الطلبات المستمرة /syncإلى عامل واحد أو أكثر من العمال العامين.
• تُرسل طلبات المزامنة الأولية إلى مجموعة عامل عامة منفصلة.
• تستمر العملية الرئيسية في التعامل مع المسؤوليات التي لم يتم تفويضها.
• تشترك جميع عمليات Synapse في قاعدة بيانات PostgreSQL.

لا تعرض برنامج Synapse replication listener للإنترنت العام. تحذر وثائق العامل الحالية من أن حركة مرور النسخ المتماثل غير مشفرة وغير موثقة ما لم يتم تكوين سر النسخ المتماثل.

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

الخطوة 5: أعد تحميل عوامل التخزين المؤقت بأمان ولاحظ النتيجة

يسمح برنامج Synapse بإعادة تحميل عوامل التخزين المؤقت باستخدام الأمر التالي SIGHUP. ويُقدّم مرجع التكوين هذا المثال:

kill -HUP PID_OF_SYNAPSE_PROCESS

إذا كانت خدمة systemd المعبأة تدعم ذلك، systemctl reload matrix-synapseفيمكنها تنفيذ العملية نفسها. في حالة نشر العامل، تنص الوثائق الرسمية على ضرورة تحديث تكوين العامل ذي الصلة، وأن يتلقى كل عامل إشارة إعادة التحميل بشكل فردي.

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

الخطوة 6: تفعيل مقاييس بروميثيوس لتشخيص قابل للتكرار

لأي مشكلة تتجاوز حادثة واحدة، فعّل مقاييس Synapse واجمعها باستخدام Prometheus. يُوثّق دليل المراقبة الرسمي ذلك، enable_metrics: trueبالإضافة إلى مُستمع داخلي مُخصّص للمقاييس. احتفظ بنقطة نهاية المقاييس على واجهة داخلية أو احمها على خادم وكيل عكسي؛ يجب عدم كشفها دون داعٍ.

استخدم دليل مراقبة Synapse Prometheus الرسمي لصيغة المستمع الحالية. في عمليات نشر العامل، راقب كل عامل على حدة لأن مقاييس العامل لا تُجمع تلقائيًا في العملية الرئيسية.

أخطاء شائعة يجب تجنبها

خفض قيمة SYNAPSE_CACHE_FACTOR حتى يصبح الخادم أبطأ

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

بافتراض أن كل طلب /sync يكلف نفس الشيء

تختلف متطلبات الموارد اختلافًا كبيرًا بين عملية المزامنة المستمرة باستخدام sinceرمز مميز وعملية المزامنة الأولية بدون رمز مميز. لذا، افصل بينهما في عملية التشخيص قبل توسيع نطاق الخادم بالكامل.

استخدام العمال أثناء استخدام SQLite

تتشارك وحدات Synapse العاملة قاعدة بيانات PostgreSQL. تشير وثائق الوحدة العاملة إلى أن SQLite مخصصة للاستخدام التجريبي أو الاختباري وليست أساسًا لنشر إنتاجي قائم على الوحدات العاملة.

استخدام التبديل كحل أساسي

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

تغيير عدة إعدادات للذاكرة في وقت واحد

إذا قمتَ في آنٍ واحد بتقليل حجم ذاكرة التخزين المؤقت، وتغيير توجيه العمال، وتعديل إعدادات PostgreSQL، وزيادة حدّ الحاويات، فلن تعرف أيّ تغييرٍ حلّ المشكلة. لذا، قم بإجراء تغييرٍ واحدٍ مُتحكّمٍ به في كلّ مرة، وقارن نفس المقاييس.

مسار قرار عملي

قائمة التحقق النهائية

• قم بتشغيل إصدار Synapse الحالي المدعوم؛ الإصدار 1.162.0 هو أحدث إصدار مستقر اعتبارًا من 6 أكتوبر 2026.
• استخدم PostgreSQL للإنتاج.
• تأكد من العملية التي تستهلك RSS فعليًا وما هو حد الذاكرة المطبق عليها.
• ميّز بين المزامنة التزايدية العادية والمزامنة الأولية.
• أبقِ خاصية انتهاء صلاحية ذاكرة التخزين المؤقت مفعلة، وقم بضبط عوامل ذاكرة التخزين المؤقت تدريجياً.
• لا تقم بتمكين الضبط التلقائي لذاكرة التخزين المؤقت إلا إذا كان jemalloc قيد الاستخدام وتم تكوين جميع القيم المطلوبة.
• بالنسبة لعمليات النشر الأكبر حجماً، قم بعزل عملية المزامنة الأولية أو أضف عمال مزامنة عامين عندما تبرر القياسات ذلك.
• قم بمراقبة الذاكرة وزمن الاستجابة معًا بعد كل تغيير.

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

للحصول على معلومات حول الإصدارات الحالية، راجع صفحة إصدارات Element Synapse الرسمية .