Remediază eroarea „Prea multe fișiere deschise” a sinapsei Matrix pe systemd

Matrix Synapse poate porni normal și apoi poate înceta să mai accepte conexiuni, poate înregistra mesajul „Prea multe fișiere deschise” sau poate apărea blocat sub sarcină. Într-o instalare systemd, primul lucru de verificat este limita descriptorului de fișiere moștenită de procesul Synapse care rulează. Modificarea unui fișier cu limite al shell-ului ulimitsau editarea unui fișier cu limite PAM nu modifică de obicei limita pentru un serviciu pe care îl pornește systemd.

Pașii de mai jos se aplică unei gazde Linux unde Synapse rulează ca serviciu systemd. Unitatea poate fi denumită matrix-synapse.service, matrix-synapse@.service, sau ceva specific pachetului. Confirmați unitatea reală înainte de a copia comenzile. Dacă Synapse rulează în Docker, Kubernetes sau alt container, consultați secțiunea separată de mai jos.

Ce înseamnă „Prea multe fișiere deschise”?

Linux impune fiecărui proces o limită privind descriptorii de fișiere deschise. Un descriptor se poate referi la un fișier, socket, pipe sau altă resursă; prin urmare, conexiunile de rețea consumă și descriptori. Când un proces atinge limita sa soft, o încercare de a deschide sau accepta un alt descriptor poate eșua cu EMFILE. Linux are, de asemenea, o limită separată pentru tabelul de fișiere la nivel de sistem: epuizarea acesteia poate produce ENFILE. Creșterea limitei unui serviciu Synapse nu va rezolva o lipsă la nivel de sistem.

Întrebările frecvente oficiale privind administrarea Synapse menționează că o activitate intensă de conectare și federare poate utiliza mai multe handle-uri de fișiere și că epuizarea poate face ca serverul să nu mai accepte noi conexiuni TCP. Ghidul menționează creșterea limitei la cel puțin 4.096 în contextul setărilor implicite mai vechi, cum ar fi 1.024 sau 256. Tratați acest lucru ca un prag de depanare pentru situația descrisă, nu ca o recomandare universală de capacitate pentru fiecare server de acasă. Începeți prin a verifica limita efectivă și utilizarea reală.

Documentația getrlimit și prlimit din Linux descrie limitele soft și hard per proces. Synapse are și o soft_file_limitsetare; referința de configurare Synapse documentează o valoare implicită de zero, care îi spune lui Synapse să seteze limita soft la limita hard pe care o poate utiliza.

1. Confirmați unitatea și diagnosticați defecțiunea

Găsiți mai întâi numele propriu-zis al serviciului. În multe instalări de pachete, acesta este matrix-synapse.service, dar nu presupuneți acest nume dacă instalarea dvs. utilizează o unitate personalizată sau 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

Căutați eroarea exactă, ora la care a început și dacă apare în timpul unui vârf de trafic, al activității de federare sau al unei reporniri. Apoi, inspectați limita raportată în prezent de systemd:

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

LimitNOFILEarată limita configurată de managerul de servicii; nu este un număr de descriptori deschiși în prezent. O comandă shell, cum ar fi ulimit -nraportează doar limita shell-ului curent și nu este o dovadă a limitei serviciului.

2. Creșteți limita serviciilor systemd cu un drop-in

Folosește o funcție drop-in systemd, astfel încât actualizările pachetului să nu necesite editarea fișierului unit al furnizorului. Următoarea valoare este un exemplu, nu este garantată ca fiind ideală pentru fiecare server. Alege o limită cu spațiu peste utilizarea maximă observată și verifică compatibilitatea aplicației și a dependențelor înainte de a seta o valoare neobișnuit de mare.

sudo systemctl edit matrix-synapse.service

Adaugă asta sub noul meniu drop-in al editorului:

[Service]
LimitNOFILE=65536

Salvați și ieșiți, apoi reîncărcați systemd și reporniți Synapse într-o fereastră de mentenanță corespunzătoare:

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

O singură LimitNOFILEvaloare setează atât limita soft, cât și limita hard pentru serviciul din systemd. Manualul systemd permite, de asemenea, o soft:hardpereche. Limita soft nu poate depăși limita hard. Înainte de a alege o valoare foarte mare, consultați documentația systemd.exec , care menționează problemele de compatibilitate pentru programele care utilizează vechea select(2)interfață cu descriptori peste 1.023. Nu presupuneți că fiecare bibliotecă sau plugin din implementarea dvs. acceptă o limită arbitrară.

3. Verificați setările proprii ale Synapse și serviciile pentru lucrători

Dacă configurația Synapse este setată explicit soft_file_limitla un număr mic, este posibil ca setarea aplicației să mențină limita soft sub plafonul systemd. Căutați în fișierele de configurare active și în configurația inclusă cheia respectivă. Fie eliminați o suprascriere inutilă, fie setați-o în mod deliberat; valoarea implicită documentată de zero solicită Synapse să își ridice limita soft la limita hard disponibilă.

