Behebung von Verzögerungen und langsamen Raumbeitritten bei Matrix Synapse Federation

Beginnen Sie damit, die Verzögerung zu lokalisieren.

Wenn das Öffnen oder Beitreten eines Matrix-Raums lange dauert, prüfen Sie zunächst, ob die Verzögerung einen einzelnen Remote-Homeserver, einen einzelnen Raum oder Ihre gesamte Synapse-Instanz betrifft. Diese Unterscheidung ist wichtig: Die Föderation ist ein bidirektionaler Datenaustausch zwischen Homeservern, und der Beitritt zu einem Raum kann mehrere Server involvieren. Langsame Beitritte können durch Ihren Synapse-Prozess, den Remote-Server, das DNS- oder TLS-Routing, die Datenbank oder die Größe und den Status des Raums verursacht werden. Es gibt keine pauschale Lösung für all diese Probleme.

Bestätigt: Synapse protokolliert Informationen zu Wiederholungsversuchen an entfernte Ziele, stellt Prometheus-Metriken bereit und beinhaltet Ratenbegrenzungen für den Beitritt zu Räumen. Situationsabhängig: Welcher dieser Faktoren ist für einen einzelnen langsamen Beitritt verantwortlich? Allein anhand des Symptoms lässt sich dies nicht feststellen: Ist der andere Homeserver oder ein zwischengeschaltetes Netzwerk langsam? Beginnen Sie mit einem betroffenen Benutzer, einem Raum und der ungefähren Dauer eines langsamen Verbindungsversuchs; vergleichen Sie diese Daten mit einem Kontrollraum, der normal beitritt.

Prüfen Sie, ob die Föderation erreichbar ist.

Verwenden Sie den offiziellen Matrix Federation Tester mit dem Matrix-Servernamen Ihres Heimservers. Er kann häufige DNS-, Delegierungs-, Zertifikats- und Erreichbarkeitsprobleme aufdecken. Der Servername in Benutzer-IDs kann von dem Rechner oder Proxy abweichen, der Synapse bereitstellt. Überprüfen Sie daher den konfigurierten Verbundendpunkt und die Delegierung, anstatt anzunehmen, dass die Benutzer-ID-Domäne Synapse direkt hosten muss.

Die Dokumentation zur Synapse-Federation beschreibt TCP 8448 als Standard-Federationsport. Delegierte oder Reverse-Proxy-Bereitstellungen können hingegen HTTPS auf Port 443 verwenden. Der entsprechende Port muss von anderen Homeservern aus erreichbar sein, und ausgehende Firewalls müssen gegebenenfalls den Federation-Datenverkehr zulassen. Überprüfen Sie die entsprechenden Firewallregeln für eingehenden und ausgehenden Datenverkehr und testen Sie die Verbindung anschließend erneut mit dem Federation Tester. Öffnen Sie nicht beide Ports gleichzeitig, wenn Ihre Bereitstellung nur für einen Port konfiguriert ist.

Ein Ergebnis, das einen Zertifikats-, DNS- oder Routingfehler anzeigt, deutet auf ein Konfigurations- oder Netzwerkproblem hin, nicht auf eine Serverkapazität. Überprüfen Sie die DNS-Einträge und die Delegierung für den Matrix-Servernamen, die TLS-Zertifikatskette des Reverse-Proxys und ob der Proxy die Verbundpfade an Synapse weiterleitet. Synapse dokumentiert, dass eine 308-Weiterleitung in manchen Konfigurationen von den Verbundservern nicht befolgt wird. Untersuchen Sie daher auch unerwartete Weiterleitungen. Beheben Sie den Fehler in der jeweiligen Prüfung und testen Sie erneut, bevor Sie die Anzahl der Worker oder die Ratenbegrenzungen ändern.

Referenz: Synapse-Federation-Einrichtung und Fehlerbehebung sowie Synapse-Firewall-Leitfaden .

