Cara Self-host Matrix Synapse di VPS dengan Betul

Keperluan untuk memastikan homeserver Matrix Synapse terus beroperasi

Matrix Synapse mudah dipasang tetapi juga mudah diabaikan. Pemasangannya hanya memerlukan satu repositori apt, satu fail konfigurasi, satu blok reverse proxy dan satu DNS record. Mengekalkan kesihatan homeserver untuk tempoh setahun memerlukan usaha yang berbeza: pangkalan data sebenar, storan media yang perlu dicantas, pendaftaran yang tidak boleh digunakan oleh orang asing, serta sandaran yang merangkumi kedua-dua bahagian pelayan.

Panduan ini menyasarkan Ubuntu 24.04 LTS dan memasang Synapse daripada repositori apt matrix.org, iaitu sumber pakej yang diselenggara oleh projek Synapse untuk Debian dan Ubuntu. Versi pakej berubah setiap beberapa minggu, jadi tiada nombor versi dinyatakan di sini. Setiap path dan pilihan di bawah diambil daripada dokumentasi Synapse semasa.

Saiz: apa yang anda benar-benar peroleh dengan 1 vCPU dan 2 GB RAM

Halaman saiz yang diterbitkan, setakat Ogos 2026, biasanya meletakkan homeserver Synapse pada 1 vCPU dan 2 GB RAM. Itu adalah jujur untuk satu kes: pelayan peribadi, beberapa pengguna, bilik kecil, dan tiada bilik awam yang sibuk. Dokumentasi Synapse adalah terus terang mengenai kes yang satu lagi. Ia meminta "Sekurang-kurangnya 1GB RAM percuma jika anda ingin menyertai bilik awam yang besar seperti #matrix:matrix.org". RAM percuma, di samping Python, Postgres dan kernel.

Satu bilik boleh mengubah saiz anda, disebabkan oleh cara penyertaan berfungsi. Apabila pengguna tempatan menyertai bilik, homeserver anda menjadi peserta penuh dalam bilik tersebut. Ia menerima setiap acara di dalamnya daripada setiap pelayan lain di dalamnya, ia mengesahkan tandatangan pada setiap satu, dan ia menyimpan status bilik secara tempatan. Bilik awam yang besar mempunyai beribu-ribu ahli yang tersebar di ratusan pelayan, jadi kotak anda melakukan kerja itu secara berterusan sama ada pengguna anda membuka bilik itu lagi atau tidak. Meninggalkan bilik kemudian tidak memadamkan sejarah yang telah anda simpan.

Kebanyakan RAM Synapse pergi ke cache. Bahagian caches mempunyai global_factor yang menskalakan setiap cache sekaligus, dan pemboleh ubah persekitaran SYNAPSE_CACHE_FACTOR menetapkan perkara yang sama. Meningkatkannya membelanjakan RAM untuk mengelakkan pertanyaan pangkalan data. Menurunkannya membelanjakan masa CPU dan Postgres untuk menjimatkan RAM. Postgres mahukan memorinya sendiri, jadi pada kotak 2 GB kedua-duanya bersaing untuk megabait yang sama.

Dua peraturan praktikal untuk pelan kecil. Tambah swap: swap tidak akan menjadikan Synapse pantas, tetapi ia menghalang kernel daripada mematikan proses semasa penyertaan besar. Kemudian pantau cakera dari minggu pertama, kerana dua perkara yang berkembang tanpa had ialah stor media dan jadual status bilik, dan kedua-duanya berada pada cakera.

Mengapa Postgres, dan mengapa SQLite bukan lagi pilihan

Pakej Debian bermula dengan SQLite. Ini memadai untuk but pertama, namun tidak sesuai untuk pelayan yang digunakan oleh orang lain. SQLite hanya membenarkan seorang penulis pada satu-satu masa. Trafik persekutuan (federation) dan permintaan pelanggan menulis pada saat yang sama, jadi permintaan yang ringan terpaksa menunggu di belakang permintaan yang perlahan, dan simptom yang dilaporkan oleh pengguna anda ialah aplikasi terhenti selama beberapa saat secara rawak.

Sebab kedua adalah dari segi struktur. Proses pekerja (worker processes) Synapse merupakan cara yang disokong untuk menggunakan lebih daripada satu teras CPU, dan pekerja memerlukan Postgres. Kekal menggunakan SQLite bermakna anda melepaskan laluan naik taraf serta prestasi yang lebih baik.

