Mastodon ‘Sidekiq Queue Backlog’ Causando Atrasos: Recuperação

Quando sua instância Mastodon fica lenta, notificações chegam com horas de atraso ou posts falham na federação, o backlog da fila Sidekiq geralmente é o culpado. Este backlog ocorre quando trabalhos em segundo plano se acumulam mais rápido que seu servidor consegue processar. Neste artigo, você aprenderá por que isso acontece, como limpar e como prevenir que se repita.

Por que um Backlog da Fila Sidekiq se Forma na Sua Instância Mastodon

Sidekiq é o processador de trabalhos em segundo plano que lida com quase todas as tarefas assíncronas no Mastodon. Ele envia notificações, processa dados de federação de entrada e saída, gera miniaturas de mídia e atualiza timelines. Cada tipo de trabalho pertence a uma fila: default, push, pull, mailers e scheduler.

Um backlog se forma quando a taxa de trabalhos recebidos excede a capacidade de processamento dos workers Sidekiq. Gatilhos comuns incluem:

• Um pico repentino de atividade, como um post viral ou um novo usuário importando uma grande lista de contas seguidas.
• Configurações de concorrência Sidekiq insuficientes em relação à CPU e memória do servidor.
• Uma conexão lenta com o banco de dados ou Redis que faz os trabalhos expirarem e tentarem novamente, adicionando-os de volta à fila.
• Um único trabalho travado que bloqueia a fila porque o Sidekiq processa trabalhos sequencialmente por fila por padrão.

Quando o backlog cresce, novos trabalhos esperam mais tempo para serem processados. Os usuários experimentam atrasos em notificações, falhas de federação e atualizações lentas da timeline. Se não for tratado, o backlog pode causar exaustão de memória e derrubar completamente o processo Sidekiq.

Monitorando o Painel Sidekiq para Sinais de Backlog

A maneira mais rápida de confirmar um backlog é visitar o painel Sidekiq em https://sua-instancia.com/sidekiq. Se você não habilitou o painel, pode verificar a profundidade da fila via linha de comando:

redis-cli LLEN queue:default
redis-cli LLEN queue:push
redis-cli LLEN queue:pull

Um comprimento de fila acima de 1000 trabalhos por fila geralmente indica um backlog significativo que requer intervenção.

Recuperação Passo a Passo de um Backlog da Fila Sidekiq

O processo de recuperação envolve três fases: limpar trabalhos travados, drenar o backlog e ajustar configurações para evitar recorrência. Siga estes passos em ordem.

1. Reinicie o Sidekiq para Limpar Trabalhos Travados
   Conecte-se via SSH ao seu servidor Mastodon. Execute o seguinte comando para reiniciar todos os processos Sidekiq:
   systemctl restart mastodon-sidekiq
   Esta ação mata todos os workers Sidekiq atuais. Trabalhos travados que estavam em andamento serão recolocados na fila. Aguarde 30 segundos e verifique o painel Sidekiq para ver se a profundidade da fila diminuiu.
2. Execute o Sidekiq Manualmente com Maior Concorrência
   Se o backlog permanecer acima de 500 trabalhos por fila, aumente a concorrência temporariamente. Navegue até o diretório de instalação do Mastodon (geralmente /home/mastodon/live) e execute:
   RAILS_ENV=production bundle exec sidekiq -q default -q push -q pull -c 25
   Este comando inicia um único processo Sidekiq com 25 threads em vez do padrão de 10. Ajuste o valor -c com base nos núcleos de CPU do seu servidor. Para um servidor com 4 núcleos, use 20 a 30. Monitore a profundidade da fila a cada 60 segundos. Pare este processo com Ctrl+C assim que o backlog cair abaixo de 100 trabalhos por fila.
