Napraw opóźnienie federacji Matrix Synapse i wolne dołączanie do pomieszczeń

Zacznij od zlokalizowania opóźnienia

Gdy otwarcie lub dołączenie do pokoju Matrix zajmuje dużo czasu, najpierw ustal, czy opóźnienie dotyczy jednego zdalnego serwera domowego, jednego pokoju, czy całej instancji Synapse. To rozróżnienie ma znaczenie: federacja to dwustronna wymiana danych między serwerami domowymi, a dołączenie do pokoju może obejmować kilka serwerów. Powolne dołączanie może być spowodowane przez proces Synapse, serwer zdalny, routing DNS lub TLS, bazę danych lub rozmiar i stan pokoju. Nie ma jednego rozwiązania problemu „opóźnienia federacji”, które rozwiązałoby wszystkie te problemy.

Zweryfikowano: Synapse rejestruje informacje o zdalnych próbach ponownego połączenia z miejscem docelowym, udostępnia metryki Prometheusa i uwzględnia limity szybkości dla połączeń do sal. Zależne od sytuacji: który z tych czynników jest odpowiedzialny za pojedyncze powolne połączenie. Nie można tego stwierdzić na podstawie samego objawu: czy drugi serwer domowy lub sieć pośrednia jest powolna. Zacznij od jednego użytkownika, którego dotyczy problem, jednego pokoju i przybliżonego czasu powolnej próby; porównaj te dane z salą kontrolną, która łączy się normalnie.

Sprawdź, czy federacja jest dostępna

Użyj oficjalnego narzędzia Matrix Federation Tester , podając nazwę serwera Matrix swojego serwera domowego. Narzędzie to może wykryć typowe problemy z DNS, delegacją, certyfikatami i dostępnością. Nazwa serwera w identyfikatorach użytkowników może różnić się od nazwy komputera lub serwera proxy obsługującego Synapse, dlatego sprawdź skonfigurowany punkt końcowy federacji i delegację, zamiast zakładać, że domena identyfikatora użytkownika musi bezpośrednio hostować Synapse.

Dokumentacja federacyjna Synapse opisuje domyślny port federacyjny jako TCP 8448, podczas gdy wdrożenia z delegacją lub odwrotnym proxy mogą używać protokołu HTTPS na porcie 443. Odpowiedni port musi być dostępny z innych serwerów domowych, a zapory sieciowe dla ruchu wychodzącego mogą również wymagać zezwolenia na ruch federacyjny. Sprawdź pasujące reguły zapory sieciowej dla ruchu przychodzącego i wychodzącego, a następnie przetestuj ponownie za pomocą narzędzia Federation Tester. Nie otwieraj obu portów bez rozróżnienia, jeśli wdrożenie jest skonfigurowane do używania tylko jednego.

Wynik pokazujący błąd certyfikatu, DNS lub routingu wskazuje na konfigurację lub dostępność sieci, a nie na wydajność serwera. Sprawdź rekordy DNS i delegację dla nazwy serwera Matrix, łańcucha certyfikatów TLS odwrotnego serwera proxy oraz sprawdź, czy serwer proxy przekierowuje ścieżki federacji do Synapse. Synapse dokumentuje, że w niektórych konfiguracjach serwery federacyjne nie stosują stałego przekierowania 308, więc sprawdź również nieoczekiwane przekierowania. Napraw konkretny błąd sprawdzania i przetestuj ponownie przed zmianą liczby procesów roboczych lub limitów przepustowości.

Odniesienie: Konfiguracja i rozwiązywanie problemów federacji Synapse oraz wskazówki dotyczące zapory Synapse .

Sprawdź, czy jeden serwer zdalny znajduje się w fazie odnowienia próby

Synapse tymczasowo oznacza zdalny serwer docelowy jako offline po niepowodzeniu żądań federacji. Opóźnienia ponawiania prób korzystają z funkcji backoff, więc powtarzające się błędy mogą powodować, że wiadomości lub połączenia dotyczące tego serwera docelowego będą wyświetlane jako opóźnione. Nie świadczy to o powolnym działaniu całego serwera domowego: może to być pojedynczy serwer zdalny, który jest niedostępny lub nie obsługuje żądań.

Administratorzy mogą przeglądać interfejs API administratora federacji Synapse, który dokumentuje GET /_synapse/admin/v1/federation/destinations… Użyj tokenu dostępu administratora serwera i zachowaj go w tajemnicy. Przejrzyj rekordy miejsc docelowych i pola ponownych prób dla serwera domowego powiązanego z danym pomieszczeniem. Te rekordy pomagają zidentyfikować, kiedy miejsce docelowe ponawia próbę, ale same w sobie nie dowodzą przyczyny niepowodzenia połączenia. Porównaj je z dziennikami Synapse, dziennikami serwerów proxy, testami DNS/TLS oraz czasami, w których użytkownicy zgłaszali problemy.

