استضافة Matrix Synapse على VPS: المتطلبات والصيانة

ما يلزم للحفاظ على خادم Matrix Synapse المنزلي قيد التشغيل

من السهل تثبيت Matrix Synapse، ومن السهل أيضاً إهماله. يتطلب التثبيت مستودع apt واحداً، وملف إعداد واحداً، وكتلة Reverse Proxy واحدة، وسجل DNS واحداً. لكن الحفاظ على سلامة الخادم المنزلي لمدة عام يتطلب عملاً مختلفاً: قاعدة بيانات فعلية، ومخزناً للوسائط يجري تنظيفه دورياً، وتعطيل التسجيل أمام الغرباء، ونسخة احتياطية تشمل جزأي الخادم.

يستهدف هذا الدليل Ubuntu 24.04 LTS، ويثبّت Synapse من مستودع apt الخاص بـmatrix.org، وهو مصدر الحزم الذي يديره مشروع Synapse لصالح Debian وUbuntu. تتغير إصدارات الحزم كل بضعة أسابيع، لذلك لا نذكر أي رقم إصدار هنا. تأتي كل المسارات والخيارات أدناه من وثائق Synapse الحالية.

تقدير الموارد: ما الذي يوفّره 1 vCPU و2 GB من الذاكرة فعلياً؟

تضع صفحات تقدير الموارد المنشورة، حتى August 2026، خادم Synapse عادةً ضمن مواصفات 1 vCPU و2 GB من الذاكرة. يكون ذلك كافياً في حالة واحدة: خادم خاص، وعدد قليل من المستخدمين، وغرف صغيرة، وعدم وجود غرف عامة نشطة. وتوضح وثائق Synapse الحالة الأخرى مباشرةً. فهي تطلب «At least 1GB of free RAM if you want to join large public rooms like #matrix:matrix.org». وهذه ذاكرة RAM حرة، إضافةً إلى الذاكرة التي يحتاج إليها Python وPostgres وkernel.

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

يُخصّص Synapse معظم ذاكرة RAM للتخزين المؤقت. يحتوي قسم caches على global_factor يوسّع كل ذاكرات التخزين المؤقت في الوقت نفسه، ويضبط متغير البيئة SYNAPSE_CACHE_FACTOR القيمة نفسها. يؤدي رفع هذه القيمة إلى استهلاك RAM لتجنب استعلامات قاعدة البيانات. ويؤدي خفضها إلى استهلاك CPU ووقت Postgres لتوفير RAM. يحتاج Postgres إلى ذاكرة خاصة به، لذلك يتنافس المكوّنان على وحدات الذاكرة نفسها في خادم بسعة 2 GB.

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

لماذا PostgreSQL، ولماذا لم تعد SQLite خياراً مناسباً

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

السبب الثاني بنيوي. تُعد عمليات العامل في Synapse الطريقة المدعومة لاستخدام أكثر من نواة CPU واحدة، وتتطلب هذه العمليات PostgreSQL. يؤدي الاستمرار في استخدام SQLite إلى التخلي عن مسار الترقية وعن الأداء أيضاً.

ترحيل قاعدة البيانات لاحقاً مدعوم، لكنه يتطلب فترة توقف. لذلك نفّذه قبل أن يبدأ المستخدمون باستخدام الخادم. تتضمن Synapse الأداة synapse_port_db، التي تنسخ قاعدة بيانات SQLite إلى قاعدة PostgreSQL مُجهّزة:

synapse_port_db --sqlite-database homeserver.db --postgres-config homeserver-postgres.yaml

إذا كنت تفضّل تشغيل قاعدة البيانات في حاوية بجانب Synapse، فستجد المفاضلات في تشغيل قاعدة البيانات في Docker أو على المضيف.

تثبيت Synapse على Ubuntu 24.04

sudo apt install -y lsb-release wget apt-transport-https
sudo wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/matrix-org.list
sudo apt update
sudo apt install matrix-synapse-py3

في Ubuntu 24.04، يعرض lsb_release -cs القيمة noble، وينشر مستودع matrix.org حزمة noble. لا تستخدم حزمة matrix-synapse من أرشيف Ubuntu نفسه. يطلب منك مشروع Synapse عدم استخدامها، لأن هذه الإصدارات تتأخر عن إصداراته وتتضمن ثغرات أمنية معروفة.

