Behebung des Matrix Synapse-Fehlers „Zu viele offene Dateien“ unter systemd

Matrix Synapse kann normal starten und dann keine Verbindungen mehr annehmen, die Meldung „Zu viele offene Dateien“ ausgeben oder unter Last scheinbar hängen bleiben. Bei einer systemd-Installation sollte zunächst das vom laufenden Synapse-Prozess geerbte Dateideskriptorlimit überprüft werden. Änderungen an der Shell ulimitoder der PAM-Datei haben in der Regel keinen Einfluss auf das Limit eines von systemd gestarteten Dienstes.

Die folgenden Schritte gelten für einen Linux-Host, auf dem Synapse als systemd-Dienst ausgeführt wird. Die Unit kann beispielsweise `synapse.com`, `synapse.com` oder einen paketspezifischen Namen tragen matrix-synapse.service. matrix-synapse@.serviceÜberprüfen Sie die tatsächliche Unit, bevor Sie die Befehle kopieren. Falls Synapse in Docker, Kubernetes oder einem anderen Container ausgeführt wird, lesen Sie bitte den separaten Abschnitt weiter unten.

Was bedeutet „Zu viele geöffnete Dateien“?

Linux begrenzt die Anzahl offener Dateideskriptoren pro Prozess. Ein Deskriptor kann auf eine Datei, einen Socket, eine Pipe oder eine andere Ressource verweisen; Netzwerkverbindungen verbrauchen daher ebenfalls Deskriptoren. Erreicht ein Prozess sein Limit, kann der Versuch, einen weiteren Deskriptor zu öffnen oder zu akzeptieren, fehlschlagen EMFILE. Linux verfügt außerdem über ein separates systemweites Limit für die Dateitabelle: Eine Erschöpfung dieses Limits kann ebenfalls zu einem Fehler führen ENFILE. Die Erhöhung des Limits eines einzelnen Synapse-Dienstes behebt einen systemweiten Mangel nicht.

Die offiziellen Administrations-FAQs von Synapse weisen darauf hin, dass hohe Verbindungs- und Föderationsaktivität viele Dateihandles belegen kann und dass eine Erschöpfung dazu führen kann, dass der Server keine neuen TCP-Verbindungen mehr annimmt. In den Richtlinien wird empfohlen, das Limit auf mindestens 4.096 zu erhöhen, da ältere Standardwerte wie 1.024 oder 256 üblich sind. Dieser Wert dient als Mindestanforderung zur Fehlerbehebung in der beschriebenen Situation und ist keine allgemeingültige Kapazitätsempfehlung für jeden Heimserver. Überprüfen Sie zunächst das effektive Limit und die tatsächliche Nutzung.

Die Dokumentation zu den Linux-Befehlen `getrlimit` und `prlimit` beschreibt die prozessspezifischen Soft- und Hardlimits. Auch Synapse bietet eine soft_file_limitentsprechende Einstellung; die Synapse-Konfigurationsreferenz gibt als Standardwert Null an, dass Synapse das Softlimit auf das maximal verwendbare Hardlimit setzt.

1. Prüfen Sie das Gerät und diagnostizieren Sie den Fehler.

Ermitteln Sie zunächst den tatsächlichen Dienstnamen. Bei vielen Paketinstallationen lautet er matrix-synapse.service, aber gehen Sie nicht von diesem Namen aus, wenn Ihre Installation eine benutzerdefinierte Einheit oder Worker verwendet.

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

Suchen Sie nach der genauen Fehlerursache, dem Zeitpunkt ihres Auftretens und ob sie während einer Lastspitze, bei Aktivitäten des Verbundsystems oder nach einem Neustart auftritt. Überprüfen Sie anschließend den von systemd aktuell gemeldeten Grenzwert:

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

LimitNOFILEZeigt das vom Dienstmanager konfigurierte Limit an; es handelt sich nicht um die Anzahl der aktuell geöffneten Deskriptoren. Ein Shell-Befehl wie dieser ulimit -nmeldet lediglich das Limit der aktuellen Shell und ist kein Beweis für das Limit des Dienstes.

