Napraw błąd Matrix Synapse „Zbyt wiele otwartych plików” w systemied

Matrix Synapse może uruchomić się normalnie, a następnie przestać akceptować połączenia, zgłosić błąd „Zbyt wiele otwartych plików” lub zawiesić się pod obciążeniem. W przypadku instalacji systemd, pierwszą rzeczą, którą należy sprawdzić, jest limit deskryptorów plików dziedziczony przez działający proces Synapse. Zmiana ulimitpliku limitów powłoki lub edycja pliku PAM zazwyczaj nie zmienia limitu dla usługi uruchamianej przez systemd.

Poniższe kroki dotyczą hosta Linux, na którym Synapse działa jako usługa systemd. Jednostka może nosić nazwę matrix-synapse.service, matrix-synapse@.servicelub inną, charakterystyczną dla danego pakietu. Przed skopiowaniem poleceń należy potwierdzić prawdziwą jednostkę. Jeśli Synapse działa w Dockerze, Kubernetesie lub innym kontenerze, zapoznaj się z osobną sekcją poniżej.

Co oznacza „Zbyt wiele otwartych plików”?

Linux nakłada na każdy proces limit otwartych deskryptorów plików. Deskryptor może odnosić się do pliku, gniazda, potoku lub innego zasobu; połączenia sieciowe również zużywają deskryptory. Gdy proces osiągnie swój limit, próba otwarcia lub zaakceptowania innego deskryptora może się nie powieść z błędem EMFILE. Linux ma również oddzielny systemowy limit tablicy plików: jego wyczerpanie może spowodować ENFILE. Podniesienie limitu jednej usługi Synapse nie rozwiąże problemu braku zasobów w całym systemie.

Oficjalne FAQ administracyjne Synapse podaje, że wysoka aktywność połączeń i federacji może wykorzystywać wiele uchwytów plików, a wyczerpanie zasobów może spowodować, że serwer przestanie akceptować nowe połączenia TCP. W wytycznych wspomniano o zwiększeniu limitu do co najmniej 4096 w kontekście starszych wartości domyślnych, takich jak 1024 lub 256. Należy to traktować jako próg rozwiązywania problemów w opisanej sytuacji, a nie jako uniwersalne zalecenie dotyczące pojemności dla każdego serwera domowego. Zacznij od sprawdzenia efektywnego limitu i rzeczywistego wykorzystania.

Dokumentacja getrlimit i prlimit systemu Linux opisuje miękkie i twarde limity dla każdego procesu. Synapse również ma takie soft_file_limitustawienie; dokumentacja konfiguracji Synapse dokumentuje wartość domyślną równą zero, która nakazuje Synapse ustawienie miękkiego limitu na wartość twardego limitu, z którego może korzystać.

1. Potwierdź działanie jednostki i zdiagnozuj usterkę

Najpierw znajdź rzeczywistą nazwę usługi. W wielu instalacjach pakietów jest to matrix-synapse.service, ale nie zakładaj tej nazwy, jeśli Twoja instalacja korzysta z niestandardowej jednostki lub pracowników.

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

Sprawdź dokładny błąd, czas jego wystąpienia oraz czy wystąpił podczas skoku ruchu, aktywności federacji czy restartu. Następnie sprawdź limit, jaki systemd aktualnie zgłasza:

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

LimitNOFILEPokazuje skonfigurowany limit menedżera usług; nie jest to liczba aktualnie otwartych deskryptorów. Polecenie powłoki, takie jak [ ulimit -nbrakuje informacji o limicie], raportuje jedynie bieżący limit powłoki i nie stanowi dowodu na istnienie limitu usługi.

2. Podnieś limit usługi systemd za pomocą drop-in

Użyj drop-inu systemd, aby aktualizacje pakietów nie wymagały edycji pliku jednostki dostawcy. Poniższa wartość jest przykładowa i nie gwarantuje idealnego działania dla każdego serwera. Wybierz limit z marginesem przekraczającym obserwowane szczytowe obciążenie i sprawdź zgodność aplikacji i zależności przed ustawieniem nietypowo wysokiej wartości.

sudo systemctl edit matrix-synapse.service

Dodaj to w nowym oknie edytora:

[Service]
LimitNOFILE=65536

Zapisz i wyjdź, a następnie przeładuj systemd i uruchom ponownie Synapse w odpowiednim oknie konserwacyjnym:

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

Pojedyncza LimitNOFILEwartość określa zarówno miękki, jak i twardy limit dla usługi w systemie systemd. Podręcznik systemd również dopuszcza soft:hardparę. Miękki limit nie może przekraczać twardego limitu. Przed wybraniem bardzo wysokiej wartości należy zapoznać się z dokumentacją systemd.exec , która wskazuje na problemy ze zgodnością programów korzystających ze starego select(2)interfejsu z deskryptorami powyżej 1023. Nie należy zakładać, że każda biblioteka lub wtyczka w systemie obsługuje dowolny limit.

3. Sprawdź własne ustawienia i usługi robocze Synapse

Jeśli konfiguracja Synapse wyraźnie ustawia soft_file_limitniską wartość, ustawienia aplikacji mogą utrzymywać limit miękki poniżej limitu systemd. Przeszukaj aktywne pliki konfiguracyjne i dołączoną konfigurację pod kątem tego klucza. Usuń niepotrzebne nadpisanie lub ustaw je celowo; udokumentowana wartość domyślna zero powoduje, że Synapse podnosi limit miękki do dostępnego limitu twardego.