Prüfen Sie, ob sich ein Remote-Server im Wiederholungs-Cooldown befindet.

Synapse markiert ein Remote-Ziel vorübergehend als offline, wenn Verbundanfragen fehlschlagen. Wiederholungsversuche werden mit Backoff-Funktion ausgeführt, sodass wiederholte Fehler dazu führen können, dass Nachrichten oder Joins mit diesem Ziel verzögert erscheinen. Dies ist kein Hinweis darauf, dass Ihr gesamter Homeserver langsam ist: Es kann auch ein einzelner Remote-Server sein, der nicht erreichbar ist oder Anfragen nicht korrekt verarbeitet.

Administratoren können die Synapse Federation Admin API einsehen, die dies dokumentiert GET /_synapse/admin/v1/federation/destinations. Verwenden Sie ein Serveradministrator-Zugriffstoken und behandeln Sie es vertraulich. Überprüfen Sie die Zieldatensätze und Wiederholungsfelder des betroffenen Homeservers im betreffenden Raum. Diese Datensätze helfen dabei, Wiederholungsversuche eines Ziels zu identifizieren, beweisen aber allein nicht die Ursache des Verbindungsfehlers. Korrelieren Sie diese Daten mit Synapse-Protokollen, Proxy-Protokollen, DNS/TLS-Tests und den Zeitpunkten, zu denen Benutzer Probleme gemeldet haben.

Die Federation Admin API ist als experimentell dokumentiert und kann sich ändern. Vermeiden Sie es, sie wie eine stabile, öffentliche Client-API zu verwenden. Synapse dokumentiert außerdem eine Operation zum Zurücksetzen des Verbindungs-Timeouts, die einen weiteren Hintergrundversuch für ein bereits im Cooldown befindliches Ziel auslösen kann. Nutzen Sie diese Operation nur dann als Diagnose- oder Wiederherstellungsmaßnahme, wenn Sie die zugrunde liegende Fehlerursache behoben oder verstanden haben. Das wiederholte Zurücksetzen von Cooldowns kann einen fehlerhaften Remote-Server nicht zum Antworten bringen. Eine erfolgreiche HTTP-Antwort vom Reset-Endpunkt bedeutet nicht, dass der Hintergrundversuch zur Föderation bereits abgeschlossen ist.

Referenz: Synapse Federation Admin API . Der experimentelle Status der API und die verfügbaren Felder können sich je nach Synapse-Version ändern. Überprüfen Sie daher vor der Verwendung einer Operation die Dokumentation für die von Ihnen verwendete Version.

Messen Sie Synapse und seine Datenbank vor der Skalierung.

Aktivieren Sie den Prometheus-Metrik-Endpunkt von Synapse nur in einem vertrauenswürdigen internen Netzwerk oder hinter Zugriffskontrollen. Die offizielle Überwachungsanleitung beschreibt /_synapse/metricsund zeigt, wie Sie ihn über einen Metrik-Listener oder einen vorhandenen HTTP-Listener bereitstellen. Metriken können Betriebsdetails enthalten; veröffentlichen Sie diesen Endpunkt daher nicht öffentlich. Wenn Sie bereits Metriken erfassen, vergleichen Sie die Zeit eines langsamen Joins mit CPU-, Speicher- und Anfragelatenz, Datenbanktransaktionsdauer sowie eingehender und ausgehender Federation-Aktivität.

Nutzen Sie die Diagramme, um allgemeine Überlastung von föderationsspezifischen Verzögerungen zu unterscheiden. Wenn normale Clientanfragen und Datenbanktransaktionen gleichzeitig mit Joins langsamer werden, überprüfen Sie die CPU- und Speicherauslastung des Hosts, den Zustand von PostgreSQL, Verbindungslimits, Festplattenlatenz und langlaufende Abfragen. Wenn die Aktivität im lokalen Raum weiterhin reagiert, aber ein entferntes Ziel Ausfälle oder Verzögerungen bei Wiederholungsversuchen aufweist, priorisieren Sie die Erreichbarkeit der Föderation und diesen entfernten Server. Wenn nur ein großer Raum betroffen ist, können der Raumstatus und die Anzahl der teilnehmenden Server eine Rolle spielen; vergleichen Sie ihn mit einem kleineren Raum, bevor Sie Schlussfolgerungen ziehen.

