6 MESES ADIANTADO −28% · 1 ANO ADIANTADO −50%Comparar planos
PrivacyNodes
PLANEJAMENTO DE RECURSOS

Dimensionar um VPS SaaS a partir de um orçamento de carga de trabalho

Comece com os processos que devem coexistir, incluindo implantação e manutenção. Escolha um perfil de recursos após comparar esse orçamento combinado com uma carga de trabalho representativa. Uma contagem de visitantes sozinha não pode dizer quanta capacidade de VPS seu SaaS precisa.

notas de engenharia PrivacyNodes · Revisado · 3 min de leitura

Nomeie o trabalho antes de escolher o host

Desenhe o caminho da solicitação: proxy reverso, processo da API, banco de dados e serviços externos. Adicione o caminho assíncrono: fila, worker e destino de exportação. Registre quais componentes compartilham o host, quem controla a concorrência e quais dados devem sobreviver a uma reconstrução. Você precisa de métricas de aplicação e uma carga de trabalho não produtiva com dados representativos; este guia não pressupõe uma instância PrivacyNodes provisionada.

Para uma API de relatórios ilustrativa, uma solicitação HTTP lê configurações da conta e enfileira uma exportação. O worker varre linhas e grava um arquivo. Uma resposta rápida de enfileiramento não prova que a exportação pode terminar durante o tráfego de pico. Inclua limpeza agendada e sobreposição de implantação no plano de teste.

Inclua a sobreposição na planilha de memória

Estes são insumos hipotéticos de planejamento em MiB, não medições ou promessas sobre PrivacyNodes. Substitua-os por requisitos de aplicação observados. RSS inclui mapeamentos compartilhados residentes; somar o RSS de cada processo pode contar a memória duas vezes. A memória disponível do host é mais útil do que tratar todo o cache do sistema de arquivos como permanentemente indisponível.

Referência técnica: Linux contabilização de memória do processo.

Orçamento de memória ilustrativo no mesmo host
ComponenteOrçamentoSuposição
Host e ferramentas512 MiBSO, proxy, telemetria
Dois processos de API768 MiB384 cada no pico presumido
Um worker de exportação512 MiBLotes limitados
Banco de dados1,024 MiBTrabalho de cache e consulta
Sobreposição de versões512 MiBTrabalho antigo e novo coexistem
Margem não alocada512 MiBIncerteza a investigar
Suposição total3,840 MiBCompare com a memória real do host

Isso está muito próximo de um envelope nominal de 4 GB para assumir capacidade confortável. Verifique a memória real relatada pelo host e se os picos se sobrepõem. Reduza a concorrência, mova um componente ou adicione memória; não remova a reserva apenas para fazer a tabela caber.

PostgreSQL work_mem é uma margem por operação, não um limite total do banco de dados. Sessões e operações simultâneas podem multiplicar seu efeito. Contêineres Docker não têm restrições de CPU ou memória por padrão; uma imagem não é uma política de recursos.

Referência técnica: Consumo de recursos do PostgreSQL · Restrições de recursos do Docker.

Meça a CPU junto com a idade da fila

Exercite uma solicitação comum, o relatório útil mais lento, uma dependência com falha e uma exportação juntos. Registre percentis de latência, erros, CPU do host, concorrência do worker e idade do trabalho mais antigo no mesmo intervalo. Pressão de CPU com crescimento da fila sugere uma ação diferente de CPU baixa com longa espera no banco de dados.

Inicie o exemplo com uma exportação em andamento. Se o worker espera por armazenamento externo, CPU extra pode mudar pouco. Se ele saturar repetidamente um núcleo enquanto a latência da API aumenta, teste um lote de exportação menor ou um orçamento de worker separado. Altere um fator e repita o mesmo cenário antes de comprar capacidade.

Orce a próxima operação de manutenção

Liste arquivos e índices de banco de dados, uploads, logs, exportações temporárias, artefatos de versão e espaço livre para manutenção. Registre o crescimento por semana e quando sua reserva seria esgotada. Um conjunto de dados de 20 GB mais uma cópia temporária de 20 GB precisa de mais de 20 GB, mesmo quando o tráfego comum da aplicação está quieto.

Atribua rotação de logs e expiração de exportações. Mantenha cópias de recuperação fora do limite de falha do host. Armazenamento extra de VPS expande a alocação de trabalho; uma cópia nesse mesmo disco não é um backup independente. Teste tanto a operação normal quanto uma versão em execução junto com um backup ou exportação.

Escreva uma decisão que possa ser revisitada

Sua saída é uma planilha, uma descrição de carga de trabalho e um gatilho de revisão: idade crescente do trabalho mais antigo durante o teste representativo, espaço de manutenção encolhendo ou uma versão que não pode coexistir com os processos atuais. Registre observações em vez de inventar um limite percentual universal de CPU.

Compare App 2 e Scale 4 contra essas restrições. Se o resultado ainda surpreendê-lo, siga uma solicitação lenta pela pilha. Este exercício estima sua carga de trabalho; não estabelece referência de fornecedor, capacidade de tráfego ou disponibilidade.

Referências oficiais

A documentação foi revisada para este artigo. Os exemplos são exercícios de planejamento, não comandos testados em um servidor PrivacyNodes. Verifique a documentação da sua versão instalada.