De quanta RAM precisa realmente para servidores e VPS em 2025?

O dimensionamento da RAM é uma questão de cálculo da carga de trabalho, não um benchmark. Se gastar mais do que o necessário, pagará por capacidade ociosa. Se ficar aquém do necessário, os seus processos serão interrompidos, a sua base de dados será servida a partir do disco em vez da memória, ou os seus contentores serão limitados. Este guia apresenta intervalos concretos de RAM para as cargas de trabalho que observamos com mais frequência (alojamento web, bases de dados, virtualização, contentores, inferência de IA e servidores de jogos), além das regras a seguir ao dimensionar algo que não conste da lista.

O que a RAM faz num servidor

A RAM armazena tudo aquilo em que o servidor está ativamente a trabalhar. Memória de processos para servidores web, motores de bases de dados e daemons em segundo plano. Cache de páginas ao nível do sistema operativo e buffers de E/S de disco. Memória de execução para aplicações e contentores. E os blocos de memória atribuídos a máquinas virtuais ou cargas de trabalho de contentores.

O que distingue o dimensionamento da RAM do dimensionamento da CPU é o modo de falha. Se a CPU ficar sem recursos, os processos abrandam. Se a RAM ficar sem recursos, o kernel ou recorre ao swap (o que é lento) ou o «OOM killer» escolhe uma vítima e encerra-a. A primeira situação é desagradável. A segunda opção resulta na perda de dados. Provisionar RAM com margem não é um luxo, é o que impede que o sistema entre em colapso sob carga.

RAM por carga de trabalho

Servidores web e de aplicações

• Pilha LAMP ou LEMP leve: 1 a 2 GB
• WordPress ou CMS com cache (por exemplo, Redis): 2 a 4 GB
• Comércio eletrónico (Magento, WooCommerce): 4 a 8 GB
• Aplicações Node.js, Django ou Rails: 2 a 6 GB

Camadas de cache como o Redis ou o Varnish requerem memória RAM própria, para além da memória de base da aplicação. Os workers do PHP-FPM, as ligações à base de dados e os proxies reversos consomem todos memória em simultâneo; por isso, o valor que importa é o paralelismo de pico, e não a pegada em modo inativo.

Servidores de bases de dados (SQL e NoSQL)

• MySQL ou PostgreSQL (pequeno): 4 a 8 GB
• MySQL ou PostgreSQL (grande ou de elevado tráfego): 16 a 64 GB
• MongoDB ou Redis (focados na memória): 32 a 128 GB ou mais
• Nós do Elasticsearch ou OpenSearch: 32 a 128 GB por nó

O objetivo é manter o conjunto de trabalho, os índices e as linhas acedidas com frequência na RAM. Assim que qualquer um desses elementos for transferido para o disco, a latência multiplica-se por ordens de magnitude, independentemente da velocidade do SSD.

Hosts de virtualização (Proxmox, VMware, Hyper-V)

• Máquinas virtuais Linux leves: 2 a 4 GB por máquina virtual
• Máquinas virtuais Windows: 8 a 12 GB por máquina virtual
• Painéis de alojamento (cPanel, Plesk, DirectAdmin): 4 a 8 GB por instância
• Hosts de contentores KVM ou LXC: 32 a 128 GB ou mais

Reserve sempre 4 a 8 GB para o próprio sistema operativo do anfitrião, para além das alocações dos convidados. Os contentores utilizam menos RAM por carga de trabalho do que as máquinas virtuais completas, mas escalam de forma diferente; por isso, planeie com base na densidade e na margem de picos de utilização, em vez de no tamanho por contentor. Se o anfitrião utilizar ZFS, tenha também em conta o ARC, que, por predefinição, ocupará silenciosamente até metade da RAM do sistema e entrará em concorrência com as alocações dos convidados (o nosso guia de ajuste do ZFS ARC aborda os limites adequados para cargas de trabalho do hipervisor).

Contentores e microsserviços (Docker, Kubernetes)