Synapses Grafana-Leitfaden empfiehlt, die Nachrichtenlaufzeit, CPU- und Speicherauslastung, Anzahl und Dauer von Datenbanktransaktionen sowie Verbunddiagramme zu überprüfen. Eine hohe Transaktionsanzahl ist nicht automatisch der Flaschenhals; auch Dauer und Systemlast spielen eine Rolle. Überprüfen Sie die Metriknamen Ihrer installierten Synapse-Version und die aktuelle Dashboard-Dokumentation, da sich die Metriken im Laufe der Zeit geändert haben.

Referenzen: Synapse Prometheus-Überwachung und Verständnis von Synapse mithilfe von Grafana-Diagrammen .

Überprüfen Sie die Drosselung und die Aussetzer beim Raumzusammentritt.

Synapse hat separate rc_joinsBeschränkungen für lokale und Remote-Beitritte. Ein Remote-Beitritt kann mehr Aufwand erfordern als der Beitritt zu einem Raum, an dem der Server bereits teilnimmt. Synapse verfügt außerdem rc_joins_per_roomüber eine Begrenzung der Beitritte zu einem Raum, um Massenansammlungen von Beitritten zu verhindern. Falls Protokolle oder Client-Antworten auf eine Ratenbegrenzung hinweisen, überprüfen Sie diese Einstellungen und das Beitrittsvolumen der letzten Zeit, bevor Sie Änderungen vornehmen.

Erhöhen Sie die Ratenbegrenzungen nicht pauschal, um die Geschwindigkeit zu verbessern. Höhere Grenzwerte können die Last auf Ihrem Server und anderen Heimservern erhöhen und den Schutz vor Join-Floods verringern. Wenn eine legitime Migration oder ein Onboarding-Ansturm einen konfigurierten Grenzwert erreicht, ermitteln Sie den genauen Grenzwert und überprüfen Sie die aktuell dokumentierten Werte für Ihre Synapse-Version. Erwägen Sie, die Join-Last zeitlich zu verteilen. Ändern Sie jeweils nur einen relevanten Wert, behalten Sie die vorherige Konfiguration bei und überwachen Sie Fehlerraten und Ressourcennutzung nach jedem Neustart oder Neuladen, wie es Ihre Bereitstellung erfordert.

Referenz: Synapse-Konfiguration:rc_joins und Synapse-Konfiguration:rc_joins_per_room . Standardwerte und unterstützte Optionen können je nach Version variieren; vergleichen Sie diese mit Ihrer installierten Version, bevor Sie Änderungen vornehmen.

Führen Sie einen kontrollierten Verbindungstest durch.

1. Wählen Sie einen betroffenen Raum aus und notieren Sie den Raumalias oder die Raum-ID, den Homeserver des beitretenden Benutzers, die Uhrzeit und den genauen Clientfehler. Fügen Sie niemals Zugriffstoken in ein Support-Protokoll ein.
2. Überprüfen Sie im Federation Tester Ihren Servernamen und bestätigen Sie den konfigurierten Verbundendpunkt, das Zertifikat und die Proxy-Route.
3. Überprüfen Sie die Synapse-Protokolle um diesen Zeitpunkt auf Föderationsfehler, Fehler beim Remote-Ziel, Timeouts oder Ratenbegrenzungsreaktionen. Suchen Sie in den Protokollen des Reverse-Proxys und der Datenbank nach entsprechenden Verzögerungen.
4. Prüfen Sie die Federation Admin API auf den Wiederholungsstatus der relevanten Remote-Ziele. Vergleichen Sie die betroffenen Räume mit einem Kontrollraum, der sich umgehend verbindet.
5. Vergleichen Sie die Metriken von Prometheus und des Hosts im gleichen Zeitraum. Achten Sie auf erhöhte Anfragelatenz, Datenbanktransaktionsdauer, CPU- oder Speicherauslastung oder einen Anstieg der Föderationsaktivität.
6. Nehmen Sie eine gezielte Korrektur vor – beispielsweise die Behebung eines DNS/TLS/Proxy-Problems, die Beseitigung eines Datenbankengpasses oder die Anpassung einer bestätigten Ratenbegrenzung – und wiederholen Sie dann den gleichen Test und vergleichen Sie die Ergebnisse.