Pentru o implementare multi-proces, fiecare lucrător este un proces separat și poate fi pornit de o unitate separată sau o instanță șablon. Creșterea limitei serviciului principal nu dovedește automat că fiecare lucrător are limita dorită. Inspectați numele unităților lucrătoare reale cu systemctl list-units, apoi aplicați și verificați opțiunea drop-in corespunzătoare pentru fiecare serviciu care o necesită.

În mod similar, setările din /etc/security/limits.confși dintr-un shell de autentificare ulimitnu guvernează, în general, un serviciu de sistem lansat direct de systemd. Pentru această configurare, modificați limita de resurse a unității și verificați-o în procesul pe care systemd l-a pornit efectiv.

4. Dacă Synapse rulează într-un container

O suprascriere systemd la nivel de gazdă pentru un serviciu diferit nu modifică automat limita de descriptori de fișiere a unui container. Configurați nivelul de execuție sau de orchestrare al containerului. Pentru Docker Compose, definiția serviciului acceptă per container ulimits; un exemplu este:

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

Numărul este ilustrativ; dimensionați-l în funcție de utilizare și de limitele gazdei. Referința serviciului Compose din Docker documentează ulimitssetarea. Începând cu Docker Engine 29, notele de lansare ale Docker descriu o modificare a limitei implicite nofile asociate cu containerd 2.1.5: containerele pot primi 1.024 în loc de valoarea implicită anterioară de 1.048.576. Dacă problema a apărut după o actualizare a motorului, verificați limita efectivă a containerului și setați explicit ulimit-ul necesar în configurația de implementare. Consultați notele de lansare ale Docker Engine 29 și referința de rulare a dockerului .

5. Verificați limita procesului Synapse care rulează

După repornire, verificați limita la nivel de proces, nu doar configurația systemd. Obțineți PID-ul principal și inspectați limitele raportate de kernel:

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

Dacă PID-ul principal este zero sau aparține unui wrapper și nu Synapse, identificați procesul Synapse în grupul de control al serviciului și inspectați acel PID în schimb. Numărul de descriptori este o instantanee; repetați-o în timpul încărcării reprezentative. Confirmați că „Max open files” reflectă limitele soft și hard intenționate, că numărul rămâne confortabil sub limita soft și că jurnalul nu mai raportează eroarea.

Dacă numărul continuă să crească până când atinge noul plafon, este posibil ca limita să nu facă decât să amâne eșecul. Întrebările frecvente despre Synapse menționează că solicitările blocate sau lente pot fi relevante atunci când se investighează epuizarea fișierelor. Examinați jurnalele și procesarea solicitărilor înconjurătoare, comparați numărul descriptorilor în timp și investigați o posibilă scurgere de informații sau conexiuni persistente în mod neașteptat, în loc să continuați să creșteți limita orbește.

Când creșterea limitei per serviciu nu este suficientă

Dacă jurnalele raportează o eroare de epuizare a tabelei de fișiere la nivel de sistem, cum ar fi ENFILE, inspectați utilizarea la nivel de gazdă și alte servicii; o LimitNOFILEmodificare per serviciu nu va crește capacitatea kernelului la nivel de sistem. Evitați modificarea limitelor globale ale kernelului fără a confirma eroarea și a înțelege impactul la nivel de gazdă. Dacă limita raportată de serviciu rămâne scăzută după o instalare drop-in, executați systemctl cat matrix-synapse.servicepentru a confirma că instalarea drop-in-ului este încărcată, verificați numele unității, reîncărcați systemd și reporniți unitatea corectă.

Autoverificare rapidă

• Ai identificat unitatea sau containerul exact Synapse care înregistrează eroarea?
• Raportează systemctl showlimita prevăzută pentru acea unitate?
• Afișează /proc/<Synapse-PID>/limitslimitele soft și hard intenționate după repornire?
• Este numărul descriptorilor sub limita soft în condiții de sarcină maximă normală?
• Sunt unitățile de lucru și setările containerului verificate separat, acolo unde este cazul?
• Eroarea s-a oprit sau utilizarea continuă să crească spre noul plafon?

Dacă toate verificările la nivel de proces trec cu succes și eroarea s-a oprit în timpul traficului reprezentativ, modificarea limitei systemd funcționează. Dacă descriptorii continuă să se acumuleze sau sistemul raportează o lipsă globală, continuați să investigați sursa, în loc să tratați o limită mai mare ca fiind soluția completă.

Surse

• Întrebări frecvente despre administrarea sinapselor: epuizarea identificatorului de fișiere
• Referință de configurare a sinapselor: soft_file_limit
• Manual systemd.exec: limitele resurselor de serviciu
• Manual Linux: getrlimit și prlimit
• Note de lansare Docker Engine 29