Risolvi il problema "Troppi file aperti" di Matrix Synapse su systemd

Matrix Synapse potrebbe avviarsi normalmente e poi smettere di accettare connessioni, registrare il messaggio "Troppi file aperti" o sembrare bloccato sotto carico. In un'installazione systemd, la prima cosa da verificare è il limite di descrittori di file ereditato dal processo Synapse in esecuzione. La modifica ulimitdei limiti di una shell o di un file PAM in genere non modifica il limite per un servizio avviato da systemd.

I passaggi seguenti si applicano a un host Linux in cui Synapse viene eseguito come servizio systemd. L'unità potrebbe avere il nome matrix-synapse.service, matrix-synapse@.service, o un nome specifico del pacchetto. Verificare l'unità corretta prima di copiare i comandi. Se Synapse viene eseguito in Docker, Kubernetes o un altro container, consultare la sezione separata di seguito.

Cosa significa "Troppi file aperti"?

Linux assegna a ciascun processo un limite al numero di descrittori di file aperti. Un descrittore può fare riferimento a un file, un socket, una pipe o un'altra risorsa; di conseguenza, anche le connessioni di rete consumano descrittori. Quando un processo raggiunge il suo limite "soft", il tentativo di aprire o accettare un altro descrittore può fallire con un errore EMFILE. Linux ha anche un limite separato per la tabella dei file a livello di sistema: l'esaurimento di tale tabella può causare ENFILEun errore. Aumentare il limite di un singolo servizio Synapse non risolverà una carenza a livello di sistema.

Le FAQ ufficiali di amministrazione di Synapse affermano che un'elevata attività di connessione e federazione può consumare molti handle di file e che l'esaurimento di questi può impedire al server di accettare nuove connessioni TCP. Le linee guida suggeriscono di aumentare il limite ad almeno 4.096, rispetto ai valori predefiniti precedenti come 1.024 o 256. Considerate questo valore come un punto di riferimento per la risoluzione dei problemi nella situazione descritta, non come una raccomandazione universale per la capacità di ogni server domestico. Iniziate verificando il limite effettivo e l'utilizzo reale.

La documentazione di Linux relativa a getrlimit e prlimit descrive i limiti soft e hard per processo. Anche Synapse dispone di soft_file_limitun'impostazione; il manuale di configurazione di Synapse riporta un valore predefinito pari a zero, che indica a Synapse di impostare il suo limite soft al limite hard utilizzabile.

1. Confermare l'unità e diagnosticare il guasto

Innanzitutto, individua il nome effettivo del servizio. In molte installazioni di pacchetti è matrix-synapse.service, ma non dare per scontato questo nome se la tua installazione utilizza un'unità o dei worker personalizzati.

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

Cerca l'errore esatto, l'ora in cui è iniziato e se si verifica durante un picco di traffico, un'attività di federazione o un riavvio. Successivamente, controlla il limite che systemd segnala attualmente:

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

LimitNOFILEMostra il limite configurato del gestore dei servizi; non è un conteggio dei descrittori attualmente aperti. Un comando di shell come ulimit -nriporta solo il limite della shell corrente e non è una prova del limite del servizio.

2. Aumenta il limite del servizio systemd con un drop-in

Utilizza un componente aggiuntivo di systemd in modo che gli aggiornamenti dei pacchetti non richiedano la modifica del file di unità del fornitore. Il valore seguente è un esempio e non una soluzione ideale garantita per ogni server. Scegli un limite con un margine superiore al picco di utilizzo osservato e verifica la compatibilità delle applicazioni e delle dipendenze prima di impostare un valore insolitamente elevato.

sudo systemctl edit matrix-synapse.service

Aggiungi questo sotto il nuovo modulo dell'editor:

[Service]
LimitNOFILE=65536

Salva ed esci, quindi ricarica systemd e riavvia Synapse durante un intervallo di manutenzione appropriato:

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

Un singolo LimitNOFILEvalore definisce sia il limite flessibile che quello rigido per il servizio in systemd. Il manuale di systemd consente anche di specificare una soft:hardcoppia di valori. Il limite flessibile non può superare il limite rigido. Prima di scegliere un valore molto elevato, consultare la documentazione di systemd.exec , che segnala problemi di compatibilità per i programmi che utilizzano la vecchia select(2)interfaccia con descrittori superiori a 1.023. Non dare per scontato che ogni libreria o plugin nella propria implementazione supporti un limite arbitrario.

3. Controlla le impostazioni e i servizi dei lavoratori di Synapse.

Se la configurazione di Synapse imposta esplicitamente soft_file_limitun valore basso, l'impostazione dell'applicazione potrebbe mantenere il limite flessibile al di sotto del limite massimo di systemd. Cerca la chiave corrispondente nei file di configurazione attivi e nella configurazione inclusa. Rimuovi un override non necessario oppure impostalo deliberatamente; il valore predefinito documentato di zero richiede a Synapse di innalzare il limite flessibile al limite massimo disponibile.

