Corrigir erro "Muitos arquivos abertos" no Matrix Synapse em sistemas systemd.

O Matrix Synapse pode iniciar normalmente e, em seguida, parar de aceitar conexões, exibir a mensagem "Muitos arquivos abertos" ou parecer travado sob carga. Em uma instalação do systemd, a primeira coisa a verificar é o limite de descritores de arquivo herdado pelo processo do Synapse em execução. Alterar as configurações do shell ulimitou editar um arquivo de limites PAM geralmente não altera o limite para um serviço iniciado pelo systemd.

Os passos abaixo aplicam-se a um host Linux onde o Synapse é executado como um serviço do systemd. A unidade pode ter o nome `systemd` matrix-synapse.service, matrix-synapse@.service`system` ou algo específico do pacote. Confirme a unidade correta antes de copiar os comandos. Se o Synapse for executado em Docker, Kubernetes ou outro contêiner, consulte a seção separada abaixo.

O que significa “Muitos arquivos abertos”?

O Linux impõe um limite de descritores de arquivo abertos para cada processo. Um descritor pode se referir a um arquivo, socket, pipe ou outro recurso; portanto, as conexões de rede também consomem descritores. Quando um processo atinge seu limite flexível, uma tentativa de abrir ou aceitar outro descritor pode falhar com um erro EMFILE. O Linux também possui um limite separado para a tabela de arquivos em todo o sistema: o esgotamento dessa tabela pode gerar um erro ENFILE. Aumentar o limite de um serviço do Synapse não resolverá uma escassez em todo o sistema.

O FAQ oficial de administração do Synapse afirma que alta atividade de conexão e federação pode usar muitos descritores de arquivo e que o esgotamento desses descritores pode fazer com que o servidor pare de aceitar novas conexões TCP. A recomendação menciona o aumento do limite para pelo menos 4.096, considerando valores padrão mais antigos, como 1.024 ou 256. Considere isso como um limite mínimo para a situação descrita, e não como uma recomendação universal de capacidade para todos os servidores domésticos. Comece verificando o limite efetivo e o uso real.

A documentação do getrlimit e do prlimit do Linux descreve os limites flexíveis e rígidos por processo. O Synapse também possui uma soft_file_limitconfiguração; a referência de configuração do Synapse documenta um valor padrão de zero, que instrui o Synapse a definir seu limite flexível para o limite rígido que ele pode usar.

1. Confirme a unidade e diagnostique a falha.

Primeiro, encontre o nome real do serviço. Em muitas instalações de pacotes, ele é `service` matrix-synapse.service, mas não assuma esse nome se sua instalação usar uma unidade personalizada ou 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

Procure o erro exato, a hora em que começou e se ele ocorre durante um pico de tráfego, atividade de federação ou reinicialização. Em seguida, verifique o limite que o systemd está relatando atualmente:

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

LimitNOFILEMostra o limite configurado do gerenciador de serviços; não é uma contagem de descritores atualmente abertos. Um comando do shell, como este, ulimit -napenas relata o limite do shell atual e não comprova o limite do serviço.

2. Aumente o limite do serviço systemd com um comando drop-in.

Use um módulo drop-in do systemd para que as atualizações de pacotes não exijam a edição do arquivo de unidade do fornecedor. O valor a seguir é um exemplo e não representa o ideal para todos os servidores. Escolha um limite com margem acima do pico de uso observado e verifique a compatibilidade do aplicativo e das dependências antes de definir um valor excepcionalmente alto.

sudo systemctl edit matrix-synapse.service

Adicione isto à seção de novos recursos do editor:

[Service]
LimitNOFILE=65536

Salve e saia, depois recarregue o systemd e reinicie o Synapse durante uma janela de manutenção apropriada:

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

Um único LimitNOFILEvalor define os limites flexível e rígido para o serviço no systemd. O manual do systemd também permite um soft:hardpar de valores. O limite flexível não pode exceder o limite rígido. Antes de escolher um valor muito alto, consulte a documentação do systemd.exec , que menciona problemas de compatibilidade para programas que usam a select(2)interface antiga com descritores acima de 1023. Não presuma que todas as bibliotecas ou plugins em sua implementação suportam qualquer limite arbitrário.

3. Verifique as configurações e os serviços de trabalho do próprio Synapse.

Se a sua configuração do Synapse definir explicitamente soft_file_limitum valor baixo, a configuração do aplicativo pode manter o limite flexível abaixo do limite máximo do systemd. Procure essa chave nos arquivos de configuração ativos e na configuração incluída. Remova qualquer sobrescrita desnecessária ou defina-a deliberadamente; o valor padrão documentado de zero instrui o Synapse a aumentar seu limite flexível para o limite rígido disponível.