يطلب المثبّت اسم خادم ويكتب الإجابة في /etc/matrix-synapse/conf.d/server_name.yaml. أدخلها بعناية. يمثّل server_name الجزء الذي يلي النقطتين في كل معرّف مستخدم (@alice:example.com)، ويُضمَّن في كل غرفة ينشئها خادمك. تغييره لاحقاً لا ينقل أي شيء؛ بل ينشئ homeserver مختلفاً. استخدم نطاقك الأساسي، example.com، حتى عندما يعمل Synapse نفسه على matrix.example.com. يربط التفويض بينهما، وهذا هو موضوع القسم التالي.

تشغّل الحزمة Synapse باستخدام المستخدم matrix-synapse، وتحتفظ ببياناته ضمن /var/lib/matrix-synapse، وتقرأ /etc/matrix-synapse/homeserver.yaml ثم كل ملف داخل /etc/matrix-synapse/conf.d/. ضع إعداداتك في ملفات صغيرة ضمن conf.d. تترك ترقيات الحزمة هذه الملفات دون تغيير.

sudo systemctl restart matrix-synapse
systemctl status matrix-synapse
sudo journalctl -u matrix-synapse -n 100 --no-pager

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

توجيه Synapse إلى Postgres

sudo apt install -y postgresql
sudo -u postgres createuser --pwprompt synapse_user
sudo -u postgres createdb --encoding=UTF8 --locale=C --template=template0 --owner=synapse_user synapse

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

database:
  name: psycopg2
  txn_limit: 10000
  args:
    user: synapse_user
    password: secretpassword
    dbname: synapse
    host: localhost
    port: 5432
    cp_min: 5
    cp_max: 10

احتفظ بمفتاح database: واحد فقط في جميع ملفات الإعداد. استبدل كتلة SQLite داخل homeserver.yaml بدلاً من إضافة نسخة ثانية تحت conf.d، حتى لا يكون هناك أي التباس بشأن الإعداد الفعّال. أعد التشغيل، ثم أثبت أن Synapse يستخدم Postgres فعلاً:

sudo -u postgres psql synapse -c "SELECT count(*) FROM users;"

يعني ظهور رقم أن Synapse أنشأ مخططه في قاعدة البيانات هذه. أما ظهور خطأ يفيد بغياب علاقة، فيعني أنه ما زال يكتب إلى ملف SQLite، ولذلك فإن ملف الإعداد الذي عدّلته ليس الملف الذي تتم قراءته.

الـReverse Proxy وTLS وملفات .well-known التي تحتاج إليها federation

يستمع Synapse إلى HTTP العادي على المنفذ 8008، ويرتبط بالعنوان المحلي. يتولى Reverse Proxy الموجود أمامه مهمة TLS والمنفذ العام.

listeners:
- port: 8008
  tls: false
  type: http
  x_forwarded: true
  bind_addresses:
  - '::1'
  - '127.0.0.1'
  resources:
  - names:
    - client
    - federation
    compress: false

يخبر x_forwarded: true ‏Synapse بأن يثق في ترويسة X-Forwarded-For التي يضبطها الـproxy. من دونها، سيبدو كل عميل وكأنه قادم من 127.0.0.1، ولذلك سيرى تحديد معدل الطلبات مستخدماً محلياً واحداً شديد النشاط، وسيطبّق التقييد على الجميع معاً.

location ~ ^(/_matrix|/_synapse/client) {
    proxy_pass http://localhost:8008;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host:$server_port;
    client_max_body_size 50M;
    proxy_http_version 1.1;
}

تورد وثائق Synapse تحذيراً واحداً بشأن هذه الكتلة، وقد يكلّف تجاهله المستخدمين أياماً من العمل. لا تضف مساراً بعد المنفذ في proxy_pass، ولا حتى / واحداً. عندها يطبّع nginx معرّف URI، فيغيّر البايتات التي وقّعها خادم الإرسال، وتفشل طلبات federation في التحقق من التوقيع، بينما تستمر طلبات العملاء العادية في العمل.

يجب أن تكون قيمة client_max_body_size مساوية لقيمة max_upload_size في Synapse أو أكبر منها. إذا احتفظ nginx بالقيمة الأصغر، فسيرفض nginx عمليات الرفع التي تتجاوزها باستخدام 413 Request Entity Too Large قبل أن يراها Synapse، ولذلك لن يظهر أي سطر في سجل Synapse يفسّر الفشل.