In una distribuzione multi-processo, ogni worker è un processo separato e può essere avviato da un'unità o un'istanza modello separata. L'aumento del limite del servizio principale non garantisce automaticamente che ogni worker abbia il limite previsto. Ispeziona i nomi effettivi delle unità worker con systemctl list-units, quindi applica e verifica il drop-in appropriato per ogni servizio che ne ha bisogno.

Allo stesso modo, le impostazioni in /etc/security/limits.confuna shell di login ulimitgeneralmente non regolano un servizio di sistema avviato direttamente da systemd. Per questa configurazione, modifica il limite di risorse dell'unità e verificalo sul processo che systemd ha effettivamente avviato.

4. Se Synapse viene eseguito in un container

Un override di systemd a livello host per un servizio diverso non modifica automaticamente il limite di descrittori di file di un container. Configura il runtime del container o il livello di orchestrazione. Per Docker Compose, la definizione del servizio supporta per container ulimits; un esempio è:

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

Il numero è indicativo; dimensionatelo in base all'utilizzo e ai limiti dell'host. La documentazione del servizio Compose di Docker descrive l' ulimitsimpostazione. A partire da Docker Engine 29, le note di rilascio di Docker descrivono una modifica al limite predefinito di nofile associato a containerd 2.1.5: i container possono riceverne 1.024 anziché i precedenti 1.048.576 predefiniti. Se il problema si è presentato dopo un aggiornamento di Engine, verificate il limite effettivo dei container e impostate esplicitamente il limite ulimit necessario nella configurazione di distribuzione. Consultate le note di rilascio di Docker Engine 29 e la documentazione di riferimento di docker run .

5. Verificare il limite del processo Synapse in esecuzione

Dopo il riavvio, verifica il limite a livello di processo, non solo la configurazione di systemd. Ottieni il PID principale e controlla i limiti riportati dal 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

Se il PID principale è zero o appartiene a un wrapper anziché a Synapse, identificare il processo Synapse nel cgroup del servizio e controllare quel PID. Il conteggio dei descrittori è un'istantanea; ripeterlo durante un carico rappresentativo. Verificare che "Numero massimo di file aperti" rifletta i limiti soft e hard desiderati, che il conteggio rimanga ben al di sotto del limite soft e che il journal non segnali più l'errore.

Se il conteggio continua ad aumentare fino a raggiungere il nuovo limite massimo, quest'ultimo potrebbe semplicemente posticipare il problema. Le FAQ di Synapse indicano che le richieste bloccate o lente possono essere rilevanti quando si indaga sull'esaurimento dei descrittori di file. È consigliabile esaminare i log e l'elaborazione delle richieste, confrontare il numero di descrittori nel tempo e indagare su una possibile perdita di memoria o su connessioni persistenti inaspettate, anziché continuare ad aumentare il limite alla cieca.

Quando aumentare il limite per servizio non è sufficiente

Se i log segnalano un errore di esaurimento della tabella dei file a livello di sistema, come ad esempio ENFILE, esaminare l'utilizzo a livello di host e altri servizi; una LimitNOFILEmodifica per singolo servizio non aumenterà la capacità del kernel a livello di sistema. Evitare di modificare i limiti globali del kernel senza aver prima confermato l'errore e compreso l'impatto a livello di host. Se il limite segnalato del servizio rimane basso dopo un drop-in, eseguire systemctl cat matrix-synapse.serviceper confermare che il drop-in sia stato caricato, verificare il nome dell'unità, ricaricare systemd e riavviare l'unità corretta.

Autovalutazione rapida

• Hai identificato l'unità o il container Synapse esatto che registra l'errore?
• Il report indica systemctl showil limite previsto per quell'unità?
• Vengono /proc/<Synapse-PID>/limitsvisualizzati i limiti soft e hard previsti dopo il riavvio?
• Il conteggio dei descrittori è inferiore al limite flessibile in condizioni di carico di picco normale?
• Le unità lavorative e le impostazioni dei contenitori vengono controllate separatamente, ove applicabile?
• L'errore si è interrotto o l'utilizzo continua ad aumentare verso il nuovo limite massimo?

Se tutti i controlli a livello di processo vengono superati e l'errore si è interrotto durante un utilizzo rappresentativo del traffico, la modifica del limite di systemd sta funzionando. Se i descrittori continuano ad accumularsi o il sistema segnala una carenza globale, è consigliabile continuare a indagare sulla causa anziché considerare un limite più elevato come soluzione definitiva.

Fonti

• FAQ sull'amministrazione di Synapse: esaurimento dei handle di file
• Riferimento alla configurazione di Synapse: soft_file_limit
• Manuale di systemd.exec: limiti delle risorse di servizio
• Manuale Linux: getrlimit e prlimit
• Note di rilascio di Docker Engine 29