Quanta memória e quantos núcleos um site precisa

Se o site ainda não está no ar e você não sabe quanto contratar, comece com 2 GB de memória e um ou dois núcleos. Isso basta para um blog, um site institucional ou uma loja pequena em WordPress, e na maioria dos provedores dá para aumentar o plano depois sem reinstalar nada. Se o site já funciona, não precisa adivinhar: em cinco minutos você vê quanta memória ele ocupa e escolhe um plano com uns 30% de folga.

O erro mais comum vai sempre para o mesmo lado: contratar quatro núcleos e 1 GB de memória, porque núcleos parecem mais robustos. Para um site, é uma combinação ruim. O PHP e o banco de dados consomem um gigabyte em minutos, o servidor começa a jogar memória para o disco, e as páginas levam vários segundos para abrir, embora o processador esteja quase ocioso.

O que você recebe por esse dinheiro

Peguei cerca de 27.700 planos de VPS de 2.200 provedores do catálogo da accsly em 27 de outubro de 2026, separei por preço mensal e, para cada faixa, encontrei a mediana de memória, núcleos e disco. Os valores foram convertidos de rublos e arredondados (US$ 1 é perto de R$ 5,50).

A proporção comum no mercado é um núcleo para cada 2 GB de memória. Os planos de 2 GB se dividem quase meio a meio: metade tem um núcleo, metade tem dois. Com 4 GB, 61% dos planos vêm com dois núcleos; com 8 GB, 57% vêm com quatro.

Um servidor com 4 GB de memória custa, na mediana do mercado, cerca de US$ 20 por mês (uns R$ 110). Seleções por tamanho: VPS com 2 GB, VPS com 4 GB, VPS com 8 GB.

Para onde vai a memória num servidor com site

Um site em PHP com banco de dados divide a memória entre quatro consumidores. Sabendo quanto cada um come, dá para calcular o tamanho certo num papel.

• O próprio sistema. Um Ubuntu ou Debian recém-instalado ocupa 150–300 MB depois de iniciar.
• O servidor web nginx usa dezenas de megabytes; pode deixar fora da conta.
• PHP-FPM. Cada processo de PHP ocupa 40–100 MB, e um WordPress com uma dúzia de plugins ou um Magento pode passar disso. Há tantos processos quanto requisições que o site atende ao mesmo tempo.
• MySQL ou MariaDB. O maior consumidor. O banco mantém na memória um buffer com dados e índices, mais alguns megabytes por conexão.

Um painel de controle como o CyberPanel ou o FastPanel acrescenta mais 200–500 MB; o Redis para cache, de 50 MB até o tamanho do que você guardar nele.

Imagine uma loja em WooCommerce com 5.000 produtos e um banco de 800 MB. O sistema ocupa 300 MB, o buffer do banco com todos os dados e folga, 1 GB, o próprio banco por cima, mais 300 MB, 15 processos de PHP de 80 MB, 1,2 GB, e o Redis, 100 MB. Dá cerca de 3 GB. Num servidor de 4 GB sobra um gigabyte, que o Linux usa como cache de arquivos, e isso é bom. Em 2 GB a loja também roda, mas o buffer do banco e o número de processos de PHP precisam ser cortados pela metade, e nos horários de promoção as páginas do catálogo ficam mais lentas.

E quantos núcleos?

Menos do que parece. Um núcleo executa uma requisição de PHP por vez. Se uma página é montada em 200 ms, um núcleo entrega cinco páginas por segundo, e dois núcleos, dez.

Traduzindo em visitantes: um site com 10.000 visitantes por dia mostra umas 30.000 páginas. Na hora de pico cai mais ou menos um décimo disso, 3.000 páginas, ou seja, menos de uma por segundo. Um núcleo dá conta. O segundo ajuda para que o painel administrativo, a importação de produtos, o backup e os robôs de busca não deixem o site lento para os visitantes. E com cache de páginas ativado, a maior parte das requisições nem chega ao PHP.

