Dimensionamento de vCPU - Quanto é demais? Quanto é de menos?

Definir a quantidade certa de vCPUs parece simples no começo... até você perceber que tem mais variáveis do que gostaria de considerar. Tipo de workload, uso real da aplicação, ambiente de nuvem, licenciamento... tudo entra na conta.

Talvez sua VM esteja rodando com 4 vCPUs e só use 30% de uma. Ou talvez esteja no limite com 2 e você nem percebeu. E aí começa a dúvida: será que acertei na mão?

Não existe uma resposta única. Mas dá pra tomar essa decisão com mais critério (e com bem menos tentativa e erro).

Afinal, que é uma vCPU?

A vCPU, ou CPU virtual, é uma unidade de processamento lógica atribuída a uma máquina virtual. Ela não existe fisicamente no hardware, mas o sistema operacional da VM enxerga essa vCPU como se fosse um núcleo real.

Na prática, funciona assim: o hypervisor, que é o software responsável por gerenciar o ambiente virtualizado, pega os núcleos físicos (ou threads de um processador físico) e divide entre as VMs ativas. Cada "fatia" dessa divisão se torna uma vCPU.

É como alugar só um pedaço do processador, não ele inteiro. Esse pedaço pode estar sendo compartilhado com outras aplicações ou até com outras máquinas virtuais. Por isso, o desempenho de uma vCPU depende bastante de como o ambiente todo está configurado e utilizado.

Um processador com 4 núcleos e hyperthreading (2 threads por núcleo) pode fornecer até 8 vCPUs. Mas isso não quer dizer que essas 8 vCPUs tenham o mesmo desempenho de 8 núcleos físicos. O que muda é a forma como os ciclos de CPU são distribuídos.

Em resumo:

• CPU física é hardware de verdade

• vCPU é uma abstração que simula um núcleo

• O hypervisor gerencia quem usa o quê, quando

Quantas vCPUs cabem numa CPU? (e por que isso varia)

Essa é uma daquelas perguntas que parece ter uma resposta simples, mas depende de alguns fatores. O principal deles: como o processador e o ambiente de virtualização estão configurados.

Em geral, cada núcleo físico pode executar dois threads simultâneos (quando há hyperthreading). E cada thread pode ser tratado como uma vCPU pelo hypervisor. Por isso, uma CPU com 4 núcleos e hyperthreading pode oferecer até 8 vCPUs.

vCPUs = núcleos físicos × threads por núcleo × número de CPUs físicas

Só que nem sempre o número de vCPUs alocadas bate exatamente com o número de threads disponíveis. Muitas vezes, o ambiente é configurado para rodar mais vCPUs do que o hardware físico suportaria simultaneamente.

É aí que entra o conceito de oversubscription.

O hypervisor faz uma espécie de revezamento entre as VMs, agendando as vCPUs para usar os núcleos físicos por pequenos períodos de tempo. Isso funciona bem em ambientes onde as máquinas virtuais não exigem processamento o tempo todo.

Mas tem um limite. Se várias VMs precisarem de CPU ao mesmo tempo, pode gerar uma contenção: tudo começa a disputar os mesmos recursos. E isso gera atrasos, lentidão e queda de desempenho.

Tá, mas quantas vCPUs eu preciso?

A resposta mais honesta? Depende. E não é “depende” por preguiça de responder, é porque cada workload tem um comportamento diferente. Tentar adivinhar pode sair caro, seja por desperdício de recurso, seja por travamento inesperado.

Se sua aplicação é mais leve, como um servidor web com pouco tráfego ou uma API que responde a poucos chamados por minuto, talvez 1 ou 2 vCPUs sejam mais que suficientes. Já se você roda banco de dados, processamento paralelo, aplicações com múltiplas threads ou jobs em background, o cenário muda de figura.

Aqui vai uma ideia:

• Workload leve: sites institucionais, serviços de DNS, pequenas APIs - 1 vCPU (ou 2, se for mais estável com picos)

• Workload média: aplicações web com acesso moderado, sistemas administrativos - 2 a 4 vCPUs

• Workload pesada: banco de dados, processamento de dados em tempo real, serviços críticos -  4+ vCPUs, às vezes dedicadas, dependendo do volume

Mas cuidado: jogar 8 vCPUs numa VM que roda ociosa 90% do tempo não vai fazer milagre, só vai consumir recurso do host à toa.

Se o seu ambiente trabalha com picos (como lojas em horários específicos ou integrações sazonais), talvez o ideal seja menos vCPUs com elasticidade configurada, ou um burst controlado.

Por outro lado, se a aplicação é sensível a latência ou precisa rodar sem nenhuma oscilação, mais vCPUs podem ser necessárias, com alocação mais conservadora e até com pinagem de CPU, se for o caso.

Dica prática: Antes de decidir, monitore. Use ferramentas como htop, Prometheus ou Grafana pra ver como a CPU está sendo usada na prática. Se o consumo médio estiver abaixo de 40% e os picos não passarem de 70%, talvez você tenha espaço pra otimizar.

Antes de fechar a conta

Não existe uma resposta exata sobre quantas vCPUs são ideais. Esse número não sai de uma tabela genérica nem de fórum de TI. Ele depende do que sua aplicação realmente precisa, do comportamento do seu ambiente e do quanto você pode (ou quer) escalar.

Mais importante do que acertar de primeira é ter base pra ajustar conforme o cenário muda. Isso vale tanto pra quem está começando agora quanto pra quem já desconfia que pode estar gastando mais do que deveria.

Precisa entender melhor se está alocando as vCPUs certas? Fale com a EVEO. A gente ajuda você a entender o que faz sentido no seu cenário e dimensionar com segurança.

Fale com um especialista da EVEO