للحصول على الشهادة نفسها، اتبع Certbot وLet's Encrypt على Ubuntu 24.04. إذا لم تحسم اختيار الـproxy بعد، توضّح مقارنة الـReverse Proxy أيّها ينفّذ مهمة TLS نيابةً عنك.

تتيح Delegation إبقاء server_name على example.com بينما يعمل Synapse على matrix.example.com. قدّم ملفين من النطاق الأساسي:

location /.well-known/matrix/server {
    default_type application/json;
    return 200 '{"m.server": "matrix.example.com:443"}';
}

location /.well-known/matrix/client {
    default_type application/json;
    add_header Access-Control-Allow-Origin '*';
    return 200 '{"m.homeserver": {"base_url": "https://matrix.example.com"}}';
}

يخبر ملف الخادم خوادم homeserver الأخرى بمكان إرسال حركة federation، وبذلك تعمل federation عبر 443 بدلاً من المنفذ الافتراضي 8448. ويخبر ملف العميل عملاء Matrix بعنوان URL الذي يخدم @alice:example.com. وتهم ترويسة Access-Control-Allow-Origin في ملف العميل لأن العملاء المستندين إلى المتصفح يجلبونه من مصدر مختلف؛ ومن دون هذه الترويسة يحظر المتصفح الاستجابة، ويبلّغ العميل بأنه لا يستطيع العثور على homeserver الخاص بك.

يجب تقديم كلا الملفين عبر TLS صالح ومن example.com نفسه. افحصهما، ثم افحص ما يراه العالم الخارجي:

curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version

يعرض الأمر الأول JSON الذي كتبته. ويعرض الأمر الثاني كائن JSON يذكر تنفيذ الخادم وإصداره، ما يثبت أن الـproxy يصل إلى Synapse عبر مسار federation. ثم اختبر النطاق باستخدام أداة Matrix federation tester على https://federationtester.matrix.org، فهي تتبع المسار نفسه الذي يسلكه خادم بعيد فعلياً.

التخ federation أو عدمه: اتخذ القرار عمداً

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

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

لتقييد federation بدلاً من تعطيله، يستخدم Synapse قائمة سماح:

federation_domain_whitelist:
- lon.example.com
- nyc.example.com

توصي الوثائق أيضاً بتصفية federation listener عبر الجدار الناري، بحيث تتوقف حركة الشبكة غير المرغوبة عند طبقة الشبكة بدلاً من وصولها إلى Python. لتعطيل federation بالكامل، أزل federation من قائمة resources الخاصة بـlistener، ولا تنشر /.well-known/matrix/server، واترك المنفذ 8448 مغلقاً.

إذا كان سبب تشغيل Matrix هو الدردشة الخاصة بالفريق ولم تكن federation جزءاً من الخطة قط، فقارن تكلفة التشغيل بالبدائل الأخرى لـSlack المستضاف ذاتياً قبل الالتزام بـSynapse. يوفّر Rocket.Chat على Docker Compose دردشة للفريق على جهاز أصغر، لأنه لا يحتاج أبداً إلى تخزين حالة غرف مؤسسة أخرى.

مستودع الوسائط هو ما يملأ القرص بصمت

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

اعثر على مخزن الوسائط وقِس حجمه:

grep media_store_path /etc/matrix-synapse/homeserver.yaml
sudo du -sh /var/lib/matrix-synapse/media_store

قِس المسار الذي تطبعه إعداداتك الخاصة. تحتفظ حزمة Debian ببيانات Synapse ضمن /var/lib/matrix-synapse، لذلك يوجد المخزن عادةً هناك. ثم عيّن سياسة للاحتفاظ في conf.d:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

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

لإجراء تنظيف لمرة واحدة، تتطلب واجهة الإدارة البرمجية طابعاً زمنياً بنظام Unix وبوحدة المللي ثانية:

BEFORE_TS=$(date -d '30 days ago' +%s%3N)
curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  "https://matrix.example.com/_synapse/admin/v1/purge_media_cache?before_ts=$BEFORE_TS"

يحذف POST /_synapse/admin/v1/purge_media_cache الوسائط البعيدة المخزنة مؤقتاً التي كان آخر وصول إليها قبل ذلك الطابع الزمني. ويحذف POST /_synapse/admin/v1/media/delete?before_ts=<ms> الوسائط المحلية وفق القاعدة نفسها. نفّذ تنظيف الوسائط البعيدة أولاً ثم قِس الحجم مرة أخرى، لأن ذاكرة التخزين المؤقت البعيدة تكون عادةً الجزء الأكبر على الخادم الذي يستخدم federation.

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