Núcleos fazem falta quando muitas páginas não podem ir para o cache: filtros do catálogo, busca, carrinho, área do cliente. Também são consumidos por tarefas pesadas em segundo plano, como processar imagens, exportar produtos para marketplaces e importar listas de preços. E por vários sites no mesmo servidor.

Pagar por núcleos «para o futuro» sai caro. Com 4 GB de memória, um plano de quatro núcleos custa na mediana do mercado US$ 27, e um de dois, US$ 19: diferença de US$ 8 por mês (uns R$ 44). Com 8 GB, a diferença entre dois e quatro núcleos é de só uns US$ 3, então nesse tamanho quatro núcleos saem quase de graça. Para o PHP, a frequência também conta: cada página é montada num único núcleo, e a 4,5 GHz ela fica pronta bem antes que a 2,2 GHz. Esses planos estão na seleção VPS com processador de alta frequência.

O que contratar para sites típicos

• Landing page, site estático, cartão de visita sem banco de dados: 1 GB e um núcleo. São os planos mais baratos, e não há por que pagar mais: VPS com 1 GB.
• Blog ou site institucional em WordPress com cache: 2 GB e um ou dois núcleos: VPS para WordPress.
• Loja com milhares de produtos em WooCommerce, OpenCart ou PrestaShop: 4 GB e dois núcleos: VPS para loja virtual.
• Magento: a partir de 4 GB, e para uma loja com catálogo grande, 8 GB e quatro núcleos.
• Aplicação em Laravel com filas e Redis: 2–4 GB, porque cada worker da fila mantém o próprio processo de PHP na memória. Seleção: VPS para Laravel.
• Vários sites e um painel de controle: some as necessidades dos sites e acrescente 0,5–1 GB para o painel.

Quanta memória o site gasta de verdade

Entre no servidor por SSH e rode:

free -m

A saída vai ser parecida com esta:

               total        used        free      shared  buff/cache   available
Mem:            3915        1720         240          60        1955        1890
Swap:           1023          12        1011

Não se assuste com o número pequeno na coluna free. O Linux usa a memória livre como cache de arquivos, que é a coluna buff/cache, e a devolve aos programas assim que eles pedem. O que importa é available: aqui o servidor tem 1,9 GB que os programas podem pegar agora. Se available fica abaixo de 10% do total nos horários de pico, falta memória.

A segunda verificação é se o servidor usa swap:

vmstat 1 10

O comando imprime uma linha de números dez vezes, uma por segundo. Olhe as colunas si e so: quanto o servidor lê do swap e grava nele por segundo. Zeros significam que está tudo bem, mesmo que a linha Swap do free mostre algo ocupado. Se ali aparecem centenas e milhares o tempo todo, o servidor está jogando memória para o disco, e isso deixa o site mais lento do que qualquer outro problema.

A terceira é se o sistema matou processos por falta de memória. Quando a memória acaba de vez, o kernel do Linux escolhe o maior processo, muitas vezes o MySQL, e o encerra. Para os visitantes, isso aparece como «Error establishing a database connection» ou erro 502.

journalctl -k | grep -i -E 'out of memory|killed process'

Se o comando encontrou algo, a memória faltou pelo menos uma vez. Contrate um plano maior ou reduza o apetite do PHP e do banco, como mostro abaixo.

Quem comeu a memória: htop e ps

Rode o htop (no Ubuntu e no Debian ele se instala com apt install htop) e aperte M para ordenar os processos por memória. A coluna RES mostra quanto cada processo ocupa na RAM. No topo costumam aparecer mysqld ou mariadbd e uma longa fila de processos php-fpm.

Para somar quanta memória vai para o PHP no total e por processo, basta uma linha:

ps -eo rss,comm | awk '/php-fpm/ {s+=$1; n++} END {printf "%d processos, %.0f MB no total, %.0f MB por processo\n", n, s/1024, s/n/1024}'

