Retransmissor do Mastodon Causando Acúmulo na Fila do Sidekiq: Diagnóstico

Retransmissores (relays) do Mastodon transmitem publicações públicas de uma instância para todas as conectadas. Isso pode causar uma enxurrada de tráfego de federação que sobrecarrega o Sidekiq, o processador de tarefas em segundo plano. Quando as filas do Sidekiq enchem, novas publicações locais, notificações e entregas diminuem ou param completamente. Este artigo explica por que relays criam acúmulos no Sidekiq e como diagnosticar a causa raiz.

Você aprenderá a identificar pressão na fila relacionada a relays, medir o impacto exato na sua instância e decidir se deve desconectar ou limitar o relay. O objetivo é restaurar a taxa de processamento normal do Sidekiq sem desabilitar completamente a federação.

Por que Relays Causam Acúmulos no Sidekiq

Um relay do Mastodon atua como um hub de publicação-assinatura. Quando qualquer instância publica uma postagem que corresponde às regras do relay, o relay encaminha essa postagem para todas as instâncias conectadas. Para uma instância pequena com algumas centenas de usuários, um único relay pode entregar milhares de postagens por minuto. Cada postagem recebida aciona workers do Sidekiq para processar, armazenar e potencialmente entregar a postagem adiante.

O Sidekiq usa múltiplas filas com prioridades diferentes. A fila push lida com entregas de saída para outras instâncias. A fila pull lida com atividades recebidas de relays e outras instâncias. Quando um relay inunda a fila pull, os workers ficam saturados. Eles não conseguem processar tarefas locais, como enviar notificações, atualizar timelines ou entregar postagens dos seus usuários. O acúmulo cresce até o Sidekiq ficar sem memória ou os workers atingirem o limite de concorrência configurado.

A causa raiz não é o relay em si, mas a proporção entre o tráfego recebido e os recursos disponíveis dos workers. Um relay que envia 500 postagens por minuto para uma instância com apenas 25 workers do Sidekiq criará um acúmulo persistente. O acúmulo só é limpo quando o tráfego recebido cai abaixo da capacidade de processamento.

Passos para Diagnosticar Acúmulo Relacionado a Relay

1. Verifique o painel do Sidekiq
   Abra https://suainstancia.com/sidekiq/queues. Observe os tamanhos das filas pull e push. Uma fila saudável mostra de 0 a 100 tarefas pendentes. Um acúmulo causado por relay mostra milhares ou dezenas de milhares de tarefas pendentes. Anote a contagem exata e se ela cresce ou permanece estável.
2. Identifique o relay com mais tráfego
   Vá em Preferências > Administração > Federação > Relays. Cada linha do relay mostra o número de mensagens recebidas. Ordene por mensagens recebidas em ordem decrescente. O relay com o maior número é o provável culpado. Anote sua URL e contagem de mensagens.
3. Monitore o crescimento da fila por 5 minutos
   Atualize a página de filas do Sidekiq a cada 60 segundos por 5 minutos. Se a contagem da fila pull aumentar em mais de 200 tarefas por minuto, o relay está sobrecarregando sua instância. Tire um print ou anote os horários e contagens.
4. Verifique a latência dos workers do Sidekiq
   No painel do Sidekiq, observe a coluna Latency. Latência acima de 10 segundos indica que os workers não estão conseguindo acompanhar. O tráfego de relay é a causa mais comum de latência alta em instâncias pequenas e médias.
5. Examine os logs do Sidekiq em busca de erros de relay
   Execute journalctl -u sidekiq -n 200 --no-pager no servidor. Procure por linhas contendo ProcessingWorker, ActivityPub::IncomingActivity ou Relay. Erros repetidos de timeout ou conexão sugerem que o relay está enviando dados mais rápido do que sua instância consegue aceitar.
6. Compare o acúmulo com o momento de ativação do relay
   Se você ativou o relay recentemente, verifique o histórico da fila do Sidekiq. Um acúmulo que começou imediatamente após ativar o relay confirma a causa. Se o acúmulo existia antes do relay, o problema pode ser outra coisa, como uma federação mal configurada ou um ataque DDoS.

Se o Acúmulo Persistir Após o Diagnóstico

Fila do Sidekiq travada em contagem alta mesmo após desconectar o relay

Desconectar o relay interrompe o novo tráfego recebido, mas as tarefas já enfileiradas precisam ser concluídas. O Sidekiq pode levar horas para limpar um acúmulo de 10.000 tarefas. Para acelerar, aumente temporariamente o número de workers do Sidekiq. Edite docker-compose.yml ou o arquivo de serviço systemd e adicione mais configurações de concurrency. Reinicie o Sidekiq após a alteração.

Relay mostra zero mensagens, mas o acúmulo permanece

O relay pode estar mal configurado ou o servidor do relay pode estar offline. Remova o relay de Administração > Federação > Relays e adicione-o novamente. Se o acúmulo não for limpo em 30 minutos, o próprio servidor do relay pode estar enviando atividades duplicadas. Entre em contato com o operador do relay e peça para verificar os logs.

Workers do Sidekiq travam com erros de falta de memória

Um grande acúmulo consome RAM. Cada tarefa pendente mantém uma referência aos dados da atividade. Se seu servidor tiver menos de 2 GB de RAM, o Sidekiq pode ficar sem memória. Aumente a RAM do servidor ou reduza a concorrência do Sidekiq para 5 workers ou menos. Em seguida, desconecte o relay e deixe o acúmulo drenar lentamente.

Item	Relay Conectado	Relay Desconectado
Taxa de crescimento da fila pull	200-1000 tarefas por minuto	0-20 tarefas por minuto
Latência dos workers	10-60 segundos	Abaixo de 2 segundos
Uso de memória pelo Sidekiq	1,5-3 GB	200-500 MB
Tempo para limpar o acúmulo	Nunca limpa	30 minutos a 4 horas

Agora você consegue identificar se um relay do Mastodon está causando acúmulo na fila do Sidekiq. Comece verificando o painel do Sidekiq e as contagens de mensagens do relay. Se o acúmulo for confirmado, desconecte o relay e monitore a fila por 30 minutos. Para acúmulos persistentes, aumente a concorrência dos workers do Sidekiq ou atualize a memória do servidor. Como passo avançado, configure um processo Sidekiq dedicado para a fila pull para que o tráfego do relay não bloqueie tarefas locais.