Escolher o hardware certo para uma instância Mastodon é um exercício de equilíbrio. Os três principais recursos — CPU, RAM e disco — lidam com diferentes partes da carga de trabalho, e sua importância muda conforme sua base de usuários cresce. Muitos administradores começam com um servidor virtual pequeno e descobrem que um recurso se torna um gargalo enquanto outros ficam ociosos. Este artigo explica como CPU, RAM e disco interagem na pilha do Mastodon, o que cada componente faz e como priorizar gastos no recurso certo para o número esperado de usuários e nível de atividade.
Principais Conclusões: Compensações no Dimensionamento de Recursos do Mastodon
- Núcleos de CPU para workers do Sidekiq: Cada thread de worker em segundo plano precisa de um núcleo de CPU para processar federação, mídia e notificações push sem atraso.
- RAM para PostgreSQL e Puma: O Mastodon depende de cache em memória e conexões de banco de dados — 4 GB é o mínimo para 10 usuários simultâneos, 16 GB para 100.
- IOPS de disco para armazenamento de mídia: SSDs NVMe reduzem a latência de gravação do banco de dados e o tempo de upload de mídia, enquanto HDDs causam timeouts sob carga moderada.
Como o Mastodon Usa CPU, RAM e Disco de Forma Diferente
O Mastodon é uma aplicação Ruby on Rails que usa um servidor web (Puma), um processador de tarefas em segundo plano (Sidekiq), um banco de dados (PostgreSQL), um cache (Redis) e um proxy de mídia. Cada componente tem um perfil de recursos distinto.
Carga de CPU: Sidekiq e Federação
O Sidekiq executa tarefas em segundo plano. Essas tarefas incluem buscar timelines remotas, processar atividades recebidas de outras instâncias, enviar notificações push, gerar miniaturas de mídia e excluir dados antigos. Cada processo do Sidekiq executa múltiplas threads, mas as threads compartilham o mesmo núcleo de CPU. Para federação pesada, você precisa de mais processos Sidekiq, o que significa mais núcleos de CPU. Um servidor com um único núcleo pode atender de 5 a 10 usuários ativos se a federação for leve. Para 50 usuários ativos, planeje 4 núcleos de CPU. O Puma também usa CPU para renderizar páginas web e respostas da API, mas sua carga é tipicamente menor que a do Sidekiq.
Carga de RAM: PostgreSQL e Redis
O PostgreSQL armazena todos os toots, contas, seguidores e metadados. O Mastodon gera consultas complexas para timelines e pesquisa. O PostgreSQL usa buffers compartilhados para armazenar dados em cache na RAM. Se o conjunto de trabalho de dados ativos — toots recentes de contas seguidas — couber na RAM, as consultas são rápidas. Caso contrário, o banco de dados lê do disco, o que é ordens de magnitude mais lento. O Redis armazena em cache dados de timeline e informações de sessão. O Redis é um armazenamento em memória; ele mantém dados acessados com frequência para reduzir a carga no banco de dados. Uma instância Redis com 1 GB de RAM é suficiente para 100 usuários ativos. O PostgreSQL normalmente precisa de 2 GB a 8 GB, dependendo do tamanho do conjunto de dados ativos.
Carga de Disco: Armazenamento de Mídia e Gravações do Banco de Dados
O desempenho do disco é importante por dois motivos: arquivos de mídia e logs de write-ahead do banco de dados. O Mastodon armazena imagens e vídeos enviados no diretório public/system. Cada toot com uma imagem grava um arquivo no disco. Quando um usuário rola sua timeline inicial, o Mastodon serve esses arquivos diretamente. Se você usar armazenamento de objetos compatível com S3, o desempenho do disco no servidor se torna menos crítico para mídia. O banco de dados ainda grava no disco para cada transação. Um disco lento aumenta o tempo que o PostgreSQL leva para confirmar gravações, o que pode causar timeouts de requisição. SSDs NVMe oferecem a menor latência. SSDs SATA são aceitáveis. HDDs não são recomendados para instâncias de produção com mais de 10 usuários.
Como Dimensionar Sua Instância Mastodon com Base no Número de Usuários
A tabela abaixo fornece alocações iniciais de recursos para diferentes escalas de usuários. Esses números assumem federação moderada — cerca de 200 instâncias remotas — e uso típico de mídia de 1 a 2 imagens por toot.
- Estime seus usuários simultâneos de pico
Usuários simultâneos são aqueles ativos na instância ao mesmo tempo, não o total de contas registradas. Uma proporção típica é 10% dos usuários registrados ativos no pico. Por exemplo, 100 contas registradas significam aproximadamente 10 usuários simultâneos. - Escolha o número de núcleos de CPU
Para até 10 usuários simultâneos: 2 núcleos de CPU. Para 10 a 50 usuários simultâneos: 4 núcleos de CPU. Para 50 a 200 usuários simultâneos: 8 núcleos de CPU. Acima de 200, escale horizontalmente executando múltiplos processos Sidekiq e Puma em servidores separados. - Escolha a quantidade de RAM
Para até 10 usuários simultâneos: 4 GB de RAM total (2 GB para PostgreSQL, 1 GB para Redis, 1 GB para sistema e Puma). Para 10 a 50 usuários simultâneos: 8 GB total. Para 50 a 200 usuários simultâneos: 16 GB total. Para 200 a 500 usuários simultâneos: 32 GB total. - Escolha o tipo e tamanho do disco
Use SSDs NVMe para qualquer instância com mais de 10 usuários simultâneos. SSDs SATA são aceitáveis para instâncias menores. Aloque 30 GB para o sistema operacional e a aplicação Mastodon. Adicione 100 MB por usuário registrado para armazenamento de mídia. Para 100 usuários registrados, são 10 GB de mídia, mais 30 GB de sistema = 40 GB total. Use armazenamento de objetos como S3 ou Wasabi para mídia acima de 50 GB para manter os custos de disco do servidor baixos. - Configure a concorrência do Sidekiq
Defina a concorrência do Sidekiq no arquivo .env.production. Um bom ponto de partida é 10 threads por processo Sidekiq. Execute um processo Sidekiq por núcleo de CPU. Para um servidor de 4 núcleos, execute 4 processos Sidekiq. Isso garante que as tarefas em segundo plano não se acumulem.
Erros Comuns de Dimensionamento e Compensações a Evitar
Comprar Mais CPU Quando o Gargalo São IOPS de Disco
Se sua instância parece lenta, mas o uso de CPU está abaixo de 50%, verifique o tempo de espera de I/O do disco usando o comando iostat. Uma alta porcentagem de espera de I/O significa que o disco não consegue acompanhar as requisições de leitura e gravação. Adicionar mais núcleos de CPU não ajudará. Atualize para um disco mais rápido — SSD NVMe — ou mova a mídia para armazenamento de objetos.
Alocar Muita RAM para Redis e Pouca para PostgreSQL
O Redis usa RAM de forma eficiente para seu cache, mas o PostgreSQL precisa de RAM para evitar leituras de disco. Se a taxa de acerto de cache do PostgreSQL cair abaixo de 99%, aumente a configuração shared_buffers. Um erro comum é dar 4 GB para Redis enquanto o PostgreSQL tem apenas 1 GB. O Redis raramente precisa de mais de 2 GB para uma instância pequena ou média. Realoque essa RAM para o PostgreSQL.
Usar um HDD para o Volume do Banco de Dados
Um disco rígido causa picos de latência de gravação no banco de dados sempre que ocorre uma liberação do log de write-ahead. Isso resulta em erros 500 para usuários publicando toots. Mesmo um HDD de 7200 RPM não consegue igualar o desempenho de I/O aleatório de um SSD SATA. Nunca use um HDD para o banco de dados ou o diretório da aplicação Mastodon. Use um HDD apenas para armazenamento frio de mídia raramente acessada, e mesmo assim, prefira armazenamento de objetos.
Ignorar a Memória para Workers do Sidekiq
Cada thread do Sidekiq consome cerca de 100 MB de RAM. Se você executar 4 processos Sidekiq com 10 threads cada, são 40 threads e aproximadamente 4 GB de RAM apenas para o Sidekiq. Se seu servidor tiver apenas 4 GB de RAM total, o sistema fará swap de memória para o disco, causando lentidão severa. Sempre considere a memória do Sidekiq ao dimensionar a RAM. Uma fórmula segura é: RAM total = 2 GB para sistema + 2 GB para PostgreSQL + 1 GB para Redis + (número de threads do Sidekiq 100 MB).
| Recurso | Instância Pequena (10 usuários simultâneos) | Instância Média (50 usuários simultâneos) |
|---|---|---|
| Núcleos de CPU | 2 | 4 |
| RAM | 4 GB | 8 GB |
| Tipo de disco | SATA SSD ou NVMe | NVMe SSD |
| Tamanho do disco | 40 GB (30 GB sistema + 10 GB mídia) | 80 GB (30 GB sistema + 50 GB mídia) |
| Processos Sidekiq | 2 | 4 |
| shared_buffers do PostgreSQL | 512 MB | 2 GB |
| maxmemory do Redis | 256 MB | 1 GB |
Agora você pode dimensionar uma instância Mastodon combinando CPU, RAM e disco com seu número esperado de usuários simultâneos. Comece com a alocação mínima recomendada e monitore o tamanho da fila do Sidekiq e a taxa de acerto de cache do PostgreSQL após o lançamento. Se você observar crescimento da fila acima de 100 tarefas ou uma taxa de acerto de cache abaixo de 99%, adicione primeiro o recurso que é gargalo. Para uma verificação rápida, execute htop para uso de CPU e RAM e iostat -x 1 para espera de I/O de disco. A atualização mais custo-benefício para uma instância lenta é quase sempre adicionar RAM ou mudar para um SSD NVMe, em vez de adicionar núcleos de CPU.