Corrigir atrasos na federação de sinapses do Matrix e lentidão na entrada em salas.

Comece por localizar o atraso.

Quando uma sala do Matrix demora muito para abrir ou para entrar, primeiro determine se o atraso afeta um servidor remoto, uma sala específica ou toda a sua instância do Synapse. Essa distinção é importante: a federação é uma troca bidirecional entre servidores, e entrar em uma sala pode envolver vários servidores. A lentidão na entrada pode ser causada pelo seu processo do Synapse, pelo servidor remoto, pelo roteamento DNS ou TLS, pelo banco de dados ou pelo tamanho e estado da sala. Não existe uma única configuração para "atraso na federação" que resolva todos esses problemas.

Verificado: o Synapse registra informações sobre tentativas de conexão do destino remoto, expõe métricas do Prometheus e inclui limites de taxa para ingresso em salas. Depende da situação: qual desses fatores é responsável pela lentidão de um ingresso específico? Não é possível determinar apenas pelo sintoma: se o outro servidor doméstico ou uma rede intermediária está lenta. Comece com um usuário afetado, uma sala e o horário aproximado de uma tentativa lenta; compare esses detalhes com uma sala de controle que ingressa normalmente.

Verifique se a federação está acessível.

Use o Matrix Federation Tester oficial com o nome do servidor Matrix do seu servidor doméstico. Ele pode revelar problemas comuns de DNS, delegação, certificado e acessibilidade. O nome do servidor nos IDs de usuário pode ser diferente da máquina ou proxy que hospeda o Synapse, portanto, verifique o endpoint de federação e a delegação configurados em vez de presumir que o domínio do ID de usuário hospeda o Synapse diretamente.

A documentação de federação do Synapse descreve a porta de federação padrão como TCP 8448, enquanto implantações delegadas ou com proxy reverso podem usar HTTPS na porta 443. A porta relevante deve ser acessível a partir de outros servidores domésticos, e os firewalls de saída também podem precisar permitir o tráfego de federação. Verifique as regras de firewall de entrada e saída correspondentes e teste novamente no Testador de Federação. Não abra ambas as portas indiscriminadamente se sua implantação estiver configurada para usar apenas uma.

Um resultado que mostre um erro de certificado, DNS ou roteamento indica um problema de configuração ou de conectividade de rede, e não de capacidade do servidor. Revise os registros DNS e a delegação para o nome do servidor Matrix, a cadeia de certificados TLS do proxy reverso e se o proxy está encaminhando os caminhos de federação para o Synapse. O Synapse documenta que um redirecionamento permanente 308 não é seguido pelos servidores de federação em algumas configurações, portanto, investigue também redirecionamentos inesperados. Corrija a verificação específica com falha e teste novamente antes de alterar a quantidade de workers ou os limites de taxa.

Referência: Configuração e resolução de problemas da federação Synapse e orientações sobre o firewall Synapse .

Verifique se um servidor remoto está em período de espera para novas tentativas.

Após falhas nas solicitações de federação, o Synapse marca temporariamente um destino remoto como offline. Os atrasos de repetição utilizam um mecanismo de backoff, portanto, falhas repetidas podem fazer com que mensagens ou junções envolvendo esse destino pareçam atrasadas. Isso não significa que todo o seu servidor doméstico esteja lento: pode ser apenas um servidor remoto inacessível ou com falhas nas solicitações.

Os administradores podem inspecionar a API de Administração de Federação do Synapse, que documenta o processo GET /_synapse/admin/v1/federation/destinations. Use um token de acesso de administrador de servidor e mantenha-o em sigilo. Analise os registros de destino e os campos de novas tentativas do servidor principal envolvido na sala afetada. Esses registros ajudam a identificar quando um destino está tentando novamente, mas não comprovam, por si só, o motivo da falha de conexão. Correlacione-os com os logs do Synapse, logs de proxy, testes de DNS/TLS e os horários em que os usuários relataram problemas.

A API de Administração da Federação é documentada como experimental e sujeita a alterações. Evite criar scripts para ela como se fosse uma API de cliente pública e estável. O Synapse também documenta uma operação de redefinição de tempo limite de conexão que pode iniciar outra tentativa em segundo plano para um destino já em período de espera. Trate isso como uma ação de diagnóstico ou recuperação somente após corrigir ou compreender a falha subjacente; limpar repetidamente os períodos de espera não fará com que um servidor remoto com problemas responda. Uma resposta HTTP bem-sucedida do endpoint de redefinição não significa que a tentativa de federação em segundo plano já tenha sido concluída.

Referência: API de administração da Federação Synapse . O status experimental da API e os campos disponíveis podem mudar a cada nova versão do Synapse, portanto, verifique a documentação da versão que você está usando antes de executar qualquer operação.

Meça o Synapse e seu banco de dados antes de dimensioná-lo.

Habilite o endpoint de métricas do Prometheus do Synapse somente em uma rede interna confiável ou protegida por controles de acesso. O guia oficial de monitoramento documenta /_synapse/metricse demonstra como expô-lo por meio de um listener de métricas ou um listener HTTP existente. As métricas podem incluir detalhes operacionais; não publique este endpoint abertamente. Se você já coleta métricas, compare o tempo de uma junção lenta com o uso de CPU, memória, latência de requisição, duração da transação do banco de dados e atividade de federação de entrada e saída.

Use os gráficos para distinguir sobrecargas generalizadas de atrasos específicos da federação. Se as solicitações comuns do cliente e as transações do banco de dados ficarem lentas ao mesmo tempo que as junções, verifique a pressão da CPU e da memória do host, a integridade do PostgreSQL, os limites de conexão, a latência do disco e as consultas de longa duração. Se a atividade da sala local permanecer responsiva, mas um destino remoto apresentar falhas ou atrasos nas tentativas, priorize a acessibilidade da federação e esse servidor remoto. Se apenas uma sala grande for afetada, o estado da sala e o número de servidores participantes podem contribuir; compare com uma sala menor antes de tirar conclusões.