Penghijrahan pada masa hadapan disokong tetapi ia memerlukan waktu henti (downtime), jadi lakukanlah sebelum anda mempunyai pengguna. Synapse menyertakan synapse_port_db, yang menyalin pangkalan data SQLite ke dalam pangkalan data Postgres yang telah disediakan:

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

Jika anda lebih gemar menjalankan pangkalan data dalam kontena di samping Synapse, pertimbangan mengenai kelebihan dan kekurangan boleh dirujuk dalam menjalankan pangkalan data anda dalam Docker atau pada hos.

Memasang Synapse pada 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

Pada Ubuntu 24.04, lsb_release -cs akan mencetak noble, dan repositori matrix.org menerbitkan suite noble. Jangan gunakan pakej matrix-synapse daripada arkib Ubuntu sendiri. Projek Synapse meminta anda untuk tidak berbuat demikian, kerana binaan tersebut ketinggalan berbanding release mereka dan mengandungi pepijat keselamatan yang diketahui.

Pemasang akan meminta nama pelayan dan menulis jawapan tersebut ke dalam /etc/matrix-synapse/conf.d/server_name.yaml. Jawab dengan teliti. server_name ialah bahagian selepas titik bertindih dalam setiap ID pengguna (@alice:example.com) dan ia terbenam dalam setiap bilik yang dicipta oleh pelayan anda. Menukarnya kemudian tidak akan memindahkan apa-apa: ia akan menghasilkan homeserver yang berbeza. Gunakan domain asas anda, example.com, walaupun Synapse sendiri akan berjalan pada matrix.example.com. Delegasi menghubungkan kedua-duanya, dan itu adalah bahagian seterusnya.

Pakej ini menjalankan Synapse sebagai pengguna matrix-synapse, menyimpan datanya di bawah /var/lib/matrix-synapse, dan membaca /etc/matrix-synapse/homeserver.yaml diikuti oleh setiap fail dalam /etc/matrix-synapse/conf.d/. Letakkan tetapan anda sendiri dalam fail kecil di dalam conf.d. Naik taraf pakej tidak akan mengubah fail tersebut.

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

Permulaan yang sihat akan menghidupkan listener dan kemudian menjadi senyap. Unit systemd akan memulakan semula servis beberapa saat selepas sebarang penutupan, jadi konfigurasi yang ditolak oleh Synapse akan kelihatan sebagai unit yang bermula dan mati dalam gelung. Baris terakhir jurnal akan menamakan kunci yang ditolaknya.

Halakan Synapse ke 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

Locale bukan sekadar kosmetik. Synapse enggan bermula dengan pangkalan data yang dicipta menggunakan nilai COLLATE dan CTYPE yang berbeza melainkan anda menetapkan allow_unsafe_locale dalam konfigurasi pangkalan data, dan pembaikan yang didokumentasikan selepas itu adalah dengan melakukan dump dan memuatkan semula ke dalam pangkalan data yang dicipta dengan betul. Cipta pangkalan data dengan betul pada kali pertama.

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

Pastikan hanya ada satu kunci database: merentasi semua fail konfigurasi anda. Gantikan blok SQLite di dalam homeserver.yaml dan bukannya menambah salinan kedua di bawah conf.d, supaya tidak timbul persoalan tentang yang mana satu sedang aktif. Mulakan semula, kemudian buktikan Synapse benar-benar menggunakan Postgres:

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

Satu nombor bermakna Synapse telah membina skemanya dalam pangkalan data ini. Ralat tentang hubungan (relation) yang hilang bermakna ia masih menulis ke fail SQLite, jadi konfigurasi yang anda edit bukanlah konfigurasi yang sedang dibaca.

Reverse proxy, TLS dan keperluan fail .well-known untuk federasi

Synapse mendengar pada HTTP biasa di port 8008, yang terikat pada localhost. TLS dan port awam dikendalikan oleh reverse proxy di hadapan Synapse.

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 memberitahu Synapse untuk mempercayai header X-Forwarded-For yang ditetapkan oleh proksi. Tanpanya, setiap klien kelihatan seolah-olah datang dari 127.0.0.1, menyebabkan rate limiting melihat satu pengguna tempatan yang sangat aktif dan menyekat semua orang secara serentak.

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;
}