O total sai um pouco inflado, porque os processos de PHP compartilham parte da memória entre si. Para uma estimativa, serve. Rode o comando durante o dia, com visitantes no site: à noite os processos estão ociosos e parecem menores.

O tamanho médio do processo diz quantos processos de PHP você pode permitir. Decida quanta memória vai dar ao PHP e divida pelo tamanho do processo. Por exemplo, 1.200 MB com 80 MB por processo dão 15 processos. Esse número vai no parâmetro pm.max_children do arquivo do pool, que no Ubuntu e no Debian é /etc/php/8.3/fpm/pool.d/www.conf, onde 8.3 é a sua versão do PHP. Se você puser mais, num pico de visitas o PHP ocupa toda a memória e o sistema começa a matar processos. Se puser menos, as requisições a mais esperam na fila, mas o servidor continua de pé.

O buffer do MySQL: maior consumidor e maior alavanca

O banco de dados é rápido enquanto os dados e índices cabem no buffer em memória. Para saber quanto pesam as tabelas, rode esta consulta no console do mysql:

SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024) AS mb
FROM information_schema.tables WHERE engine = 'InnoDB';

O tamanho atual do buffer:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

Depois da instalação ele costuma ser de 128 MB. Para uma loja com banco de 800 MB, é pouco demais: cada filtro do catálogo vai ler o disco. Dois contadores mostram se o buffer é suficiente:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Divida Innodb_buffer_pool_reads por Innodb_buffer_pool_read_requests. O primeiro número é quantas vezes o banco precisou ir ao disco; o segundo, quantas leituras houve no total. Se o resultado é menor que 0,01, ou seja, menos de 1% das leituras vai ao disco, o buffer basta. Olhe esses números depois que o servidor rodar pelo menos um dia.

Vale deixar o buffer do tamanho dos dados mais 10–20% para crescimento, mas, num servidor em que o PHP roda ao lado, não mais que metade da memória total. O valor é definido pela linha innodb_buffer_pool_size = 1G na seção [mysqld] da configuração (no Ubuntu, /etc/mysql/mysql.conf.d/mysqld.cnf; no MariaDB, um arquivo em /etc/mysql/mariadb.conf.d/), e depois é preciso reiniciar o banco. Se o banco não cabe nem em metade da memória, é um motivo honesto para um plano maior. Nessa situação, um disco rápido também ajuda; falo disso no artigo NVMe ou SSD para site.

Quando aumentar a memória e quando os núcleos

Falta memória se available cai abaixo de 10% no pico, se o vmstat mostra valores diferentes de zero em si e so ou se o log tem processos mortos. Aqui, mais núcleos não adiantam.

Faltam núcleos se a memória está livre, mas o site fica lento sob carga. Confira com o comando uptime: os três números no fim da linha mostram a carga média de 1, 5 e 15 minutos. Compare com o número de núcleos do comando nproc. Se nos horários de pico a carga fica por muito tempo acima do número de núcleos e o htop mostra o processador ocupado com processos php-fpm, você precisa de núcleos ou de cache de páginas, que muitas vezes sai mais barato.

Há dois casos em que um plano maior no mesmo provedor não resolve. Se no top, na linha %Cpu(s), o valor st está alto, de 10% para cima, os vizinhos no servidor físico estão tomando o seu processador. Só ajuda outro provedor ou um plano com núcleos dedicados. Se o wa está alto, o processador está esperando o disco, e o problema a resolver é o disco, não os núcleos.

Na dúvida entre dois tamanhos, fique com o menor num provedor que permita subir de plano pelo painel em poucos minutos. Antes de comprar, veja na descrição se dá para mudar de plano sem reinstalar. E se você quer testar o site em várias configurações, a cobrança por hora é prática: uma noite de servidor custa menos de um dólar. Os demais parâmetros do plano estão no artigo como escolher uma VPS.