• Pilhas simples do Docker (web, aplicação, base de dados): 8 a 16 GB
• Nós de borda do Docker Swarm ou K3s: 16 a 32 GB
• Nós de trabalho do Kubernetes: 32 a 128 GB
• Executores de CI/CD e agentes de compilação (GitLab, Jenkins): 8 a 32 GB por executor

Esteja atento a fugas de memória em contentores de execução prolongada. Cargas de trabalho baseadas em JVM, como o Kafka e o Elasticsearch, requerem valores de referência mais elevados, uma vez que a pilha (heap) ocupa todo o espaço que lhe for permitido, o que, frequentemente, é mais do que o esperado.

Inferência de IA e ML

• Modelos pequenos (BERT quantizado, Llama 7B): 16 a 32 GB
• Modelos médios (13B a 30B, quantizados): 64 a 128 GB
• Modelos grandes (40B+ ou de gama média não quantizados): 128 a 512 GB ou mais
• Inferência suportada por GPU (Stable Diffusion, Whisper): 32 a 128 GB, dependendo da descarregamento

A quantização transfere a pressão sobre a memória da GPU para a RAM da CPU, pelo que as especificações do sistema variam significativamente consoante se utilize fp16 na GPU ou 4 bits na CPU. O tamanho do lote e o comprimento do prompt também aumentam estes valores. O nosso guia sobre alojamento de inferência de IA aprofunda a questão da correspondência entre o hardware e o tamanho do modelo.

Servidores de jogos

• Minecraft (versão padrão): 2 a 4 GB
• Minecraft (modificado): 6 a 16 GB
• Rust, ARK ou 7 Days to Die: 8 a 16 GB
• Nós de alojamento multi-instância: 32 a 64 GB

Cargas de trabalho especializadas

• Transcodificação de vídeo (FFmpeg, Plex): 16 a 64 GB
• Servidores de cópias de segurança ou instantâneos: 8 a 16 GB, mais se estiverem a executar motores de deduplicação
• Firewall ou IDS (pfSense, Suricata): 2 a 8 GB, mais para NetFlow ou registo completo de pacotes

Não confie na memória swap

A memória swap é 10 a 100 vezes mais lenta do que a RAM. Existe como uma rede de segurança para que o kernel tenha para onde recorrer quando a pressão sobre a memória atinge picos, e não como uma forma de ampliar a memória utilizável. Se um servidor estiver a recorrer à memória swap sob carga normal, significa que está com recursos insuficientes, ponto final. O artigo «Como a memória swap do Linux, o OOM killer e os cgroups interagem» aborda os modos de falha em pormenor.

Como dimensionar a RAM com precisão

1. Meça o pico, não a média. Utilize htop, free -m, vmstat 1ou as suas métricas do Kubernetes para identificar o pico de utilização ao longo de um ciclo completo de tráfego. Os picos diários, os lotes semanais e os ciclos de faturação mensais são todos importantes.
2. Adicione margem para crescimento. 20% a 50% para o dimensionamento de aplicações. Para bases de dados, dimensione a memória de acordo com o tamanho do conjunto de dados, não com a taxa de pedidos. Para plataformas multi-tenant, calcule a pegada por cliente e multiplique.
3. Planeie tendo em conta o modo de falha que pode tolerar. Uma réplica de leitura com falta de RAM fica com o desempenho reduzido. Um banco de dados primário com falta de RAM corrompe as consultas e pode derrubar as aplicações consigo. Aloque a RAM onde o impacto for maior.

A RAM é a especificação em que a falta de memória prejudica mais do que o excesso. Adicionar memória não tornará mais rápida uma aplicação limitada pela CPU, mas uma configuração demasiado reduzida destrói a estabilidade. Determine a capacidade com base na monitorização real e nos picos testados, e depois deixe margem.

A FDC oferece servidores dedicados e VPS com configurações de RAM elevada e largura de banda ilimitada em várias regiões.