3. Limpe Repetições e Trabalhos Mortos do Painel
   Abra o painel Sidekiq no seu navegador. Clique na aba Retries. Se você vir centenas de trabalhos repetidos, clique no botão Clear All. Em seguida, clique na aba Dead e clique em Clear All. Isso remove trabalhos que falharam várias vezes e continuariam tentando novamente, desperdiçando capacidade de processamento.
4. Verifique a Entrega de Notificações e Federação
   Após o backlog ser limpo, teste a federação publicando um toot público e verificando se ele aparece em outra instância. Envie uma mensagem direta para um usuário local e confirme se ele recebe a notificação. Se os atrasos persistirem, verifique o painel Sidekiq novamente para novos backlogs na fila pull, que lida com dados de federação recebidos.
5. Ajuste a Concorrência do Sidekiq na Configuração de Produção
   Edite o arquivo de configuração do Sidekiq em /home/mastodon/live/config/sidekiq.yml. Altere o valor concurrency para um número que corresponda aos recursos do seu servidor. Para um servidor com 4 GB de RAM e 4 núcleos de CPU, defina a concorrência para 15 a 20. Salve o arquivo e reinicie o Sidekiq:
   systemctl restart mastodon-sidekiq
6. Escalone Processos Sidekiq (Opcional para Instâncias Grandes)
   Se sua instância tiver mais de 10.000 usuários ativos, considere executar múltiplos processos Sidekiq. Crie um arquivo de serviço systemd para um segundo processo, por exemplo /etc/systemd/system/mastodon-sidekiq-2.service, com um argumento -q diferente. Habilite e inicie o serviço:
   systemctl enable mastodon-sidekiq-2 && systemctl start mastodon-sidekiq-2

Se o Backlog Retornar ou Outros Problemas Aparecerem

Sidekiq Mostra Alto Uso de Memória Após Reinicialização

Um único processo Sidekiq com alta concorrência pode consumir mais de 1 GB de RAM. Se seu servidor tiver memória limitada, reduza o valor de concorrência em sidekiq.yml para 10 e adicione um segundo processo Sidekiq. Isso distribui a carga de memória entre dois processos.

Federação Ainda Falha Após Limpeza do Backlog

Se a federação de saída continuar quebrada, a fila push pode conter trabalhos que referenciam contas deletadas ou URLs inválidos. Use o painel Sidekiq para visualizar a fila Dead. Delete todos os trabalhos mortos e reinicie o Sidekiq. Se o problema persistir, verifique as regras de firewall da sua instância para conexões de saída na porta 443.

Exaustão de Memória Redis Causa Queda do Sidekiq

Um backlog pode encher a memória Redis com dados de trabalho. Execute redis-cli INFO memory para verificar used_memory_human. Se exceder 80% da configuração maxmemory do Redis, limpe as filas com redis-cli FLUSHDB (isso remove todos os trabalhos, então use apenas como último recurso). Em seguida, configure o Redis para usar a política de evicção allkeys-lru em /etc/redis/redis.conf.

Item	Reiniciar Sidekiq	Execução Manual com Alta Concorrência
Propósito	Limpar trabalhos travados e redefinir workers	Drenar backlog grande mais rápido que as configurações padrão permitem
Efeito nas filas	Recoloca todos os trabalhos em andamento na fila	Processa trabalhos a até 25x a taxa normal
Risco	Mínimo; trabalhos não são perdidos	Alto uso de memória se a concorrência for muito alta
Melhor para	Backlogs abaixo de 1000 trabalhos por fila	Backlogs acima de 5000 trabalhos por fila

Agora você pode identificar um backlog da fila Sidekiq, limpá-lo usando o painel Sidekiq ou linha de comando e ajustar as configurações de concorrência para evitar atrasos futuros. Para backlogs persistentes, considere dividir o Sidekiq em múltiplos processos ou atualizar os recursos do servidor. Como dica avançada, configure um alerta de monitoramento com Prometheus e o sidekiq_exporter para notificá-lo quando qualquer fila exceder 500 trabalhos.