Interfejs API administratora federacji jest udokumentowany jako eksperymentalny i może ulec zmianie. Należy unikać tworzenia skryptów dla niego, tak jakby był stabilnym, publicznym interfejsem API klienta. Synapse dokumentuje również operację resetowania połączenia po przekroczeniu limitu czasu, która może spowodować kolejną próbę połączenia w tle dla celu, który jest już w fazie oczekiwania. Należy to traktować jako działanie diagnostyczne lub naprawcze dopiero po naprawieniu lub zrozumieniu przyczyny awarii; wielokrotne czyszczenie okresów oczekiwania nie spowoduje odpowiedzi niesprawnego serwera zdalnego. Pomyślna odpowiedź HTTP z punktu końcowego resetu nie oznacza, że ​​próba połączenia w tle została już zakończona.

Odniesienie: Interfejs API administratora federacji Synapse . Status eksperymentalny interfejsu API i dostępne pola mogą ulec zmianie w zależności od wersji Synapse, dlatego przed użyciem operacji należy sprawdzić dokumentację uruchomionej wersji.

Zmierz Synapse i jego bazę danych przed skalowaniem

Włącz punkt końcowy metryk Prometheus firmy Synapse tylko w zaufanej sieci wewnętrznej lub za kontrolą dostępu. Oficjalny przewodnik monitorowania dokumentuje /_synapse/metricsi pokazuje, jak udostępnić go za pośrednictwem nasłuchiwacza metryk lub istniejącego nasłuchiwacza HTTP. Metryki mogą zawierać szczegóły operacyjne; nie publikuj tego punktu końcowego publicznie. Jeśli zbierasz już metryki, porównaj czas wolnego łączenia z procesorem, pamięcią, opóźnieniem żądania, czasem trwania transakcji w bazie danych oraz przychodzącą i wychodzącą aktywnością federacji.

Użyj wykresów, aby odróżnić ogólne przeciążenie od opóźnień specyficznych dla federacji. Jeśli zwykłe żądania klientów i transakcje w bazie danych ulegają spowolnieniu w tym samym czasie co łączenia, sprawdź obciążenie procesora i pamięci hosta, kondycję bazy danych PostgreSQL, limity połączeń, opóźnienia na dysku i długotrwałe zapytania. Jeśli aktywność lokalnego pokoju pozostaje responsywna, ale jeden zdalny adres docelowy ma awarie lub opóźnienia w ponawianiu prób, priorytetowo potraktuj dostępność federacji i ten zdalny serwer. Jeśli problem dotyczy tylko jednego dużego pokoju, wpływ mogą mieć stan pokoju i liczba serwerów uczestniczących; porównaj to z mniejszym pokojem przed wyciągnięciem wniosków.

Przewodnik Synapse po Grafanie zaleca sprawdzenie czasu wysyłania wiadomości, procesora i pamięci, liczby i czasu trwania transakcji w bazie danych oraz grafów federacyjnych. Wysoka liczba transakcji nie jest automatycznie wąskim gardłem; czas trwania i obciążenie systemu również mają znaczenie. Sprawdź nazwy metryk zainstalowanej wersji Synapse oraz aktualną dokumentację pulpitu nawigacyjnego, ponieważ nazwy metryk z czasem ulegały zmianie.

Referencje: Synapse Prometheus monitorowanie i zrozumienie Synapse poprzez grafy Grafana .

Sprawdź ograniczenie przepustowości i przepustowość połączeń pokojowych

Synapse ma oddzielne rc_joinslimity dla połączeń lokalnych i zdalnych. Zdalne dołączenie może wymagać więcej pracy niż dołączenie do pokoju, w którym serwer już uczestniczy. Synapse ma również funkcję rc_joins_per_room, która ogranicza ostatnie dołączenia do pokoju, aby pomóc złagodzić fale masowych dołączeń. Jeśli logi lub odpowiedzi klienta wskazują na ograniczenie przepustowości, sprawdź te ustawienia i liczbę ostatnich dołączeń przed ich zmianą.

Nie podnoś limitów przepustowości jako ogólnego „rozwiązania problemu”. Wyższe limity mogą zwiększyć obciążenie serwera i innych serwerów domowych, a także osłabić ochronę przed falami dołączeń. Jeśli prawidłowa migracja lub seria połączeń osiąga skonfigurowany limit, określ go dokładnie i sprawdź aktualne wartości udokumentowane dla swojej wersji Synapse. Rozważ rozłożenie obciążenia dołączania w czasie. Zmieniaj jedną istotną wartość na raz, zachowaj poprzednią konfigurację i monitoruj wskaźniki błędów oraz wykorzystanie zasobów po ponownym załadowaniu lub uruchomieniu, zgodnie z wymaganiami wdrożenia.