أغلِق التسجيل قبل أن يعثر أحد على خادمك المنزلي

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

يأتي Synapse مغلقاً افتراضياً. تكون enable_registration مضبوطة افتراضياً على false، وتكون registration_requires_token مضبوطة افتراضياً على false. كما يرفض Synapse التشغيل عند تفعيل التسجيل من دون خطوة تحقق، ما لم تضبط أيضاً enable_registration_without_verification: true. هذا الرفض مقصود، لذلك لا تفعّل هذا الخيار لإخفاء خطأ بدء التشغيل.

أنشئ الحسابات المطلوبة يدوياً:

sudo register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http://localhost:8008

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

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

enable_registration: true
registration_requires_token: true

curl -X POST -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"uses_allowed": 1}' \
  https://matrix.example.com/_synapse/admin/v1/registration_tokens/new

اترك token خارج المحتوى، وسيُنشئ Synapse رمزاً ويعيده إليك. يسرد GET /_synapse/admin/v1/registration_tokens الرموز الفعالة. يتطلب الاستدعاءان رمز الوصول لحساب مسؤول للخادم، ويمكنك الحصول عليه بتسجيل الدخول إلى حساب المسؤول الذي أنشأته أعلاه.

يمكن للمؤسسة التي تدير الحسابات في مكان آخر تجاوز كلمات المرور المحلية بالكامل، لأن Synapse يستطيع تفويض تسجيل الدخول إلى موفّر OIDC (OpenID Connect)، مثل Authentik كموفّر SSO مستضاف ذاتياً. عندها تُدار عمليات انضمام المستخدمين ومغادرتهم من مكان واحد.

نسخة احتياطية يمكنها فعلياً إعادة بناء الخادم

تتكوّن نسخة Synapse الاحتياطية من ثلاثة أجزاء، وأي نسخة تفتقد أحدها ستعيد خادماً لا يستطيع أحد استخدامه.

• قاعدة بيانات Postgres، التي تحتوي على كل حدث وحساب وغرفة.
• دليل مخزن الوسائط، الذي يحتوي على كل ملف مرفوع.
• /etc/matrix-synapse، الذي يحتوي على إعداداتك ومفتاح توقيع الخادم.

مفتاح التوقيع هو الجزء الذي ينساه الناس. وهو المفتاح الخاص الذي يوقّع به homeserver الأحداث، بينما تتحقق الخوادم البعيدة من الأحداث باستخدام المفتاح العام المطابق. نفّذ grep signing_key_path /etc/matrix-synapse/homeserver.yaml لمعرفة موقعه. إذا فقدته، فستستعيد خادماً لا يستطيع إثبات أنه الخادم نفسه الذي تعرفه غرفك مسبقاً.

sudo -u postgres pg_dump --format=custom --file=/var/backups/synapse-$(date +%F).dump synapse
sudo tar czf /var/backups/synapse-etc-$(date +%F).tgz -C /etc matrix-synapse

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

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

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

عندما تكبر جداول الحالة: الضغط

يخزّن Synapse حالة الغرف في مجموعات حالة، وعلى الخادم الذي يدعم federation تصبح state_groups_state غالباً أكبر كائن في قاعدة البيانات. قِس أولاً قبل تغيير أي شيء:

sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));"

إذا كان هذا الجدول وحده يشغل معظم مساحة قاعدة البيانات، يوفّر المشروع أداة ضغط له، وهي rust-synapse-compress-state، وتعيد كتابة تسلسل مجموعات الحالة في عدد أقل من الصفوف من دون تغيير معنى حالة أي غرفة. الأداة مبنية باستخدام Rust:

sudo apt install -y build-essential libssl-dev pkg-config git
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
git clone https://github.com/matrix-org/rust-synapse-compress-state.git
cd rust-synapse-compress-state/synapse_auto_compressor
cargo build --release

./target/release/synapse_auto_compressor -p postgresql://synapse_user:secretpassword@localhost/synapse -c 500 -n 100

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

هناك تفصيل في Postgres يفاجئ بعض المستخدمين. يؤدي حذف الصفوف إلى إعادة المساحة إلى Postgres لإعادة استخدامها، وليس إلى نظام الملفات، لذلك قد لا يتغير df إطلاقاً بعد عملية ضغط كبيرة. تعيد VACUUM FULL المساحة إلى نظام الملفات، وتتطلب قفلاً حصرياً على الجدول ومساحة قرص حرة تعادل حجم الجدول تقريباً. لذلك جدوِل تشغيلها ضمن أعمال الصيانة، ولا تشغّلها عشوائياً.

