Quanta memória RAM para um VPS: a regra, uso por uso

A regra: somar o que fica em memória

Um servidor não consome memória “em geral”: cada programa em execução reserva uma parte dela enquanto roda. O cálculo parte, portanto, da lista dos processos presentes o tempo todo e depois acrescenta o pico e uma margem:

Memória a prever = (sistema + serviços permanentes + pico das tarefas pontuais) × 1,25

• O sistema: uma distribuição Linux mínima (Debian, Ubuntu) ocupa algo entre 150 e 300 MB depois de iniciada, com acesso SSH e registro de logs.
• Os serviços permanentes: servidor web, processos da aplicação, banco de dados, cache, fila de tarefas. O consumo depende da tecnologia, detalhada na próxima seção.
• O pico: o que se soma em certos momentos, como o build de uma aplicação, um backup, uma importação ou uma tarefa agendada pesada. Um servidor dimensionado pela média cai justamente nesses momentos.
• A margem: 25% acima do total, para o crescimento dos dados e do tráfego. Ela não fica parada: o Linux usa a memória livre como cache de arquivos, o que acelera o banco de dados.

O que cada componente consome

As ordens de grandeza abaixo valem para uma aplicação de porte comum, medida em produção. Elas dão um ponto de partida; a medição em sua própria aplicação, descrita mais adiante, sempre tem a última palavra.

Um pico aparece com frequência nas aplicações JavaScript: o build. npm run build em um projeto Next.js, Nuxt ou Angular costuma pedir 1 a 2 GB sozinho, durante alguns minutos, além do que já está rodando. Fazer o build no servidor é dimensionar para esse pico; fazer o build em seu computador ou em sua integração contínua e enviar só o resultado é evitá-lo.

O mesmo raciocínio vale para os contêineres Docker: cada contêiner é um conjunto de processos como os outros, e o daemon do Docker acrescenta o próprio consumo. docker stats mostra quanto cada um ocupa.

Perfis típicos

Estes perfis somam os componentes anteriores, pico e margem incluídos. Eles supõem uma aplicação de porte comum e o tráfego de um lançamento; um banco de dados volumoso ou um tráfego alto e constante empurram o número para cima.

Uma aplicação que chama um modelo de IA por API (OpenAI, Anthropic, Mistral) se dimensiona como qualquer aplicação web: o modelo roda no fornecedor, e seu servidor aguarda a resposta. É a execução do modelo no próprio servidor que muda a escala.

Medir em um servidor que está rodando

Em um servidor em produção, a medição substitui a estimativa. Três comandos mostram onde você está:

free -h
ps aux --sort=-rss | head -n 15
vmstat 5 5

• free -h: leia a coluna available, a memória realmente disponível para iniciar novos programas. A coluna free quase sempre está baixa, e isso é normal: o Linux preenche a memória não usada com o cache de arquivos (buff/cache), que ele devolve assim que um programa precisa.
• ps aux --sort=-rss: os processos ordenados pela memória ocupada (coluna RSS, em kilobytes). É aqui que se vê quanto pesa cada worker PHP ou Node.js.
• vmstat 5 5: cinco leituras com cinco segundos de intervalo. Valores diferentes de zero nas colunas si e so, leitura após leitura, indicam um servidor que troca páginas com o swap: falta memória.

Meça no horário de maior carga do dia, e durante as tarefas pontuais: build, backup, importação. O que conta é o pico.

Quando a memória acaba

Um servidor sem memória não fica lento aos poucos. Quando não há mais nada a liberar, o kernel Linux aciona o OOM killer (out of memory): ele escolhe um processo, em geral o que ocupa mais memória, e o encerra na hora. Em um servidor de aplicação, muitas vezes é o banco de dados.

Os sintomas: erros 502 ou 503 de vez em quando, um serviço que reinicia sem motivo aparente, um build que para com Killed. Os logs confirmam:

journalctl -k | grep -i "out of memory"
systemctl status nome-do-servico

Na saída do systemctl status, a mensagem Failed with result 'oom-kill' indica um serviço encerrado por falta de memória.

O swap, quando o servidor tem, adia esse momento transferindo para o disco a memória menos usada. Ele serve de rede de segurança, não de capacidade: um servidor que depende do swap o tempo todo responde várias vezes mais devagar, mesmo em um SSD NVMe.

As soluções, da mais simples à mais duradoura: reduzir o número de processos da aplicação (pm.max_children, workers do Gunicorn), fazer o build fora do servidor, limitar a memória do banco de dados e, depois, passar para um tamanho superior.

Escolher o tamanho e planejar o futuro

1. Liste o que vai rodar: servidor web, aplicação e número de processos, banco de dados, cache, tarefas agendadas.
2. Some com a tabela de componentes, acrescente o pico mais pesado (muitas vezes o build) e, depois, 25% de margem.
3. Fique com o tamanho que cobre esse total. Entre dois tamanhos vizinhos, o menor serve, desde que a passagem para o tamanho superior aconteça sem reinstalação.
4. Meça depois de entrar no ar, no pico do dia, e de novo a cada etapa de crescimento da aplicação.

A memória não é o único recurso: o processador conta para o que calcula (build, processamento de imagens, execução de um modelo de IA), o disco para o banco de dados e os arquivos. Em uma aplicação web, porém, é quase sempre a memória que define o tamanho.