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.
| Componente | Orçamento | Suposição |
|---|---|---|
| Host e ferramentas | 512 MiB | SO, proxy, telemetria |
| Dois processos de API | 768 MiB | 384 cada no pico presumido |
| Um worker de exportação | 512 MiB | Lotes limitados |
| Banco de dados | 1,024 MiB | Trabalho de cache e consulta |
| Sobreposição de versões | 512 MiB | Trabalho antigo e novo coexistem |
| Margem não alocada | 512 MiB | Incerteza a investigar |
| Suposição total | 3,840 MiB | Compare 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.