W przypadku wdrożenia wieloprocesowego każdy pracownik jest osobnym procesem i może zostać uruchomiony przez osobną jednostkę lub instancję szablonu. Podniesienie limitu usługi głównej nie oznacza automatycznie, że każdy pracownik ma zamierzony limit. Sprawdź rzeczywiste nazwy jednostek roboczych za pomocą systemctl list-units, a następnie zastosuj i zweryfikuj odpowiedni drop-in dla każdej usługi, która go potrzebuje.

Podobnie, ustawienia w /etc/security/limits.confpowłoce logowania i w powłoce logowania ulimitzazwyczaj nie regulują usługi systemowej uruchamianej bezpośrednio przez systemd. W tym celu należy zmienić limit zasobów jednostki i zweryfikować go w procesie, który systemd faktycznie uruchomił.

4. Jeśli Synapse działa w kontenerze

Nadpisanie systemd na poziomie hosta dla innej usługi nie zmienia automatycznie limitu deskryptorów plików kontenera. Skonfiguruj środowisko wykonawcze kontenera lub warstwę orkiestracji. W przypadku Docker Compose definicja usługi obsługuje obsługę poszczególnych kontenerów ulimits; przykład:

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

Liczba ta ma charakter poglądowy; należy ją dostosować do rozmiaru na podstawie wykorzystania i limitów hosta. Dokumentacja usługi Docker Compose dokumentuje to ulimitsustawienie. Od wersji Docker Engine 29, informacje o wydaniu Dockera opisują zmianę domyślnego limitu nofile związanego z containerd 2.1.5: kontenery mogą otrzymać 1024 zamiast poprzedniego domyślnego limitu 1 048 576. Jeśli problem pojawił się po aktualizacji silnika, należy sprawdzić obowiązujący limit kontenerów i jawnie ustawić wymagany limit ulimit w konfiguracji wdrożenia. Zobacz informacje o wydaniu Docker Engine 29 i dokumentacja uruchomienia Dockera .

5. Sprawdź limit uruchomionego procesu Synapse

Po ponownym uruchomieniu sprawdź limity na poziomie procesu, a nie tylko konfigurację systemd. Uzyskaj główny PID i sprawdź jego limity zgłaszane przez jądro:

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

Jeśli główny PID wynosi zero lub należy do wrappera, a nie Synapse, zidentyfikuj proces Synapse w grupie cgroup usługi i sprawdź ten PID. Liczba deskryptorów to migawka; powtórz ją podczas ładowania reprezentatywnego. Upewnij się, że „Maksymalna liczba otwartych plików” odzwierciedla zamierzone limity miękkie i twarde, liczba ta utrzymuje się znacznie poniżej limitu miękkiego, a dziennik nie zgłasza już błędu.

Jeśli liczba będzie rosła, aż osiągnie nowy limit, limit może jedynie opóźniać awarię. W FAQ Synapse zaznaczono, że zablokowane lub powolne żądania mogą mieć znaczenie podczas badania wyczerpania uchwytów plików. Przejrzyj logi i przetwarzanie żądań, porównaj liczbę deskryptorów w czasie i zbadaj ewentualny wyciek lub nieoczekiwanie trwałe połączenia, zamiast bezmyślnie zwiększać limit.

Kiedy podniesienie limitu na usługę nie wystarczy

Jeśli logi zgłaszają błąd wyczerpania tabeli plików w całym systemie, taki jak ENFILE, sprawdź użycie w całym hoście i innych usługach; LimitNOFILEzmiana w obrębie pojedynczej usługi nie zwiększy wydajności jądra w całym systemie. Unikaj zmiany globalnych limitów jądra bez potwierdzenia błędu i zrozumienia wpływu na cały host. Jeśli zgłoszony limit usługi pozostaje niski po dodaniu, uruchom program, systemctl cat matrix-synapse.serviceaby upewnić się, że dodanie jest załadowane, zweryfikuj nazwę jednostki, przeładuj systemd i ponownie uruchom właściwą jednostkę.

Szybka samokontrola

• Czy zidentyfikowałeś dokładną jednostkę lub kontener Synapse, który rejestruje błąd?
• Czy systemctl showpodaje przewidywany limit dla danej jednostki?
• Czy /proc/<Synapse-PID>/limitspo ponownym uruchomieniu wyświetla zamierzone limity miękkie i twarde?
• Czy liczba deskryptorów jest poniżej limitu miękkiego przy normalnym obciążeniu szczytowym?
• Czy jednostki robocze i ustawienia kontenerów są sprawdzane osobno, jeśli ma to zastosowanie?
• Czy błąd ustał, czy też wykorzystanie nadal rośnie, zmierzając w kierunku nowego limitu?

Jeśli wszystkie kontrole na poziomie procesu zakończą się powodzeniem, a błąd ustanie podczas reprezentatywnego ruchu, zmiana limitu systemd działa. Jeśli deskryptory nadal się kumulują lub system zgłasza globalny niedobór, należy kontynuować badanie źródła, zamiast traktować większy limit jako kompletne rozwiązanie.

Źródła

• Często zadawane pytania dotyczące administracji Synapse: wyczerpanie uchwytów plików
• Odniesienie do konfiguracji Synapse: soft_file_limit
• podręcznik systemd.exec: limity zasobów usługi
• Podręcznik Linuksa: getrlimit i prlimit
• Notatki o wydaniu Docker Engine 29