Dokumentasi Synapse memberikan satu amaran tentang blok ini yang sering membuang masa pengguna selama berhari-hari. Jangan tambah path, walaupun satu /, selepas port dalam proxy_pass. nginx kemudian akan menukar URI kepada bentuk kanonikal, yang mengubah bait yang ditandatangani oleh pelayan penghantar, dan permintaan federasi akan gagal dalam pengesahan tandatangan manakala permintaan klien biasa terus berfungsi.

client_max_body_size mestilah sekurang-kurangnya sama besar dengan max_upload_size milik Synapse. Jika nginx menetapkan nombor yang lebih kecil, muat naik yang melebihi had tersebut akan ditolak oleh nginx dengan ralat 413 Request Entity Too Large sebelum Synapse sempat menerimanya, jadi tiada baris log Synapse yang menjelaskan kegagalan tersebut.

Untuk sijil itu sendiri, ikuti Certbot dan Let's Encrypt pada Ubuntu 24.04. Jika anda masih belum memilih proksi, perbandingan reverse proxy merangkumi proksi mana yang menguruskan tugas TLS untuk anda.

Delegasi ialah perkara yang membolehkan server_name kekal sebagai example.com sementara Synapse berjalan pada matrix.example.com. Hidangkan dua fail daripada domain asal:

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"}}';
}

Fail server memberitahu homeserver lain ke mana untuk menghantar trafik federasi, yang membolehkan federasi berjalan melalui port 443 dan bukannya port lalai 8448. Fail client memberitahu klien Matrix URL mana yang menyokong @alice:example.com. Header Access-Control-Allow-Origin adalah penting pada fail client kerana klien berasaskan pelayar mengambilnya secara cross-origin; tanpa header tersebut, pelayar akan menyekat respons dan klien akan melaporkan bahawa ia tidak dapat mencari homeserver anda.

Kedua-dua fail mesti dihidangkan melalui TLS yang sah daripada example.com itu sendiri. Semak fail tersebut, kemudian semak apa yang dilihat oleh dunia luar:

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

Yang pertama mengembalikan JSON yang anda tulis. Yang kedua mengembalikan objek JSON yang menamakan implementasi pelayan dan versinya, yang membuktikan bahawa proksi mencapai Synapse pada path federasi. Kemudian, jalankan domain anda melalui penguji federasi Matrix di https://federationtester.matrix.org, yang mengikuti laluan yang sama seperti pelayan jauh yang sebenar.

Persekutuan atau tidak: buat keputusan dengan sengaja

Persekutuan (federation) adalah tujuan utama Matrix dan ia juga merupakan sebahagian besar daripada kosnya. Homeserver yang bersekutu menerima sambungan daripada pelayan yang tidak pernah anda kenali, menerima acara mereka, menyimpan cache media mereka, dan menyimpan state untuk setiap bilik yang disentuh oleh pengguna anda. Itu adalah keputusan model ancaman, bukan tetapan lalai.

Bersekutu apabila pengguna anda perlu menghubungi orang di homeserver lain, atau apabila identiti mudah alih adalah sebab anda memilih Matrix. Jangan bersekutu apabila pelayan tersebut wujud untuk satu pasukan dan setiap akaun di dalamnya adalah milik anda. Pelayan tertutup menyimpan lebih sedikit data, menerima lebih sedikit trafik, dan jauh kurang menarik untuk disalahgunakan.

Untuk menyekat dan bukannya melumpuhkan, Synapse menggunakan senarai kebenaran (allow list):

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

Dokumentasi mengesyorkan agar firewall turut digunakan pada listener persekutuan, supaya trafik yang tidak diingini dihentikan di peringkat rangkaian dan bukannya di dalam Python. Untuk mematikan persekutuan sepenuhnya, alih keluar federation daripada senarai resources listener, jangan terbitkan /.well-known/matrix/server, dan biarkan port 8448 ditutup.

Jika sebab anda menjalankan Matrix adalah untuk sembang pasukan peribadi dan persekutuan tidak pernah menjadi sebahagian daripadanya, bandingkan kos operasi dengan alternatif Slack yang dihoskan sendiri yang lain sebelum anda memilih Synapse. Rocket.Chat pada Docker Compose melakukan sembang pasukan pada mesin yang lebih kecil, kerana ia tidak perlu menyimpan state bilik organisasi lain.

Repositori media adalah punca cakera penuh secara senyap

