«O servidor está lento, vamos dobrar a RAM» é o reflexo mais caro da hospedagem. Às vezes acerta. Muitas vezes a máquina está esperando o disco, ou a CPU está no talo, e a memória nova fica parada enquanto a conta dobra.
Então, antes de falar de quem precisa de 64 GB, vamos descobrir o que realmente está faltando. Se você só quer números típicos de memória por tipo de carga, eles estão no nosso guia anterior Quanta RAM um VPS precisa, incluindo a fórmula para modelos de linguagem. Este artigo é sobre diagnóstico: RAM, disco ou CPU.
Três comandos, dois minutos
Rode no servidor lento enquanto ele está lento, não às quatro da manhã quando nada acontece:
free -m
vmstat 1 10
cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io
Veja como ler sem manual.
free -m. Ignore a coluna free; o Linux enche a memória sobrando com cache de disco de propósito. Olhe para available. Se numa máquina de 2 GB ela mostra só algumas centenas de megabytes e o used do swap não para de subir, a memória está apertada.
vmstat 1 10. Quatro colunas contam quase toda a história:
| Coluna | O que significa | Aponta para |
|---|---|---|
si / so | páginas entrando e saindo do swap por segundo | RAM |
wa | % do tempo em que a CPU espera pelo disco | disco |
us + sy | % do tempo em que a CPU está trabalhando | CPU |
st | % do tempo em que o hipervisor deu a sua CPU para outra pessoa | CPU (vCPU dividida com outros) |
Alguns valores diferentes de zero em si/so de vez em quando são normais. O sinal de verdade é swap constante, segundo após segundo.
/proc/pressure/*. O mais honesto dos três. Cada arquivo mostra a fração do tempo em que tarefas ficaram travadas esperando aquele recurso. some avg60=25.00 em memory quer dizer que, no último minuto, algo ficou esperando memória um quarto do tempo. O arquivo com os números mais altos é o seu gargalo.
Se for o disco
wa alto, pressão de io alta, pouco swap. A causa comum é um banco de dados ou uma aplicação cheia de logs lendo mais do que cabe no cache.
Aqui vem a reviravolta: mais RAM pode resolver, porque o Linux vai colocar mais do disco em cache. Se o seu banco tem 6 GB e a parte quente tem 3 GB, passar de 2 GB para 8 GB de memória pode fazer o problema de disco sumir. Mas se o banco tem 300 GB e cada consulta toca uma parte diferente, nenhuma quantidade razoável de RAM vai colocá-lo em cache. Aí a solução é ter índices melhores, consultas menores ou outra organização dos dados. Todos os planos aqui rodam em NVMe, então o disco em si raramente é a parte lenta. O padrão de acesso, quase sempre é.
Se for a CPU
us+sy altos, pressão de cpu, sem swap, pouca espera de disco. Compressão, builds, codificação de vídeo, processamento de imagem, cálculo criptográfico. Mais memória não ajuda em nada.
Fique de olho também no st. Num VPS, uma vCPU é uma fatia do tempo de um núcleo físico, não o núcleo inteiro: o número do plano é um teto para picos, e carga cheia por muito tempo pode ser limitada para ficar justo com todos na máquina. Se o seu trabalho precisa de todos os núcleos a 100% por horas, isso é uma questão da carga, e preferimos dizer agora do que depois de você comprar um plano maior.
Se for mesmo a RAM
Swap constante, pressão de memória subindo, o OOM killer no dmesg. Agora a pergunta é: quanto.
2 GB bastam, muitas vezes por anos, para: um ou alguns bots, uma API pequena, uma VPN, um site estático atrás do Nginx, alguns scrapers no cron, um agente de monitoramento. O Micro dá 2 vCPU, 2 GB e 25 GB por US$ 5 por mês em NAT, ou US$ 10 com IPv4 próprio.
4–8 GB é o meio-termo confortável: uma aplicação web com o banco, um índice de busca pequeno, automação de navegador headless, dois ou três agentes lado a lado.
32–64 GB é para dados que precisam viver na memória:
- um banco de dados cujo conjunto de trabalho tem dezenas de gigabytes, para que o cache segure de fato os dados quentes;
- um cache ou fila grande em memória que não pode ir para o disco sem deixar tudo mais lento;
- um índice vetorial para busca em milhões de trechos (números reais em RAG auto-hospedado em grande escala);
- inferência em CPU de um modelo de linguagem de porte médio, em que os pesos têm que caber na RAM;
- consolidação: dez serviços que antes moravam em dez servidores pequenos.
É para isso que existe o Pro-64: 12 vCPU, 64 GB de RAM, 600 GB de NVMe e um IPv4 dedicado por US$ 70 por mês. Os degraus intermediários são o Pro-32 por US$ 40 e o Pro-48 por US$ 55; acima, o Pro-80 por US$ 90. A disponibilidade de localizações para os planos Pro aparece no pedido.
Onde uma máquina grande não serve
Três casos em que 64 GB é a resposta errada, mesmo que caiba no bolso.
Trabalho em GPU. Nenhum desses planos tem GPU. Se o seu modelo precisa de uma para treinar ou para inferência rápida, uma máquina de CPU com muita RAM vai rodá-lo, devagar, e você vai pagar pela paciência.
Trabalhos com CPU cheia por muito tempo. Como dito acima: vCPUs são capacidade para picos. Doze delas a 100% o dia todo não é para isso que um VPS foi feito.
E o «vai que precisa». Se os três comandos não mostram pressão de memória, os 60 GB extras viram cache de arquivos que você não lê. Comece menor. Passar para um plano maior do mesmo tipo de rede adiciona vCPU, RAM e disco no lugar, com uma reinicialização, como explica Mudar de plano. Diminuir no lugar não dá, então comprar grande demais tem custo real: para encolher, você migra para um servidor novo, e mudar um VPS sem tempo fora do ar é um trabalho que você preferiria evitar.
Se você está comparando planos de provedores diferentes, como ler as especificações de um VPS explica o que os números de vCPU, disco e porta realmente prometem.
Comentários
Nenhum comentário ainda. Seja o primeiro.