Dimensione o aplicativo que você realmente executa.

Antes de medir

Use uma máquina de teste Linux que você controla, com seu aplicativo e dados representativos. Os comandos abaixo inspecionam recursos; eles não ajustam o kernel nem excluem arquivos. Você precisa do procps e do GNU coreutils, e de permissão para inspecionar o diretório do aplicativo escolhido. Substitua /srv/my-app pelo seu caminho real. Se o app ainda não estiver em execução em lugar algum, use seu ambiente de desenvolvimento ou staging para construir uma estimativa inicial e depois revise essa estimativa no sistema pretendido.

Anote o que compartilha o VPS: sistema operacional, proxy, API, banco de dados, workers e monitoramento. Registre se builds de assets são executados ali, se backups são comprimidos localmente e se uma tarefa agendada pode sobrepor uma implantação. Um processo de aplicativo tranquilo pode coexistir com um processo de release caro.

Leia a memória disponível e identifique os processos

free -m
ps -eo pid,comm,rss --sort=-rss | head -n 12

free -m relata mebibytes. Foque em available, a estimativa de memória que poderia suportar novo trabalho sem swap; free sozinho exclui memória recuperável útil. O cache, portanto, não é, por si só, um motivo para comprar mais RAM. Veja as definições dos campos do free.

Illustrative selected fields — not an OffVPS measurement
Mem total: 2048 MiB
Mem free:   180 MiB
Mem available: 800 MiB

Illustrative ps rows
  PID COMMAND     RSS
 2100 postgres 393216
 2140 node     184320
  920 caddy     32768

Os valores de RSS dos processos acima correspondem aproximadamente a 384, 180 e 32 MiB. Eles ajudam a localizar o uso de memória, mas somar cada valor de RSS não é um total exato da máquina: páginas compartilhadas podem ser contadas mais de uma vez e alguns custos de kernel ficam fora da cifra do processo. Evite imprimir argumentos de comando ou ambientes ao coletar um relatório, pois eles podem conter segredos. O manual do ps explica seus campos e o comportamento de snapshot.

Transforme observações em uma planilha

As alocações a seguir ilustram uma pequena API com banco de dados local e um worker. São valores de planejamento inventados, não benchmarks nem requisitos mínimos para um framework específico. Substitua pelos seus measurements e observe quais alocações podem atingir pico ao mesmo tempo.

Esta planilha já excede um orçamento de 1,024 MiB. Um ambiente de teste de 2,048 MiB deixaria 676 MiB contra essas alocações, mas o resultado útil é se trabalho representativo real cabe enquanto o app permanece responsivo. Se a alocação de implantação dominar, construir artefatos em outro lugar pode ser uma mudança melhor do que ampliar o servidor permanente. Preserve as premissas ao lado do total.

Observe CPU e swap durante trabalho útil

vmstat 1 10

Execute isso durante um lote representativo de requisições, um job e um release. Ignore a primeira linha ao interpretar um intervalo recente: ela resume a atividade desde o boot. As linhas seguintes descrevem os intervalos de amostragem. Trabalho executável persistente em r, baixo tempo ocioso em id e requisições lentas juntos justificam investigar a pressão de CPU. si/so repetido mostra swapping; swap alocado sozinho não prova pressão atual. wa e st precisam de contexto em vez de um upgrade automático de CPU. Esses campos são definidos em vmstat.

Registre também o tempo de resposta no aplicativo. Uma API externa lenta ou uma consulta ao banco de dados pode fazer as requisições esperarem enquanto a CPU permanece majoritariamente ociosa. Repita a mesma carga de trabalho após uma mudança, para que você saiba qual mudança ajudou. Testes de carga devem mirar apenas sistemas que você controla, com uma taxa e condição de parada que evitem perturbar outros usuários.

Orce o crescimento de disco e a transferência separadamente

df -h /srv/my-app
df -i /srv/my-app
du -sh /srv/my-app

df descreve o sistema de arquivos que contém o caminho, incluindo espaço compartilhado com outros diretórios; df -i verifica o uso de inodes onde houver suporte. Um grande número de arquivos pequenos pode esgotar inodes antes da capacidade em bytes. du estima a árvore escolhida, sujeito às permissões de acesso. São perguntas diferentes, então seus totais não precisam coincidir. Veja df e du.

Liste o banco de dados atual, uploads, logs, artefatos da aplicação e qualquer espaço local de staging de backup. Adicione o espaço necessário para um release ao lado do release anterior e depois estime o crescimento ao longo do próximo intervalo de revisão. Por exemplo, 100 MiB de novos uploads por dia adicionam cerca de 3,000 MiB ao longo de 30 dias antes de réplicas ou backups. Rótulo GB decimal e GiB binário de forma consistente ao comparar o resultado com um catálogo.

Para transferência, uma resposta ilustrativa de 20 kB enviada 50,000 vezes é cerca de 1 GB de payload de resposta. Adicione uploads, arquivos estáticos, overhead de protocolo e tráfego de backup. Essa aritmética estima volume, não throughput nem usuários simultâneos. Confirme como o serviço conta o tráfego e lida com qualquer excesso.

Escolha a próxima ação e verifique-a

• Memória disponível baixa durante picos normais: inspecione os principais consumidores e teste um orçamento de memória maior.
• Requisições lentas com pressão de CPU sustentada: faça profiling do caminho ocupado e depois compare mudanças de CPU usando a mesma carga de trabalho.
• Uso crescente de disco: identifique o diretório responsável e a política de retenção antes de excluir qualquer coisa.
• Os recursos parecem confortáveis, mas o app está lento: investigue dependências, consultas e o caminho da requisição.

Salve a planilha com a descrição da carga de trabalho, o horário da amostra, as unidades e a próxima data de revisão. Verifique novamente após um release substancial, crescimento de dados ou um worker adicionado. Escolha uma configuração a partir dessas observações; nenhum nome de plano garante capacidade de requisições. Continue com ler avisos de memória e disco ou o primeiro cenário de recurso de API.