Fail yang dimuat naik oleh pengguna anda kekal pada cakera selama-lamanya. Fail yang dihantar oleh pengguna pada homeserver lain akan diambil dan disimpan dalam cache pada cakera anda sebaik sahaja salah satu klien anda memaparkannya, dan Synapse juga menjana lakaran kecil (thumbnail) untuk imej, jadi satu foto menjadi beberapa fail. Secara lalai, tiada apa-apa yang akan luput.

Cari storan tersebut dan ukur saiznya:

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

Ukur laluan yang dicetak oleh konfigurasi anda sendiri. Pakej Debian menyimpan data Synapse di bawah /var/lib/matrix-synapse, jadi storan biasanya terletak di situ. Kemudian, tetapkan polisi pengekalan dalam conf.d:

media_retention:
  local_media_lifetime: 90d
  remote_media_lifetime: 14d

Baca dua baris tersebut dengan teliti, kerana ia bukan jenis tetapan yang sama. remote_media_lifetime meluputkan cache, dan apa-apa yang dipadamkannya boleh diambil semula daripada pelayan yang memiliki fail tersebut. local_media_lifetime memadamkan muat naik pengguna anda sendiri secara kekal sebaik sahaja ia mencapai usia tersebut. Pasukan yang berkongsi dokumen dalam sembang dan menjangkakan untuk menemuinya pada tahun hadapan akan kehilangan dokumen tersebut. Banyak pelayan hanya menetapkan nilai jauh (remote).

Untuk pembersihan sekali sahaja, API pentadbir mengambil cap masa Unix dalam milisaat:

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 menggugurkan media jauh yang disimpan dalam cache yang kali terakhir diakses sebelum cap masa tersebut. POST /_synapse/admin/v1/media/delete?before_ts=<ms> memadamkan media tempatan mengikut peraturan yang sama. Jalankan pembersihan jauh terlebih dahulu dan ukur semula, kerana pada pelayan yang berfederasi, cache jauh biasanya merupakan bahagian yang lebih besar.

Dua tetapan memberi kesan kepada cakera yang sama. max_upload_size mengehadkan saiz muat naik tunggal dan perlu diselaraskan dengan client_max_body_size dalam nginx. url_preview_enabled: true menyebabkan pelayan anda mengambil halaman jauh supaya klien boleh memaparkan pratonton pautan, yang menggunakan lebar jalur dan menyimpan lakaran kecil kandungan yang tidak dimuat naik oleh sesiapa pun kepada anda.

Tutup pendaftaran sebelum seseorang menemui homeserver anda

Pengimbas akan menemui homeserver yang terbuka dalam masa beberapa hari. Apabila akaun bebas untuk dicipta, pelayan anda akan menjadi sumber spam dalam setiap bilik yang difederasikan, dan pentadbir di pihak lain akan menyekat seluruh domain anda. Kerosakan reputasi tersebut berlarutan lebih lama daripada proses pembersihan, kerana senarai sekatan diselenggara secara manual.

Synapse dihantar dalam keadaan tertutup. enable_registration ditetapkan secara lalai kepada false dan registration_requires_token ditetapkan secara lalai kepada false. Synapse juga enggan bermula jika pendaftaran didayakan tanpa langkah pengesahan, melainkan anda menetapkan enable_registration_without_verification: true secara tambahan. Penolakan itu adalah disengajakan, jadi jangan aktifkannya hanya untuk menghilangkan ralat permulaan.

Cipta akaun yang anda mahukan secara manual:

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

Ia akan meminta nama pengguna, kata laluan, dan sama ada akaun tersebut adalah pentadbir pelayan. Ia membaca registration_shared_secret daripada konfigurasi yang anda berikan dengan -c, jadi jika ia melaporkan bahawa ia tidak dapat menemui shared secret, halakan -c kepada fail yang menyimpannya.

Apabila penciptaan akaun secara manual tidak lagi efisien, token pendaftaran adalah tetapan perantara. Token ialah rentetan yang mesti dikemukakan oleh pengguna baharu semasa mendaftar, dan setiap token boleh membawa had bilangan penggunaan:

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

Biarkan token kosong daripada badan permintaan dan Synapse akan menjana satu serta memulangkannya. GET /_synapse/admin/v1/registration_tokens menyenaraikan token yang masih aktif. Kedua-dua panggilan memerlukan access token daripada akaun pentadbir pelayan, yang anda peroleh dengan log masuk sebagai pengguna pentadbir yang anda cipta di atas.

