إصلاح مشكلة "عدد كبير جدًا من الملفات المفتوحة" في برنامج Matrix Synapse على نظام systemd

قد يبدأ برنامج Matrix Synapse بشكل طبيعي ثم يتوقف عن قبول الاتصالات، أو يسجل رسالة "عدد كبير جدًا من الملفات المفتوحة"، أو يبدو عالقًا تحت ضغط كبير. في نظام systemd، أول ما يجب التحقق منه هو حدّ مُعرّفات الملفات الذي يرثه برنامج Synapse قيد التشغيل. ulimitعادةً لا يؤدي تغيير حدود shell أو تعديل ملف PAM limits إلى تغيير الحدّ الخاص بالخدمة التي يبدأها systemd.

تنطبق الخطوات التالية على مضيف Linux حيث يعمل Synapse كخدمة systemd. قد يكون اسم الوحدة `<اسم الوحدة>` matrix-synapse.serviceأو matrix-synapse@.service`<اسم الوحدة>` أو اسمًا خاصًا بالحزمة. تأكد من الوحدة الفعلية قبل نسخ الأوامر. إذا كان Synapse يعمل في Docker أو Kubernetes أو حاوية أخرى، فراجع القسم المنفصل أدناه.

ماذا تعني عبارة "عدد كبير جدًا من الملفات المفتوحة"؟

يفرض نظام لينكس حدًا أقصى لعدد مُعرّفات الملفات المفتوحة لكل عملية. يمكن أن يُشير المُعرّف إلى ملف، أو مقبس، أو قناة، أو أي مورد آخر؛ وبالتالي، تستهلك اتصالات الشبكة مُعرّفات أيضًا. عندما تصل عملية ما إلى حدها الأقصى، قد تفشل محاولة فتح مُعرّف آخر أو قبوله EMFILE. كما يمتلك لينكس حدًا أقصى منفصلًا لجدول الملفات على مستوى النظام: قد يؤدي استنفاد هذا الحد إلى حدوث خطأ ENFILE. لن يؤدي رفع حد خدمة Synapse واحدة إلى حل مشكلة النقص على مستوى النظام.

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

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

1. تأكد من الوحدة وشخص العطل

ابحث أولاً عن اسم الخدمة الفعلي. في العديد من عمليات تثبيت الحزم، يكون الاسم هو matrix-synapse.service، ولكن لا تفترض هذا الاسم إذا كان التثبيت الخاص بك يستخدم وحدة أو عمالًا مخصصين.

systemctl list-units --type=service --all | grep -i synapse
systemctl status matrix-synapse.service --no-pager
journalctl -u matrix-synapse.service --since "30 minutes ago" --no-pager

ابحث عن الخطأ بالتحديد، ووقت حدوثه، وما إذا كان يظهر أثناء ذروة حركة البيانات، أو نشاط الاتحاد، أو إعادة التشغيل. ثم، افحص الحد الذي يُبلغه نظام systemd حاليًا:

systemctl show matrix-synapse.service -p LimitNOFILE -p MainPID

LimitNOFILEيُظهر هذا الحدّ المُكوّن لمدير الخدمة؛ وهو ليس عدد الواصفات المفتوحة حاليًا. أمر shell مثل هذا ulimit -nيُبلغ فقط عن حدّ shell الحالي، ولا يُعدّ دليلًا على حدّ الخدمة.

2. ارفع حد خدمة systemd باستخدام أمر إضافي

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

sudo systemctl edit matrix-synapse.service

أضف هذا ضمن قسم الإضافات الجديدة في المحرر:

[Service]
LimitNOFILE=65536

احفظ الملف واخرج، ثم أعد تحميل systemd وأعد تشغيل Synapse خلال فترة الصيانة المناسبة:

sudo systemctl daemon-reload
sudo systemctl restart matrix-synapse.service
systemctl show matrix-synapse.service -p LimitNOFILE

يُحدد قيمة واحدة LimitNOFILEالحد الأدنى والحد الأقصى للخدمة في نظام systemd. كما يسمح دليل systemd بتحديد soft:hardقيمة مزدوجة. لا يمكن أن يتجاوز الحد الأدنى الحد الأقصى. قبل اختيار قيمة عالية جدًا، يُرجى مراجعة وثائق systemd.exec ، التي تُشير إلى مخاوف التوافق للبرامج التي تستخدم select(2)الواجهة القديمة ذات الواصفات التي تزيد عن 1023. لا تفترض أن كل مكتبة أو إضافة في نظامك تدعم أي حد عشوائي.

3. تحقق من إعدادات Synapse وخدمات العامل الخاصة به

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

في بيئة نشر متعددة العمليات، يُعتبر كل عامل عملية منفصلة، ​​ويمكن تشغيله بواسطة وحدة أو نموذج منفصل. لا يضمن رفع حد الخدمة الرئيسية بالضرورة أن كل عامل لديه الحد المطلوب. تحقق من أسماء وحدات العامل الفعلية systemctl list-units، ثم قم بتطبيق وتحقق من الإعدادات المناسبة لكل خدمة تحتاجها.

