Contagem de Workers Sidekiq para Relay Mastodon: Como Ajustar Corretamente

Executar um relay Mastodon exige ajuste cuidadoso da contagem de workers Sidekiq. Se você definir muitos workers, o servidor fica sem RAM e o relay para de responder. Se definir poucos, as atividades recebidas se acumulam e os atrasos na federação aumentam. Este artigo explica como calcular a contagem correta de workers Sidekiq para seu relay Mastodon com base na memória disponível e no volume de tráfego esperado. Você aprenderá a fórmula de memória por worker, os arquivos de configuração para editar e como monitorar a saúde das filas após as alterações.

Por que a Contagem de Workers Sidekiq é Importante para um Relay Mastodon

Um relay Mastodon recebe postagens públicas de muitas instâncias e as redistribui para todos os servidores conectados. Isso gera um alto volume de atividades recebidas que precisam ser processadas rapidamente. O Sidekiq lida com essas atividades como trabalhos em segundo plano. Cada processo worker Sidekiq consome cerca de 200 MB de RAM em estado estável. Se a contagem de workers exceder a memória disponível, o sistema operacional começa a fazer swap e o relay fica lento ou trava.

A configuração padrão de concorrência do Sidekiq em uma instalação padrão do Mastodon é de 5 workers por fila. Para um servidor de instância única, isso geralmente é suficiente. Para um relay, as filas default e relay podem acumular milhares de trabalhos por minuto. Uma concorrência de 5 significa que apenas 5 trabalhos são executados por vez. O resto espera na fila. A latência da fila cresce de segundos para minutos, e as instâncias conectadas notam atrasos no recebimento de postagens.

Planejamento do Orçamento de Memória

Antes de alterar a contagem de workers, calcule seu orçamento de memória. Comece com a RAM total do servidor em megabytes. Subtraia 1024 MB para o sistema operacional, o processo web do Mastodon e o banco de dados PostgreSQL. A memória restante está disponível para os workers Sidekiq. Divida esse número por 200 para obter a concorrência máxima segura por fila.

Por exemplo, um servidor com 4 GB de RAM tem 4096 MB no total. Subtrair 1024 MB deixa 3072 MB. Dividir por 200 dá 15 workers. Essa é a concorrência máxima que você deve definir. Começar com 10 workers é mais seguro e deixa espaço para picos de memória durante horários de pico de tráfego.

Passos para Configurar a Contagem de Workers Sidekiq para um Relay Mastodon

O método de configuração depende se você instalou o Mastodon a partir do código fonte ou usa Docker. Ambos os métodos alcançam o mesmo resultado. Escolha o que corresponde à sua configuração.

Método 1: Editar mastodon.yml para Instalações a Partir do Código Fonte

1. Abra o arquivo de configuração do Mastodon
   Execute sudo nano /etc/mastodon/mastodon.yml. Se o arquivo não existir, verifique /home/mastodon/live/.env.production.
2. Localize ou adicione a configuração de concorrência do Sidekiq
   Encontre a linha concurrency: na seção sidekiq:. Se não existir, adicione estas linhas no final do arquivo:
   sidekiq:
concurrency: 10
3. Salve o arquivo e reinicie o Sidekiq
   Pressione Ctrl+O e depois Ctrl+X para salvar e sair. Reinicie o serviço Sidekiq com sudo systemctl restart mastodon-sidekiq.
4. Verifique a nova contagem de workers
   Execute sudo systemctl status mastodon-sidekiq e procure a linha contendo concurrency nos argumentos do processo. Deve mostrar o novo número.

Método 2: Definir Variável de Ambiente para Instalações Docker

1. Abra seu arquivo Docker Compose
   Execute sudo nano /opt/mastodon/docker-compose.yml ou o caminho onde você armazena seu arquivo compose.
2. Adicione a variável de ambiente SIDEKIQ_CONCURRENCY
   Encontre a definição do serviço sidekiq. Na seção environment: adicione:
   - SIDEKIQ_CONCURRENCY=10
3. Recrie o contêiner Sidekiq
   Execute sudo docker compose up -d sidekiq no diretório que contém o arquivo compose. Isso reinicia o contêiner com a nova concorrência.
4. Confirme a alteração
   Execute sudo docker compose logs sidekiq | grep concurrency. A saída deve mostrar o novo valor de concorrência.

Erros Comuns de Ajuste do Sidekiq e Como Evitá-los

Definir Concorrência Acima da Memória Disponível

Se você definir concorrência para 25 em um servidor de 4 GB, o sistema fica sem RAM. O kernel mata o processo Sidekiq ou começa a fazer swap pesado. Monitore o uso de memória com htop ou free -m após alterar a contagem. Se o uso de memória exceder 90 por cento, reduza a concorrência em 2 e teste novamente.

Ignorar Limites de Workers Específicos por Fila

O Mastodon executa várias filas Sidekiq: default, push, mailers, pull e relay. A configuração de concorrência se aplica igualmente a todas as filas. Se apenas a fila relay estiver saturada, considere executar um processo Sidekiq separado dedicado à fila relay. No mastodon.yml, adicione um novo processo sidekiq com queues: [relay] e sua própria concorrência. Isso impede que trabalhos do relay bloqueiem o envio de e-mails ou notificações push.

Não Monitorar a Latência das Filas Após as Alterações

Alterar a contagem de workers sem verificar a latência das filas pode esconder problemas. Acesse a interface de administração do Mastodon em https://seu-dominio-relay/admin/sidekiq/queues. Observe a coluna de latência para as filas default e relay. Se a latência permanecer acima de 30 segundos após 10 minutos, aumente a concorrência em mais 2 workers. Se a latência for zero e o uso da CPU estiver abaixo de 50 por cento, você pode reduzir a concorrência ligeiramente para economizar memória.

Comparação de Contagem de Workers Sidekiq: Relay Pequeno vs Relay Grande

Item	Relay Pequeno (2-4 GB RAM)	Relay Grande (8-16 GB RAM)
Concorrência recomendada	5 a 10	15 a 30
RAM reservada para SO e web	1024 MB	2048 MB
Estimativa de RAM por worker	200 MB	200 MB
Meta de latência típica da fila	Abaixo de 30 segundos	Abaixo de 10 segundos
Processos Sidekiq	1 processo compartilhado	2 processos: um para default+push, outro para relay

Ajustar corretamente os workers Sidekiq para seu relay Mastodon mantém a federação rápida e os recursos do servidor estáveis. Comece com a fórmula de memória para encontrar uma concorrência máxima segura. Aplique a alteração através do mastodon.yml ou da variável de ambiente Docker. Monitore a latência das filas e o uso de memória após a alteração e ajuste em pequenos incrementos. Para um relay de alto tráfego, considere dividir a fila relay em seu próprio processo Sidekiq para evitar gargalos em outras filas. Essa abordagem fornece um relay confiável que lida com altos volumes sem travar.