2. Erhöhen Sie das systemd-Dienstlimit mit einem Drop-in

Verwenden Sie ein systemd-Drop-in, damit Paketaktualisierungen keine Bearbeitung der Vendor-Unit-Datei erfordern. Der folgende Wert ist ein Beispiel und keine Garantie für optimale Leistung auf jedem Server. Wählen Sie einen Grenzwert, der über der beobachteten Spitzenlast liegt, und prüfen Sie die Kompatibilität von Anwendung und Abhängigkeiten, bevor Sie einen ungewöhnlich hohen Wert festlegen.

sudo systemctl edit matrix-synapse.service

Fügen Sie dies unter dem neuen Drop-in des Editors hinzu:

[Service]
LimitNOFILE=65536

Speichern und beenden, anschließend systemd neu laden und Synapse während eines geeigneten Wartungsfensters neu starten:

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

Ein einzelner LimitNOFILEWert legt sowohl die weiche als auch die harte Grenze für den Dienst in systemd fest. Das systemd-Handbuch erlaubt auch ein soft:hardPaar. Die weiche Grenze darf die harte Grenze nicht überschreiten. Bevor Sie einen sehr hohen Wert wählen, lesen Sie die Dokumentation zu systemd.exec , die auf Kompatibilitätsprobleme für Programme hinweist, die die alte select(2)Schnittstelle mit Deskriptoren über 1023 verwenden. Gehen Sie nicht davon aus, dass jede Bibliothek oder jedes Plugin in Ihrer Umgebung jede beliebige Grenze unterstützt.

3. Überprüfen Sie die Synapse-eigenen Einstellungen und Worker-Dienste.

Wenn Ihre Synapse-Konfiguration explizit soft_file_limiteinen niedrigen Wert festlegt, kann die Anwendungseinstellung den Soft Limit unter dem systemd-Limit halten. Suchen Sie in den aktiven Konfigurationsdateien und der zugehörigen Konfiguration nach diesem Schlüssel. Entfernen Sie entweder eine unnötige Überschreibung oder setzen Sie den Wert bewusst; der dokumentierte Standardwert Null weist Synapse an, den Soft Limit auf das verfügbare Hard Limit anzuheben.

Bei einer Bereitstellung mit mehreren Prozessen ist jeder Worker ein separater Prozess und kann von einer separaten Unit oder Template-Instanz gestartet werden. Die Erhöhung des Limits des Hauptdienstes beweist nicht automatisch, dass jeder Worker das vorgesehene Limit hat. Überprüfen Sie die tatsächlichen Worker-Unit-Namen systemctl list-unitsund wenden Sie anschließend das entsprechende Drop-in für jeden Dienst an, der es benötigt.

Ebenso wenig regeln Einstellungen in /etc/security/limits.confder Login-Shell ulimitim Allgemeinen einen Systemdienst, der direkt von systemd gestartet wird. Ändern Sie in diesem Fall das Ressourcenlimit der Unit und überprüfen Sie es für den Prozess, der tatsächlich von systemd gestartet wurde.

4. Wenn Synapse in einem Container ausgeführt wird

Eine systemd-Überschreibung auf Hostebene für einen anderen Dienst ändert nicht automatisch das Dateideskriptorlimit eines Containers. Konfigurieren Sie die Container-Laufzeitumgebung oder die Orchestrierungsschicht. Bei Docker Compose unterstützt die Dienstdefinition die Konfiguration pro Container ulimits; ein Beispiel:

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

Die Zahl dient nur zur Veranschaulichung; die Größe sollte anhand der Nutzung und der Limits des Hosts angepasst werden. Die Compose-Servicereferenz von Docker beschreibt die ulimitsEinstellung. Ab Docker Engine 29 beschreiben die Versionshinweise von Docker eine Änderung des Standard-nofile-Limits in Verbindung mit containerd 2.1.5: Container erhalten nun 1.024 statt der bisherigen 1.048.576. Falls das Problem nach einem Engine-Upgrade auftritt, überprüfen Sie das effektive Containerlimit und legen Sie das benötigte ulimit explizit in der Bereitstellungskonfiguration fest. Weitere Informationen finden Sie in den Versionshinweisen zu Docker Engine 29 und in der Docker-Run-Referenz .