وبالمثل، فإن الإعدادات في /etc/security/limits.confواجهة تسجيل الدخول ulimitلا تتحكم عادةً في خدمة النظام التي يتم تشغيلها مباشرةً بواسطة systemd. في هذه الحالة، قم بتغيير حد موارد الوحدة وتحقق منه في العملية التي بدأها systemd فعليًا.

4. إذا كان برنامج Synapse يعمل في حاوية

لا يؤدي تجاوز إعدادات systemd على مستوى المضيف لخدمة مختلفة إلى تغيير حدّ مُعرّفات الملفات للحاوية تلقائيًا. لذا، يُرجى ضبط وقت تشغيل الحاوية أو طبقة التنسيق. بالنسبة إلى Docker Compose، يدعم تعريف الخدمة تحديد حدّ مُعرّفات الملفات لكل حاوية على حدة ulimits؛ مثال على ذلك:

services:
  synapse:
    ulimits:
      nofile:
        soft: 65536
        hard: 65536

الرقم المذكور هو رقم توضيحي؛ حدده بناءً على الاستخدام وحدود المضيف. يوثق مرجع خدمة Compose في Docker هذا ulimitsالإعداد. اعتبارًا من Docker Engine 29، تشير ملاحظات إصدار Docker إلى تغيير في الحد الافتراضي لملفات nofile المرتبط بـ containerd 2.1.5: قد تتلقى الحاويات 1024 بدلاً من الحد الافتراضي السابق البالغ 1048576. إذا ظهرت المشكلة بعد ترقية المحرك، فتحقق من حد الحاويات الفعلي وقم بتعيين حد ulimit المطلوب صراحةً في تكوين النشر. راجع ملاحظات إصدار Docker Engine 29 ومرجع docker run .

5. تحقق من الحد الأقصى لعملية Synapse قيد التشغيل

بعد إعادة التشغيل، تحقق من حدود مستوى العملية، وليس فقط إعدادات systemd. احصل على مُعرّف العملية الرئيسي (PID) وافحص الحدود التي يُبلغ عنها نظام التشغيل:

PID=$(systemctl show --property=MainPID --value matrix-synapse.service)
grep "Max open files" "/proc/$PID/limits"
find "/proc/$PID/fd" -mindepth 1 -maxdepth 1 | wc -l

إذا كان مُعرّف العملية الرئيسي (PID) يساوي صفرًا أو ينتمي إلى برنامج وسيط (wrapper) وليس إلى Synapse، فحدد عملية Synapse في مجموعة التحكم (cgroup) الخاصة بالخدمة، وافحص مُعرّف العملية الخاص بها. يُعدّ عدد الواصفات لقطةً لحظية؛ لذا كرّر العملية أثناء تحميل نموذجي. تأكد من أن "الحد الأقصى للملفات المفتوحة" يعكس حدودك الدنيا والعليا المقصودة، وأن العدد يبقى أقل بكثير من الحد الأدنى، وأن سجل العمليات لم يعد يُبلغ عن الخطأ.

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

عندما لا يكون رفع الحد الأقصى لكل خدمة كافياً

إذا أشارت سجلات النظام إلى خطأ استنفاد جدول الملفات على مستوى النظام، مثل خطأ `enabled` ENFILE، فافحص استخدام النظام على مستوى المضيف والخدمات الأخرى؛ LimitNOFILEإذ لن يؤدي تغيير أي خدمة على حدة إلى زيادة سعة النظام على مستوى النواة. تجنب تغيير حدود النواة العامة دون التأكد من الخطأ وفهم تأثيره على مستوى المضيف. إذا ظل الحد المُبلغ عنه للخدمة منخفضًا بعد تثبيت وحدة إضافية، فقم بتشغيل الأمر `enabled` systemctl cat matrix-synapse.serviceللتأكد من تحميل الوحدة الإضافية، والتحقق من اسم الوحدة، وإعادة تحميل systemd، وإعادة تشغيل الوحدة الصحيحة.

فحص ذاتي سريع

• هل حددت وحدة Synapse أو الحاوية التي تسجل الخطأ بدقة؟
• هل systemctl showيُبلغ عن الحد المقصود لتلك الوحدة؟
• هل /proc/<Synapse-PID>/limitsيعرض الحدود الدنيا والدنيا المقصودة بعد إعادة التشغيل؟
• هل عدد المؤشرات أقل من الحد الأدنى المسموح به في ظل الحمل الأقصى الطبيعي؟
• هل يتم فحص وحدات العمل وإعدادات الحاويات بشكل منفصل عند الاقتضاء؟
• هل توقف الخطأ، أم أن الاستخدام مستمر في النمو نحو الحد الأقصى الجديد؟

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

مصادر

• الأسئلة الشائعة حول إدارة Synapse: استنفاد مقابض الملفات
• مرجع تكوين Synapse: soft_file_limit
• دليل systemd.exec: حدود موارد الخدمة
• دليل لينكس: getrlimit و prlimit
• ملاحظات إصدار Docker Engine 29