Em uma implantação com múltiplos processos, cada worker é um processo separado e pode ser iniciado por uma unidade ou instância de modelo independente. Aumentar o limite do serviço principal não garante automaticamente que todos os workers tenham o limite desejado. Inspecione os nomes das unidades de worker com `--worker-name` systemctl list-units, aplique e verifique o drop-in apropriado para cada serviço que precisar.

Da mesma forma, as configurações /etc/security/limits.confdo shell de login ulimitgeralmente não controlam um serviço do sistema iniciado diretamente pelo systemd. Para essa configuração, altere o limite de recursos da unidade e verifique-o no processo que o systemd realmente iniciou.

4. Se o Synapse for executado em um contêiner

Uma configuração do systemd em nível de host para um serviço diferente não altera automaticamente o limite de descritores de arquivo de um contêiner. Configure o ambiente de execução ou a camada de orquestração do contêiner. Para o Docker Compose, a definição de serviço suporta configurações por contêiner ulimits; um exemplo é:

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

O número é ilustrativo; dimensione-o com base no uso e nos limites do host. A documentação de referência do serviço Composeulimits do Docker descreve essa configuração. A partir do Docker Engine 29, as notas de versão do Docker descrevem uma alteração no limite padrão de nofile associado ao containerd 2.1.5: os contêineres podem receber 1.024 em vez do padrão anterior de 1.048.576. Se o problema surgiu após uma atualização do Engine, verifique o limite efetivo de contêineres e defina explicitamente o ulimit necessário na configuração de implantação. Consulte as notas de versão do Docker Engine 29 e a referência do docker run .

5. Verifique o limite de processos do Synapse em execução.

Após a reinicialização, verifique o limite em nível de processo, não apenas a configuração do systemd. Obtenha o PID principal e inspecione seus limites relatados pelo 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 o PID principal for zero ou pertencer a um processo wrapper em vez do Synapse, identifique o processo Synapse no cgroup do serviço e inspecione esse PID. A contagem de descritores é um instantâneo; repita o processo durante uma carga representativa. Confirme se o valor de "Máximo de arquivos abertos" reflete os limites flexíveis e rígidos pretendidos, se a contagem permanece confortavelmente abaixo do limite flexível e se o registro de erros não é mais reportado.

Se a contagem continuar aumentando até atingir o novo limite máximo, é possível que o limite esteja apenas adiando a falha. As perguntas frequentes do Synapse observam que solicitações travadas ou lentas podem ser relevantes ao investigar o esgotamento de descritores de arquivo. Analise os logs e o processamento de solicitações, compare a contagem de descritores ao longo do tempo e investigue um possível vazamento ou conexões inesperadamente persistentes, em vez de continuar aumentando o limite indiscriminadamente.

Quando aumentar o limite por serviço não for suficiente

Se os logs reportarem um erro de esgotamento da tabela de arquivos em todo o sistema, como ENFILE, inspecione o uso em todo o host e em outros serviços; uma alteração por serviço LimitNOFILEnão aumentará a capacidade do kernel em todo o sistema. Evite alterar os limites globais do kernel sem confirmar o erro e entender o impacto em todo o host. Se o limite relatado do serviço permanecer baixo após a instalação de um pacote adicional, execute systemctl cat matrix-synapse.servicepara confirmar se o pacote foi carregado, verifique o nome da unidade, recarregue o systemd e reinicie a unidade correta.

Autoverificação rápida

• Você identificou a unidade ou o contêiner exato do Synapse que registra o erro?
• O relatório indica systemctl showo limite pretendido para essa unidade?
• Mostra /proc/<Synapse-PID>/limitsos limites flexíveis e rígidos pretendidos após a reinicialização?
• A contagem de descritores está abaixo do limite flexível sob carga de pico normal?
• As configurações das unidades de trabalho e dos contêineres são verificadas separadamente, quando aplicável?
• O erro parou ou o uso continua a crescer em direção ao novo limite?

Se todas as verificações em nível de processo forem aprovadas e o erro tiver cessado durante um período de tráfego representativo, a alteração do limite do systemd está funcionando. Se os descritores continuarem a se acumular ou se o sistema relatar uma escassez global, continue investigando a origem do problema em vez de considerar um limite maior como a solução definitiva.

Fontes

• Perguntas frequentes sobre administração do Synapse: esgotamento de identificadores de arquivo
• Referência de configuração do Synapse: soft_file_limit
• Manual do systemd.exec: limites de recursos do serviço
• Manual do Linux: getrlimit e prlimit
• Notas de lançamento do Docker Engine 29