5. Überprüfen Sie das Limit des laufenden Synapse-Prozesses.

Überprüfen Sie nach dem Neustart die Prozesslimits, nicht nur die Konfiguration von systemd. Ermitteln Sie die Haupt-PID und prüfen Sie die vom Kernel gemeldeten Limits:

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

Wenn die Haupt-PID null ist oder zu einem Wrapper anstatt zu Synapse gehört, identifizieren Sie den Synapse-Prozess in der Cgroup des Dienstes und überprüfen Sie stattdessen dessen PID. Die Deskriptoranzahl ist eine Momentaufnahme; wiederholen Sie die Messung unter repräsentativer Last. Stellen Sie sicher, dass „Maximale Anzahl offener Dateien“ Ihren beabsichtigten Soft- und Hardlimits entspricht, die Anzahl deutlich unter dem Softlimit bleibt und der Fehler im Journal nicht mehr gemeldet wird.

Steigt die Anzahl der Anfragen weiter an, bis der neue Grenzwert erreicht ist, verzögert das Limit möglicherweise nur den Fehler. In den Synapse-FAQs wird darauf hingewiesen, dass hängende oder langsame Anfragen bei der Untersuchung von Dateihandle-Erschöpfung relevant sein können. Überprüfen Sie die zugehörigen Protokolle und die Anfrageverarbeitung, vergleichen Sie die Anzahl der Deskriptoren im Zeitverlauf und untersuchen Sie mögliche Speicherlecks oder unerwartet persistente Verbindungen, anstatt das Limit blindlings weiter zu erhöhen.

Wenn eine Erhöhung des Limits pro Dienstleistung nicht ausreicht

Wenn Protokolle einen systemweiten Dateitabellen-Erschöpfungsfehler melden ENFILE, überprüfen Sie die Nutzung auf dem gesamten Host und bei anderen Diensten. Eine Änderung pro Dienst LimitNOFILEerhöht die systemweite Kernelkapazität nicht. Vermeiden Sie Änderungen an globalen Kernelgrenzen, ohne den Fehler zu bestätigen und die Auswirkungen auf den gesamten Host zu verstehen. Wenn die gemeldete Grenze des Dienstes nach dem Laden einer neuen Einheit weiterhin niedrig ist, führen Sie `systemd install` aus, systemctl cat matrix-synapse.serviceum zu bestätigen, dass die neue Einheit geladen wurde, überprüfen Sie den Namen der Einheit, laden Sie systemd neu und starten Sie die richtige Einheit neu.

Schneller Selbsttest

• Konnten Sie die genaue Synapse-Einheit oder den Container identifizieren, der den Fehler protokolliert?
• Wird systemctl showder vorgesehene Grenzwert für diese Einheit gemeldet?
• Werden /proc/<Synapse-PID>/limitsnach dem Neustart die vorgesehenen Soft- und Hard-Limits angezeigt?
• Liegt die Anzahl der Deskriptoren unter dem weichen Grenzwert bei normaler Spitzenlast?
• Werden die Einstellungen für Arbeitseinheiten und Container gegebenenfalls separat geprüft?
• Ist der Fehler behoben oder steigt die Nutzung weiter in Richtung des neuen Höchstwertes?

Wenn alle Prozessprüfungen erfolgreich sind und der Fehler im repräsentativen Datenverkehr nicht mehr auftritt, funktioniert die Änderung des systemd-Limits. Falls sich weiterhin Deskriptoren ansammeln oder das System einen globalen Mangel meldet, sollten Sie die Ursache weiter untersuchen, anstatt ein höheres Limit als endgültige Lösung zu betrachten.

Quellen

• Synapse-Administrations-FAQ: Erschöpfung der Dateihandles
• Synapse-Konfigurationsreferenz: soft_file_limit
• systemd.exec-Handbuch: Dienstressourcenbeschränkungen
• Linux-Handbuch: getrlimit und prlimit
• Docker Engine 29 – Versionshinweise