Quanta RAM para um VPS: a regra, caso a caso

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, enquanto estiver a correr. O cálculo parte, por isso, da lista dos processos presentes em permanência, 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 cerca de 150 a 300 MB depois de arrancar, com o acesso SSH e os registos incluídos.
• Os serviços permanentes: servidor web, processos da aplicação, base de dados, cache, fila de tarefas. O seu consumo depende da tecnologia, detalhada na secção seguinte.
• O pico: o que se soma em certos momentos, compilação de uma aplicação, cópia de segurança, importação, tarefa agendada pesada. Um servidor dimensionado pela média falha precisamente nesses momentos.
• A margem: 25 % acima do total, para o crescimento dos dados e do tráfego. Não fica parada: o Linux usa a memória livre como cache dos ficheiros, o que acelera a base de dados.

O que consome cada componente

As ordens de grandeza abaixo valem para uma aplicação de dimensão corrente, medida em produção. Dão um ponto de partida; a medição na sua própria aplicação, descrita mais abaixo, tem sempre a última palavra.

Um pico aparece muitas vezes com as aplicações JavaScript: a compilação. npm run build num projeto Next.js, Nuxt ou Angular pede habitualmente 1 a 2 GB só para si, durante alguns minutos, para além do que já está a correr. Compilar no servidor é dimensionar para esse pico; compilar no seu computador ou na sua integração contínua e enviar apenas o resultado é evitá-lo.

O mesmo raciocínio vale para os contentores Docker: cada contentor é um conjunto de processos como os outros, e o daemon do Docker acrescenta o seu próprio consumo. docker stats mostra o que cada um ocupa.

Perfis típicos

Estes perfis somam os componentes anteriores, com o pico e a margem incluídos. Pressupõem uma aplicação de dimensão corrente e o tráfego de um lançamento; uma base de dados volumosa ou um tráfego intenso fazem subir o valor.

Uma aplicação que chama um modelo de IA por API (OpenAI, Anthropic, Mistral) dimensiona-se como qualquer aplicação web: o modelo corre nos servidores do seu fornecedor, e o seu servidor espera pela resposta. É a execução do modelo no próprio servidor que faz mudar de escala.

Medir num servidor em funcionamento

Num servidor em produção, a medição substitui a estimativa. Três comandos dizem em que ponto 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 lançar novos programas. A coluna free está quase sempre baixa, e é normal: o Linux preenche a memória não utilizada com a cache dos ficheiros (buff/cache), que devolve assim que um programa precisa dela.
• 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 está a recorrer ao swap: falta-lhe memória.

Meça no momento de maior carga do dia, e durante as tarefas pontuais: compilação, cópia de segurança, importação. É o pico que conta.

Quando a memória falta

Um servidor sem memória não abranda progressivamente. Quando já não há nada para libertar, o kernel Linux aciona o OOM killer (out of memory): escolhe um processo, em geral o que ocupa mais memória, e termina-o de imediato. Num servidor aplicacional, é muitas vezes a base de dados.

Os sintomas: erros 502 ou 503 de vez em quando, um serviço que reinicia sem razão aparente, uma compilação que se interrompe com Killed. Os registos confirmam-no:

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

Na saída de systemctl status, a menção Failed with result 'oom-kill' identifica um serviço parado por falta de memória.

O swap, quando o servidor o tem, adia esse momento ao passar para o disco a memória menos utilizada. Serve de rede de segurança, não de capacidade: um servidor que se apoia no swap de forma contínua responde várias vezes mais devagar, mesmo num SSD NVMe.

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

Escolher o tamanho, e preparar o futuro

1. Liste o que vai correr: servidor web, aplicação e número de processos, base de dados, cache, tarefas agendadas.
2. Some com a tabela dos componentes, acrescente o pico mais pesado (muitas vezes a compilação), e depois 25 % de margem.
3. Escolha o tamanho que cobre esse total. Entre dois tamanhos vizinhos, o mais pequeno serve desde que a passagem ao tamanho superior se faça sem reinstalar.
4. Meça depois da entrada em produção, no pico do dia, e depois a cada etapa de crescimento da aplicação.

A memória não é o único recurso: o processador conta para o que faz cálculo (compilação, tratamento de imagens, execução de um modelo de IA), o disco para a base de dados e os ficheiros. Numa aplicação web, porém, é quase sempre a memória que define o tamanho.