Matrix Synapse lost het probleem "Te veel geopende bestanden" op in systemd.

Matrix Synapse kan normaal opstarten en vervolgens stoppen met het accepteren van verbindingen, de foutmelding "Te veel open bestanden" weergeven of vastlopen onder belasting. Bij een systemd-installatie is het eerste wat u moet controleren de limiet voor bestandsdescriptors die het draaiende Synapse-proces overneemt. Het wijzigen van de shell-limieten ulimitof het bewerken van een PAM-limietbestand verandert meestal niet de limiet voor een service die door systemd wordt gestart.

De onderstaande stappen zijn van toepassing op een Linux-host waar Synapse als een systemd-service draait. De unit kan de naam matrix-synapse.service, matrix-synapse@.service, of een pakketspecifieke naam hebben. Controleer de daadwerkelijke unit voordat u de commando's kopieert. Als Synapse in Docker, Kubernetes of een andere container draait, raadpleeg dan het aparte gedeelte hieronder.

Wat betekent "Te veel geopende bestanden"?

Linux kent aan elk proces een limiet toe voor het aantal geopende bestandsdescriptors. Een descriptor kan verwijzen naar een bestand, socket, pipe of andere bron; netwerkverbindingen verbruiken daarom ook descriptors. Wanneer een proces zijn soft-limiet bereikt, kan een poging om een ​​andere descriptor te openen of te accepteren mislukken met een foutmelding EMFILE. Linux heeft ook een aparte, systeemwijde limiet voor de bestandstabel: uitputting daarvan kan een foutmelding veroorzaken ENFILE. Het verhogen van de limiet van één Synapse-service lost een systeemwijd tekort niet op.

In de officiële FAQ van Synapse staat dat veel verbindings- en federatieactiviteit veel bestandsdescriptors kan verbruiken en dat uitputting ertoe kan leiden dat de server geen nieuwe TCP-verbindingen meer accepteert. De richtlijnen adviseren om de limiet te verhogen naar minimaal 4096 in plaats van de standaardwaarden van 1024 of 256. Beschouw dit als een minimale waarde voor het oplossen van problemen in de beschreven situatie, en niet als een algemene capaciteitsaanbeveling voor elke thuisserver. Begin met het controleren van de effectieve limiet en het daadwerkelijke gebruik.

De documentatie van Linux over getrlimit en prlimit beschrijft de zachte en harde limieten per proces. Synapse heeft ook een soft_file_limitinstelling; de Synapse-configuratiehandleiding beschrijft een standaardwaarde van nul, wat Synapse vertelt om de zachte limiet in te stellen op de harde limiet die het kan gebruiken.

1. Controleer het apparaat en stel de oorzaak van de storing vast.

Zoek eerst de daadwerkelijke servicenaam op. Bij veel pakketinstallaties is dit matrix-synapse.service, maar ga er niet van uit dat dit de juiste naam is als uw installatie gebruikmaakt van een aangepaste unit of workers.

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

Zoek naar de exacte foutmelding, het tijdstip waarop deze begon en of deze optreedt tijdens een verkeerspiek, federatieactiviteit of een herstart. Controleer vervolgens de limiet die systemd momenteel rapporteert:

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

LimitNOFILEDit geeft de geconfigureerde limiet van de servicemanager weer; het is geen telling van de momenteel geopende descriptors. Een shell-opdracht zoals ulimit -nrapporteert alleen de huidige limiet van de shell en is geen bewijs van de limiet van de service.

2. Verhoog de limiet voor de systemd-service met een drop-in.

Gebruik een systemd drop-in zodat pakketupdates geen bewerking van het vendor unit-bestand vereisen. De volgende waarde is een voorbeeld en geen gegarandeerde ideale waarde voor elke server. Kies een limiet die ruim boven het waargenomen piekgebruik ligt en controleer de compatibiliteit van applicaties en afhankelijkheden voordat u een ongebruikelijk hoge waarde instelt.

sudo systemctl edit matrix-synapse.service

Voeg dit toe onder het nieuwe invoegveld van de editor:

[Service]
LimitNOFILE=65536

Sla het bestand op en sluit af, herlaad vervolgens systemd en herstart Synapse tijdens een geschikt onderhoudsvenster:

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

Eén enkele LimitNOFILEwaarde stelt zowel de zachte als de harde limiet in voor de service in systemd. De systemd-handleiding staat ook een soft:hardpaar waarden toe. De zachte limiet mag de harde limiet niet overschrijden. Voordat u een zeer hoge waarde kiest, raadpleeg dan de systemd.exec-documentatie , waarin melding wordt gemaakt van compatibiliteitsproblemen voor programma's die de oude select(2)interface gebruiken met descriptors boven de 1023. Ga er niet vanuit dat elke bibliotheek of plug-in in uw implementatie elke willekeurige limiet ondersteunt.

3. Controleer de eigen instellingen en werknemersservices van Synapse.

Als uw Synapse-configuratie expliciet soft_file_limiteen laag getal instelt, kan de toepassingsinstelling de soft limit onder de door systemd ingestelde limiet houden. Zoek in de actieve configuratiebestanden en de meegeleverde configuratie naar die sleutel. Verwijder een onnodige overschrijving of stel deze bewust in; de gedocumenteerde standaardwaarde van nul zorgt ervoor dat Synapse de soft limit verhoogt naar de beschikbare hard limit.