Organisasi yang sudah menguruskan akaun di tempat lain boleh melangkau kata laluan tempatan sepenuhnya, kerana Synapse boleh mewakilkan log masuk kepada penyedia OIDC (OpenID Connect), contohnya Authentik sebagai penyedia SSO yang dihoskan sendiri. Pengguna yang menyertai dan keluar kemudiannya diuruskan di satu tempat sahaja.

Sandaran yang benar-benar boleh membina semula pelayan

Sandaran Synapse mempunyai tiga bahagian, dan sandaran yang kehilangan salah satu daripadanya akan memulihkan pelayan yang tidak boleh digunakan oleh sesiapa pun.

• Pangkalan data Postgres, yang menyimpan setiap acara, akaun dan bilik.
• Direktori media store, yang menyimpan setiap fail yang dimuat naik.
• /etc/matrix-synapse, yang menyimpan konfigurasi dan kunci penandatangan pelayan anda.

Kunci penandatangan adalah bahagian yang sering dilupakan oleh orang ramai. Ia merupakan kunci peribadi yang digunakan oleh homeserver anda untuk menandatangani acara, dan pelayan jauh akan mengesahkan acara tersebut dengan kunci awam yang sepadan. Jalankan grep signing_key_path /etc/matrix-synapse/homeserver.yaml untuk melihat lokasi penyimpanannya. Jika anda kehilangannya, anda akan memulihkan pelayan yang tidak dapat membuktikan bahawa ia adalah pelayan yang sama yang sudah dikenali oleh bilik-bilik anda.

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

Lakukan dump pangkalan data terlebih dahulu, kemudian salin media store. Fail media ditulis sekali sahaja dan dirujuk mengikut ID, jadi salinan media yang diambil selepas dump hanya boleh mengandungi fail tambahan, tidak akan ada fail yang hilang. Urutan sebaliknya boleh menyebabkan pangkalan data yang dipulihkan merujuk kepada fail yang tidak pernah diambil oleh sandaran anda.

Hantar ketiga-tiga bahagian tersebut keluar dari VPS. restic dengan syot kilat luar tapak sangat sesuai dengan keperluan ini, kerana media store merupakan bahagian yang besar dan ia jarang berubah antara proses sandaran, jadi penyahduplikasian memastikan setiap syot kilat bersaiz kecil.

Kemudian, buat latihan pemulihan, kerana sandaran yang tidak pernah anda pulihkan hanyalah satu hipotesis. Bina VPS kedua, pasang pakej yang sama, pulihkan konfigurasi, cipta pangkalan data dengan pengekodan dan lokal yang sama, pg_restore fail dump ke dalamnya, salin semula media store, dan log masuk. Catatkan berapa lama masa yang diambil. Angka tersebut adalah masa pemulihan sebenar anda.

Apabila jadual keadaan berkembang: pemadatan

Synapse menyimpan keadaan bilik sebagai kumpulan keadaan (state groups), dan pada pelayan yang melakukan federasi state_groups_state sering menjadi objek terbesar dalam pangkalan data. Lakukan pengukuran sebelum anda mengubah apa-apa:

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'));"

Jika jadual tersebut merangkumi sebahagian besar pangkalan data anda, projek ini menerbitkan pemampat untuknya, rust-synapse-compress-state, yang menulis semula hierarki kumpulan keadaan kepada bilangan baris yang lebih sedikit tanpa mengubah maksud keadaan mana-mana bilik. Ia dibina dengan 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 ialah bilangan kumpulan keadaan yang diproses serentak dan -n ialah bilangan ketulan (chunks) tersebut yang diproses dalam satu larian. Pemampat automatik merekodkan setakat mana ia telah memproses, jadi larian seterusnya akan bersambung dari situ, yang menjadikannya selamat untuk dijadualkan. Dokumentasinya menyatakan bahawa perubahan digunakan dalam transaksi terhadap jadual yang bersifat 'append-only', jadi ia boleh dijalankan semasa Synapse sedang aktif. Walau bagaimanapun, buat sandaran pangkalan data sebelum larian pertama.

Satu perincian Postgres mengejutkan pengguna di sini. Memadam baris mengembalikan ruang kepada Postgres untuk digunakan semula, bukan kepada sistem fail, jadi df mungkin tidak berubah langsung selepas pemadatan yang besar. VACUUM FULL mengembalikan ruang tersebut, dan ia memerlukan kunci eksklusif pada jadual serta ruang cakera kosong yang hampir sama dengan saiz jadual, jadi jadualkannya sebagai penyelenggaraan dan bukannya menjalankannya secara semberono.

