Como Configurar o Ajuste do Postgres para uma Instância Movimentada do Mastodon

Se sua instância do Mastodon fica lenta nos horários de pico ou retorna erros de timeout no banco de dados na interface web, a configuração padrão do PostgreSQL provavelmente é a culpada. O Mastodon depende muito de consultas ao banco para timelines, notificações e busca. As configurações padrão do Postgres são projetadas para uma aplicação web típica, não para uma rede social federada que pode atender milhares de requisições simultâneas. Este artigo explica como ajustar os principais parâmetros do Postgres para lidar com um servidor Mastodon movimentado. Você aprenderá quais configurações alterar, quais valores usar com base no hardware do servidor e como aplicá-los com segurança.

Por que o Mastodon Precisa de Configurações Personalizadas do Postgres

O Mastodon usa PostgreSQL como armazenamento principal para contas, status, seguidores e anexos de mídia. O guia oficial de instalação do Mastodon vem com configurações padrão do Postgres que assumem pouca carga. Em uma instância movimentada com centenas ou milhares de usuários ativos, o banco de dados se torna o gargalo.

O Mastodon gera muitas consultas ao banco por carregamento de página. A timeline inicial, por exemplo, requer uma junção entre status, seguidores e reblogs. A timeline federada puxa status remotos e precisa filtrar domínios bloqueados. Essas consultas se beneficiam de caches de memória maiores e paralelismo mais agressivo.

O valor padrão de shared_buffers no Postgres costuma ser 128 MB. Um servidor com 16 GB de RAM pode dedicar facilmente 4 GB ao cache do banco de dados. Sem essa alteração, o Postgres lê do disco repetidamente, causando alta latência de I/O e renderização lenta de páginas.

Outras configurações padrão como work_mem (4 MB) fazem com que as consultas de busca e filtro do Mastodon usem arquivos temporários em disco. Isso adiciona latência. Ajustar esses valores reduz o uso de CPU e melhora os tempos de resposta para todos os usuários.

Como o Ajuste do Postgres Afeta o Mastodon

Quando o Postgres tem memória suficiente, ele mantém dados acessados com frequência na RAM. As consultas de timeline do Mastodon se tornam muito mais rápidas porque o banco não precisa buscar dados do disco. O planejador de consultas também toma melhores decisões quando sabe quanta cache está disponível.

O ajuste também afeta jobs em segundo plano. O Mastodon usa Sidekiq para tarefas como fan-out, processamento de mídia e notificações push. Esses jobs frequentemente executam consultas ao banco. Um Postgres bem ajustado reduz o tempo que os workers do Sidekiq esperam por resultados do banco.

Passos para Ajustar a Configuração do Postgres para o Mastodon

1. Localize o arquivo de configuração do Postgres
   O arquivo principal é postgresql.conf. Em sistemas Ubuntu ou Debian, geralmente está em /etc/postgresql/14/main/postgresql.conf. Substitua 14 pela versão do seu Postgres. Use sudo nano /etc/postgresql/14/main/postgresql.conf para editá-lo.
2. Defina shared_buffers como 25% da RAM total
   Encontre a linha shared_buffers = 128MB e altere-a. Para um servidor com 16 GB de RAM, defina shared_buffers = 4GB. Para 32 GB de RAM, defina shared_buffers = 8GB. Não ultrapasse 8 GB em sistemas com menos de 8 GB de RAM total.
3. Aumente effective_cache_size para 75% da RAM
   Encontre #effective_cache_size = 4GB. Descomente e defina como 75% da sua RAM. Para 16 GB de RAM, use effective_cache_size = 12GB. Isso informa ao planejador de consultas quanta memória o sistema operacional usa para cache de arquivos.
4. Aumente work_mem para ordenação e filtragem
   Encontre #work_mem = 4MB. Altere para work_mem = 16MB. Esse valor se aplica por operação de consulta. Em um servidor com muitas consultas concorrentes, não exceda 32 MB. Um valor muito alto pode esgotar a memória sob carga pesada.
5. Defina maintenance_work_mem para operações VACUUM
   Encontre #maintenance_work_mem = 64MB. Altere para maintenance_work_mem = 1GB. Isso acelera o processo VACUUM que o Postgres executa automaticamente para recuperar espaço. Instâncias do Mastodon geram muitos status e reblogs excluídos, então o VACUUM é executado com frequência.
6. Ajuste max_worker_processes e max_parallel_workers
   Encontre #max_worker_processes = 8. Defina como o número de núcleos de CPU do seu servidor. Para um servidor com 4 núcleos, use max_worker_processes = 4. Em seguida, defina max_parallel_workers = 4 e max_parallel_workers_per_gather = 2. Isso permite que o Postgres use vários núcleos para consultas executadas pelo Mastodon, como agregação da timeline federada.
7. Reinicie o PostgreSQL
   Após salvar o arquivo, reinicie o Postgres com sudo systemctl restart postgresql. Em seguida, monitore os logs do Mastodon usando journalctl -u mastodon-web -f para confirmar que nenhum erro aparece.

Erros Comuns ao Ajustar o Postgres para o Mastodon

Definir shared_buffers Acima de 40% da RAM

Quando shared_buffers excede 40% da RAM total, o Postgres compete com o cache de arquivos do sistema operacional. Isso pode realmente desacelerar as consultas porque o SO não consegue armazenar em cache os arquivos do banco de forma eficiente. Mantenha-se em 25% para a maioria das instâncias do Mastodon.

Esquecer de Reiniciar Após as Alterações

O Postgres lê a configuração apenas na inicialização. Se você editar o postgresql.conf e não reiniciar o serviço, as alterações não terão efeito. Sempre execute sudo systemctl restart postgresql após modificar o arquivo.

Ignorar os Limites de Conexão

O Mastodon usa um pool de conexões (geralmente PgBouncer) para gerenciar conexões com o banco. Se você aumentar o max_connections do Postgres sem ajustar o pool, ainda poderá ver erros de conexão. Mantenha max_connections em 200 ou menos e confie no PgBouncer para concorrência.

Não Monitorar Após as Alterações

Após aplicar as novas configurações, observe os logs do banco e o desempenho do Mastodon. Use htop para verificar o uso de CPU e memória. Se o uso de memória ficar próximo de 100%, reduza shared_buffers ou work_mem. Use pg_stat_statements para identificar consultas lentas.

Parâmetros de Ajuste do Postgres: Padrão vs Recomendado para o Mastodon

Parâmetro	Valor Padrão	Recomendado para 16 GB RAM
shared_buffers	128 MB	4 GB
effective_cache_size	4 GB	12 GB
work_mem	4 MB	16 MB
maintenance_work_mem	64 MB	1 GB
max_worker_processes	8	4

Os valores escalam com o tamanho da RAM. Para 32 GB de RAM, dobre shared_buffers para 8 GB e effective_cache_size para 24 GB. Mantenha work_mem em 16 MB a menos que você tenha menos de 50 conexões concorrentes.

Agora você pode ajustar o Postgres para sua instância movimentada do Mastodon usando os parâmetros deste guia. Comece editando o postgresql.conf e ajustando shared_buffers, effective_cache_size e work_mem. Reinicie o Postgres e monitore o desempenho com htop e o painel de administração do Mastodon. Para otimização adicional, ative o pg_stat_statements para rastrear as consultas mais lentas e ajustar os índices conforme necessário.