Bij een implementatie met meerdere processen is elke worker een afzonderlijk proces en kan deze worden gestart door een aparte unit of template-instantie. Het verhogen van de limiet van de hoofdservice garandeert niet automatisch dat elke worker de beoogde limiet heeft. Controleer de daadwerkelijke namen van de worker-units met systemctl list-units, pas vervolgens de juiste drop-in toe en controleer of deze geldig is voor elke service die deze nodig heeft.

Evenzo bepalen instellingen in /etc/security/limits.confeen loginshell ulimitover het algemeen niet de werking van een systeemservice die direct door systemd wordt gestart. Wijzig in deze configuratie de resourcelimiet van de unit en controleer dit op het proces dat systemd daadwerkelijk heeft gestart.

4. Als Synapse in een container draait

Een systemd-override op hostniveau voor een andere service wijzigt niet automatisch de limiet voor bestandsdescriptors van een container. Configureer de runtime- of orchestratielaag van de container. Voor Docker Compose ondersteunt de servicedefinitie per container ulimits; een voorbeeld hiervan is:

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

Het getal is slechts een indicatie; pas de grootte aan op basis van het gebruik en de limieten van de host. De documentatie van de Docker Compose-service beschrijft deze ulimitsinstelling. Vanaf Docker Engine 29 beschrijven de release-opmerkingen van Docker een wijziging in de standaard nofile-limiet die is gekoppeld aan containerd 2.1.5: containers kunnen 1.024 in plaats van de vorige standaard van 1.048.576 ontvangen. Als het probleem zich voordoet na een upgrade van de Engine, controleer dan de effectieve containerlimiet en stel de benodigde ulimit expliciet in in de implementatieconfiguratie. Zie de release-opmerkingen van Docker Engine 29 en de documentatie van docker run .

5. Controleer de limiet van het actieve Synapse-proces.

Controleer na de herstart de limieten op procesniveau, niet alleen de configuratie van systemd. Achterhaal de hoofd-PID en inspecteer de door de kernel gerapporteerde limieten:

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

Als de hoofd-PID nul is of bij een wrapper hoort in plaats van bij Synapse, identificeer dan het Synapse-proces in de cgroup van de service en inspecteer die PID. Het aantal descriptors is een momentopname; herhaal dit tijdens een representatieve belasting. Controleer of "Max open files" de gewenste soft- en hard-limieten weergeeft, of het aantal ruim onder de soft-limiet blijft en of het logboek de fout niet langer meldt.

Als het aantal blijft stijgen tot het nieuwe plafond is bereikt, kan de limiet het falen slechts uitstellen. De Synapse FAQ vermeldt dat vastgelopen of trage verzoeken relevant kunnen zijn bij het onderzoeken van uitputting van bestandsdescriptors. Bekijk de omliggende logboeken en de verwerking van verzoeken, vergelijk het aantal descriptors in de loop van de tijd en onderzoek een mogelijk lek of onverwacht persistente verbindingen in plaats van de limiet blindelings te blijven verhogen.

Wanneer het verhogen van de limiet per dienst niet voldoende is

Als de logbestanden een systeemwijde foutmelding over uitputting van de bestandstabel melden, zoals ENFILE, controleer dan het gebruik op de hele host en andere services; een LimitNOFILEwijziging per service zal de systeemwijde capaciteit van de kernel niet verhogen. Vermijd het wijzigen van globale kernellimieten zonder de fout te bevestigen en de impact op de hele host te begrijpen. Als de gerapporteerde limiet van de service laag blijft na een drop-in, voer dan uit systemctl cat matrix-synapse.serviceom te bevestigen dat de drop-in is geladen, controleer de unitnaam, herlaad systemd en herstart de juiste unit.

Snelle zelfcontrole

• Heeft u de exacte Synapse-eenheid of -container geïdentificeerd die de fout registreert?
• Geeft systemctl showhet rapport de beoogde limiet voor die eenheid weer?
• Worden /proc/<Synapse-PID>/limitsde beoogde soft- en hard-limieten na een herstart weergegeven?
• Ligt het aantal beschrijvingen onder de zachte limiet bij normale piekbelasting?
• Worden de werkeenheden en containerinstellingen waar van toepassing afzonderlijk gecontroleerd?
• Is de fout verholpen, of blijft het gebruik toenemen richting het nieuwe plafond?

Als alle procescontroles slagen en de fout tijdens representatief verkeer is verdwenen, werkt de limietwijziging van systemd. Als descriptors zich blijven ophopen of het systeem een ​​algemeen tekort meldt, blijf dan de oorzaak onderzoeken in plaats van een hogere limiet als de volledige oplossing te beschouwen.

Bronnen

• Veelgestelde vragen over Synapse-beheer: uitputting van bestandshandles
• Synapse-configuratiereferentie: soft_file_limit
• handleiding voor systemd.exec: service resource limits
• Linux-handleiding: getrlimit en prlimit
• Release-opmerkingen voor Docker Engine 29