Semakan yang menunjukkan pelayan dalam keadaan sihat

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

Sihat bermaksud unit tersebut aktif dan tidak dimulakan semula, fail delegasi mengembalikan nilai m.server anda, titik akhir versi persekutuan mengembalikan JSON, dan dua nombor saiz boleh dibandingkan dengan data bulan lepas. Saiz adalah semakan yang sering dilangkau oleh pengguna, dan cakera adalah kegagalan yang menyebabkan pelayan Synapse terhenti tanpa amaran: volum yang penuh menghalang Postgres daripada menulis data, dan Synapse kemudiannya menggagalkan setiap permintaan yang melibatkan pangkalan data.

FAQ

Berapakah jumlah RAM yang diperlukan oleh pelayan Matrix Synapse?

Bagi homeserver peribadi dengan beberapa pengguna, bilik yang kecil dan tiada bilik awam yang besar, 2 GB adalah memadai, dan itulah yang disyorkan oleh kebanyakan halaman penentuan saiz yang diterbitkan setakat Ogos 2026. Dokumentasi Synapse meminta sekurang-kurangnya 1 GB RAM percuma sebagai tambahan jika pengguna anda menyertai bilik awam yang besar seperti #matrix:matrix.org, kerana pelayan anda akan menyimpan status bilik tersebut dan memproses trafiknya secara berterusan. Tambahkan swap pada pelan 2 GB supaya satu penyertaan bilik yang besar tidak menyebabkan proses tersebut ditamatkan oleh kernel.

Adakah saya perlu menggunakan PostgreSQL dan bukannya SQLite?

Jika melebihi segelintir pengguna, ya. SQLite hanya membenarkan satu penulis pada satu masa, jadi trafik federasi dan permintaan pelanggan akan saling menyekat di bawah beban dan permintaan akan tergantung selama beberapa saat. Proses worker Synapse, iaitu cara yang disokong untuk menggunakan lebih daripada satu teras CPU, memerlukan Postgres. Migrasi kemudian boleh dilakukan dengan synapse_port_db dan akan menyebabkan downtime, jadi cipta pangkalan data dengan --encoding=UTF8 --locale=C --template=template0 sebelum anda mempunyai pengguna.

Mengapakah penggunaan cakera Synapse saya terus meningkat?

Satu direktori dan satu jadual. Media store menyimpan setiap fail yang dimuat naik ke dalam bilik yang disertai pelayan anda, termasuk salinan cache media pengguna jauh dan imej kecil yang dijana, dan tiada apa-apa yang tamat tempoh sehingga anda menetapkan media_retention. Jadual state_groups_state berkembang mengikut status bilik pada pelayan yang berfederasi, dan rust-synapse-compress-state mengurangkannya. Ukur kedua-duanya, dengan du -sh pada media_store_path anda dan dengan SELECT pg_size_pretty(pg_total_relation_size('state_groups_state'));, sebelum memutuskan perkara yang perlu dilakukan.

Bagaimanakah cara untuk menghalang orang asing mendaftar pada homeserver saya?

Biarkan enable_registration pada tetapan lalai false dan cipta akaun dengan register_new_matrix_user. Apabila cara itu tidak lagi mencukupi, tetapkan enable_registration: true bersama-sama dengan registration_requires_token: true, dan berikan token yang dicipta melalui POST /_synapse/admin/v1/registration_tokens/new. Jangan tetapkan enable_registration_without_verification: true hanya untuk mendiamkan ralat permulaan Synapse, kerana homeserver yang terbuka akan menjadi sumber spam dan pentadbir lain akan bertindak balas dengan menyekat keseluruhan domain anda.

Patutkah homeserver saya berfederasi?

Federasi adalah keputusan mengenai pendedahan, bukan tetapan lalai. Berfederasilah jika pengguna anda perlu menghubungi orang di homeserver lain. Pastikan ia dimatikan jika pelayan tersebut hanya untuk satu pasukan, kerana pelayan yang tidak berfederasi menyimpan lebih sedikit data, menerima lebih sedikit trafik dan jauh kurang menarik penyalahgunaan. Sebagai jalan tengah, federation_domain_whitelist mengehadkan federasi kepada domain rakan kongsi yang dinamakan, dan dokumentasi Synapse mengesyorkan agar firewall turut digunakan pada pendengar federasi dan tidak hanya bergantung pada semakan lapisan aplikasi tersebut sahaja.