فحوصات تؤكد أن الخادم يعمل بصورة سليمة

systemctl status matrix-synapse
curl -s https://example.com/.well-known/matrix/server
curl -s https://matrix.example.com/_matrix/federation/v1/version
sudo -u postgres psql synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));"
sudo du -sh /var/lib/matrix-synapse/media_store

يعني العمل بصورة سليمة أن تكون الوحدة نشطة وألا تعيد التشغيل، وأن يعرض ملف التفويض قيمة m.server الخاصة بك، وأن يعيد endpoint إصدار federation بيانات JSON، وأن تتمكن من مقارنة رقمي الحجم ببيانات الشهر الماضي. غالباً ما يتجاهل الأشخاص فحوصات الأحجام، لكن امتلاء القرص هو العطل الذي يوقف خادم Synapse من دون تحذير: فعندما يمتلئ volume، يتوقف Postgres عن الكتابة، ثم يفشل Synapse في كل طلب يتعامل مع قاعدة البيانات.

FAQ

كم مقدار RAM الذي يحتاجه خادم Matrix Synapse؟

بالنسبة إلى homeserver خاص يضم بضعة مستخدمين وغرفاً صغيرة ولا يحتوي على غرف عامة كبيرة، يكفي 2 GB عادةً. وهذا ما توصي به معظم صفحات تحديد الموارد المنشورة حتى August 2026. تطلب وثائق Synapse توفير 1 GB على الأقل من RAM الحرة بالإضافة إلى الموارد الأخرى إذا كان المستخدمون سينضمون إلى غرف عامة كبيرة مثل #matrix:matrix.org، لأن خادمك سيخزّن عندئذٍ حالة تلك الغرفة ويعالج حركة مرورها باستمرار. أضف swap إلى خطة 2 GB حتى لا يؤدي انضمام كبير واحد إلى إنهاء العملية بواسطة kernel.

هل يجب أن أستخدم PostgreSQL بدلاً من SQLite؟

بعد تجاوز عدد قليل من المستخدمين، نعم. يسمح SQLite بعملية كتابة واحدة في كل مرة، لذلك تحجب حركة federation وطلبات العملاء بعضها بعضاً تحت الحمل، وتبقى الطلبات معلقة لثوانٍ في كل مرة. تتطلب عمليات worker في Synapse، وهي الطريقة المدعومة لاستخدام أكثر من نواة CPU واحدة، استخدام Postgres. يمكن تنفيذ الترحيل لاحقاً باستخدام synapse_port_db، لكنه يتطلب فترة توقف، لذلك أنشئ قاعدة البيانات باستخدام --encoding=UTF8 --locale=C --template=template0 قبل إضافة المستخدمين.

لماذا يستمر استخدام Synapse لمساحة القرص في الازدياد؟

يوجد سببان رئيسيان: دليل واحد وجدول واحد. يحتفظ media store بكل ملف رُفع إلى الغرف التي يوجد فيها خادمك، بما في ذلك النسخ المخزنة مؤقتاً من وسائط المستخدمين البعيدين والصور المصغرة المُنشأة، ولا تنتهي صلاحية أي منها حتى تضبط media_retention. يزداد حجم جدول state_groups_state مع حالة الغرف على الخادم الذي يستخدم federation، ويقلله rust-synapse-compress-state. قِس كلاً منهما باستخدام du -sh على media_store_path، وباستخدام SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));، قبل أن تحدد ما ستعالجه.

كيف أمنع الغرباء من التسجيل في homeserver الخاص بي؟

اترك enable_registration على قيمته الافتراضية false، وأنشئ الحسابات باستخدام register_new_matrix_user. عندما لا يعود ذلك قابلاً للتوسع، اضبط enable_registration: true مع registration_requires_token: true، ووزّع الرموز المميزة التي أُنشئت باستخدام POST /_synapse/admin/v1/registration_tokens/new. لا تضبط enable_registration_without_verification: true لمجرد إسكات رفض Synapse بدء التشغيل، لأن homeserver المفتوح يصبح مصدراً للرسائل المزعجة، وسيردّ المسؤولون الآخرون بحظر نطاقك بالكامل.

هل ينبغي أن يستخدم homeserver الخاص بي federation؟

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