Odniesienie: Konfiguracja Synapse:rc_joins i Konfiguracja Synapse:rc_joins_per_room . Domyślne i obsługiwane opcje mogą się różnić w zależności od wersji; przed edycją należy je porównać z zainstalowaną wersją.

Użyj kontrolowanego testu łączenia

1. Wybierz jeden pokój, którego dotyczy problem, i zapisz jego alias lub identyfikator, serwer domowy użytkownika dołączającego, czas oraz dokładny błąd klienta. Nigdy nie umieszczaj tokenów dostępu w dzienniku pomocy technicznej.
2. Sprawdź w narzędziu Federation Tester nazwę swojego serwera i potwierdź skonfigurowany punkt końcowy federacji, certyfikat i trasę proxy.
3. Przejrzyj logi Synapse wokół tego znacznika czasu pod kątem awarii federacji, błędów zdalnych miejsc docelowych, przekroczeń limitu czasu lub odpowiedzi dotyczących limitów przepustowości. Przeszukaj logi odwrotnego serwera proxy i bazy danych pod kątem pasujących opóźnień.
4. Sprawdź w interfejsie API administratora federacji stan ponownych prób powiązanych z odpowiednimi zdalnymi miejscami docelowymi. Porównaj pokoje, których dotyczy problem, z pokojem kontrolnym, który łączy się bezzwłocznie.
5. Porównaj metryki Prometheusa i hosta w tym samym okresie. Zwróć uwagę na zwiększone opóźnienie żądań, czas trwania transakcji w bazie danych, obciążenie procesora, pamięci lub gwałtowny wzrost aktywności federacji.
6. Wprowadź jedną ukierunkowaną korektę — taką jak naprawienie problemu z DNS/TLS/proxy, usunięcie wąskiego gardła w bazie danych lub dostosowanie potwierdzonego ograniczenia limitu przepustowości — a następnie powtórz ten sam test i porównaj wyniki.

Typowe założenia, których należy unikać

• „Powolne łączenie oznacza, że ​​port 8448 mojego serwera jest zamknięty”. Niekoniecznie. Delegacja lub odwrotny serwer proxy mogą używać portu 443. Sprawdź skonfigurowany punkt końcowy federacji i przetestuj go.
• „Udany test federacji dowodzi, że każde dołączenie do pokoju będzie szybkie”. Sprawdzana jest jedynie wspólna konfiguracja federacji i łączność. Stan serwera zdalnego, stan pokoju, obciążenie lokalne i wydajność bazy danych nadal mogą wpływać na dołączenie. Przetestuj pokój, którego dotyczy problem, i sprawdź logi.
• „Opóźnienie federacji zawsze ma swoje źródło w mojej instancji Synapse”. Własna dokumentacja konfiguracyjna Synapse ostrzega, że ​​zaobserwowane opóźnienie federacji może mieć swoje źródło w dowolnym punkcie końcowym lub w sieci między nimi. Porównaj miejsca docelowe i zbierz dowody z obu punktów końcowych, jeśli to możliwe.
• „Dodanie pracowników lub zwiększenie limitów przepustowości to pierwszy krok”. Te zmiany są przydatne tylko wtedy, gdy pomiary wskazują na przepustowość lub ograniczenie przepustowości. Najpierw należy ustalić, czy problem dotyczy łączności, zdalnego ponawiania prób, lokalnego nasycenia, opóźnień w bazie danych, czy też ograniczenia przepustowości łączenia.

Sprawdź, czy poprawka zadziałała

Powtórz ten sam test łączenia po zmianie. Upewnij się, że użytkownik łączy się pomyślnie, że dotknięty problem nie powoduje już powtarzających się błędów w docelowym miejscu docelowym, że narzędzie Federation Tester poprawnie raportuje odpowiednie sprawdzenia, a opóźnienie żądania/bazy danych wraca do normy. Zwróć uwagę na powtarzanie się tych zdarzeń w późniejszym okresie wzmożonego ruchu; jedna udana próba nie dowodzi, że zdalny serwer lub sieć są stale sprawne.

Jeśli lokalne metryki i kontrole federacji wyglądają prawidłowo, ale tylko jeden zdalny serwer domowy nadal zgłasza błąd, udostępnij administratorom tego serwera znacznik czasu, miejsce docelowe, zdezynfekowany błąd i odpowiednie identyfikatory żądań. Jeśli problem dotyczy kilku pokoi i miejsc docelowych, a także powolnych żądań lokalnych, sprawdź wydajność Synapse i PostgreSQL przed dostrojeniem działania federacji. Zapisz swoją wersję Synapse wraz z notatkami o incydencie, ponieważ konfiguracja i szczegóły interfejsu API administratora ulegają zmianom.