O guia do Grafana da Synapse recomenda verificar o tempo de envio de mensagens, o uso de CPU e memória, a contagem e a duração das transações do banco de dados e os gráficos de federação. Uma alta contagem de transações não significa necessariamente que o gargalo seja a causa; a duração e a carga do sistema também são importantes. Verifique os nomes das métricas da sua versão do Synapse e a documentação atual do painel, pois as métricas foram renomeadas ao longo do tempo.

Referências: Monitoramento do Synapse com o Prometheus e compreensão do Synapse por meio de gráficos do Grafana .

Verifique a limitação de velocidade e os picos de tráfego ao entrar na sala.

O Synapse possui rc_joinslimites separados para entradas locais e remotas. Uma entrada remota pode exigir mais trabalho do que entrar em uma sala da qual o servidor já participa. O Synapse também possui rc_joins_per_roomum recurso que limita as entradas recentes a uma sala para ajudar a mitigar ondas de entradas em massa. Se os registros ou as respostas do cliente indicarem limitação de taxa, verifique essas configurações e o volume de entradas recentes antes de alterá-las.

Não aumente os limites de taxa como uma solução geral para melhorar a velocidade. Limites mais altos podem aumentar a carga no seu servidor e em outros servidores domésticos, além de reduzir a proteção contra ataques de inundação de servidores. Se uma migração ou integração legítima atingir um limite configurado, identifique o limite exato e revise os valores documentados para a sua versão do Synapse. Considere distribuir a carga de trabalho de ingresso ao longo do tempo. Altere um valor relevante por vez, mantenha a configuração anterior e monitore as taxas de erro e o uso de recursos após recarregar ou reiniciar o servidor, conforme necessário para a sua implementação.

Referência: Configuração do Synapse:rc_joins e Configuração do Synapse:rc_joins_per_room . Os valores padrão e as opções suportadas podem variar conforme a versão; compare-os com a sua versão instalada antes de editar.

Use um teste de junção controlada.

1. Selecione uma sala afetada e registre o alias ou ID da sala, o servidor doméstico do usuário que entrou, o horário e o erro exato do cliente. Nunca inclua tokens de acesso em um registro de suporte.
2. Verifique o Testador de Federação para o nome do seu servidor e confirme o ponto de extremidade de federação configurado, o certificado e a rota do proxy.
3. Analise os registros do Synapse em torno desse horário para identificar falhas de federação, erros de destino remoto, tempos limite ou respostas de limite de taxa. Pesquise nos registros do proxy reverso e do banco de dados por atrasos correspondentes.
4. Inspecione a API do Administrador de Federação para verificar o estado de novas tentativas associado aos destinos remotos relevantes. Compare as salas afetadas com uma sala de controle que se conecta prontamente.
5. Compare as métricas do Prometheus e do host no mesmo intervalo. Procure por latência de requisição elevada, duração da transação do banco de dados, uso de CPU, pressão de memória ou pico na atividade de federação.
6. Faça uma correção específica — como corrigir um problema de DNS/TLS/proxy, resolver um gargalo no banco de dados ou ajustar uma restrição de limite de taxa confirmada — depois repita o mesmo teste e compare os resultados.

Suposições comuns a evitar

• "Uma conexão lenta significa que a porta 8448 do meu servidor está fechada." Não necessariamente. Delegação ou um proxy reverso podem usar a porta 443. Verifique o endpoint de federação configurado e teste-o.
• Um teste de federação bem-sucedido comprova que todas as conexões à sala serão rápidas. Ele verifica apenas a configuração e a conectividade comuns da federação. A integridade do servidor remoto, o estado da sala, a carga local e o desempenho do banco de dados ainda podem afetar a conexão. Teste a sala afetada e examine os registros.
• "O atraso na federação sempre se origina na minha instância do Synapse." A própria documentação de configuração do Synapse alerta que o atraso observado na federação pode ter origem em qualquer um dos pontos de extremidade ou na rede entre eles. Compare os destinos e colete evidências de ambas as extremidades, sempre que possível.
• “Adicionar trabalhadores ou aumentar os limites de taxa é a primeira solução.” Essas alterações são úteis apenas quando as medições apontam para problemas de capacidade ou limitação de taxa. Primeiro, identifique se o problema é de conectividade, nova tentativa remota, saturação local, latência do banco de dados ou limitação de taxa de junção.

Verifique se a correção funcionou.

Repita o mesmo teste de junção após a alteração. Confirme se o usuário consegue se conectar com sucesso, se o destino afetado não está mais apresentando falhas repetidamente, se o Federation Tester reporta as verificações relevantes corretamente e se a latência da requisição/banco de dados retorna ao seu nível normal. Observe se o problema se repete durante um período de alta demanda posterior; uma tentativa bem-sucedida não comprova que o servidor remoto ou a rede estejam sempre íntegros.

Se suas métricas locais e verificações de federação parecerem normais, mas apenas um servidor remoto continuar apresentando falhas, compartilhe o carimbo de data/hora, o destino, o erro tratado e os IDs de solicitação relevantes com os administradores desse servidor. Se várias salas e destinos forem afetados juntamente com solicitações locais lentas, investigue a capacidade do Synapse e do PostgreSQL antes de ajustar o comportamento da federação. Registre sua versão do Synapse nas notas do incidente, pois os detalhes de configuração e da API de administração podem mudar.