Häufige Annahmen, die es zu vermeiden gilt

• „Ein langsamer Verbindungsaufbau bedeutet, dass Port 8448 meines Servers geschlossen ist.“ Nicht unbedingt. Delegierung oder ein Reverse-Proxy verwenden möglicherweise Port 443. Überprüfen Sie den tatsächlich konfigurierten Verbundendpunkt und testen Sie ihn.
• „Ein erfolgreicher Verbundtest beweist, dass jeder Beitritt zu einem Raum schnell erfolgt.“ Er prüft jedoch nur die gängige Verbundkonfiguration und -verbindung. Der Zustand des Remote-Servers, der Raumstatus, die lokale Auslastung und die Datenbankleistung können den Beitritt weiterhin beeinflussen. Testen Sie den betroffenen Raum und prüfen Sie die Protokolle.
• „Die Verzögerung bei der Föderation tritt immer bei meiner Synapse-Instanz auf.“ Die Konfigurationsdokumentation von Synapse weist jedoch darauf hin, dass die beobachtete Verzögerung sowohl an einem der Endpunkte als auch im Netzwerk dazwischen entstehen kann. Vergleichen Sie die Ziele und sammeln Sie nach Möglichkeit von beiden Seiten Beweise.
• „Das Hinzufügen weiterer Worker oder die Erhöhung der Ratenbegrenzungen ist die erste Lösung.“ Diese Änderungen sind jedoch nur dann sinnvoll, wenn Messungen auf Kapazitätsengpässe oder Drosselung hinweisen. Zunächst muss ermittelt werden, ob das Problem in der Konnektivität, in Remote-Wiederholungsversuchen, in der lokalen Auslastung, in der Datenbanklatenz oder in der Ratenbegrenzung von Joins liegt.

Überprüfen Sie, ob die Reparatur funktioniert hat.

Wiederholen Sie den Beitrittstest nach der Änderung. Stellen Sie sicher, dass der Benutzer erfolgreich beitritt, das betroffene Ziel nicht mehr wiederholt fehlschlägt, der Federation Tester die relevanten Prüfungen korrekt meldet und die Anfrage-/Datenbanklatenz wieder im normalen Bereich liegt. Achten Sie auf ein erneutes Auftreten des Problems während einer späteren Stoßzeit; ein einzelner erfolgreicher Versuch beweist nicht, dass der Remote-Server oder das Netzwerk dauerhaft fehlerfrei funktioniert.

Wenn Ihre lokalen Metriken und Verbundprüfungen in Ordnung erscheinen, aber nur ein Remote-Homeserver weiterhin ausfällt, teilen Sie den Administratoren dieses Servers den Zeitstempel, das Ziel, die bereinigte Fehlermeldung und die relevanten Anfrage-IDs mit. Sind mehrere Räume und Ziele betroffen und gleichzeitig lokale Anfragen langsam, prüfen Sie die Kapazität von Synapse und PostgreSQL, bevor Sie das Verbundverhalten optimieren. Notieren Sie Ihre Synapse-Version in den Vorfallsnotizen, da sich Konfiguration und Details der Admin-API ändern können.