Voc\u00ea aloca 4 vCPUs para sua VM. O benchmark n\u00e3o bate com o que voc\u00ea via em um servidor dedicado com 4 n\u00facleos f\u00edsicos. Isso n\u00e3o \u00e9 bug de configura\u00e7\u00e3o.<\/p>\n\n\n\n
\u00c9 a dist\u00e2ncia entre o que a vCPU promete e o que ela de fato entrega, sempre que o hipervisor divide o mesmo core entre m\u00faltiplos inquilinos. Esse artigo mostra onde essa dist\u00e2ncia aparece na pr\u00e1tica: conten\u00e7\u00e3o de scheduler, steal time, e os cen\u00e1rios em que o gap importa.<\/p>\n\n\n\n
Uma vCPU \u00e9 uma abstra\u00e7\u00e3o de software gerenciada pelo hipervisor (KVM, Xen, VMware ESXi). Na pr\u00e1tica da nuvem moderna, uma vCPU geralmente corresponde a uma thread l\u00f3gica de um n\u00facleo f\u00edsico (via Hyper-Threading ou SMT), e n\u00e3o a um n\u00facleo dedicado inteiro.<\/p>\n\n\n\n
O scheduler do hipervisor agenda o tempo de execu\u00e7\u00e3o dessa vCPU em cima das threads do hardware real, onde ela compete por ciclos de processamento e cache com as vCPUs de outras VMs do mesmo host. Rode sua aplica\u00e7\u00e3o no core da internet brasileira e voc\u00ea ainda est\u00e1 sujeita a essa mec\u00e2nica.<\/p>\n\n\n\n
A propor\u00e7\u00e3o entre vCPUs e cores f\u00edsicos varia por provedor e hipervisor. Alguns mapeiam uma vCPU para uma thread de hyper-threading; outros usam raz\u00f5es de overcommit de 2:1 ou 3:1 para cargas mistas. Nenhuma propor\u00e7\u00e3o \u00e9 universal.<\/p>\n\n\n\n
Assumir 1 vCPU = 1 core f\u00edsico \u00e9 o erro de dimensionamento mais comum em quem migra de bare metal para cloud, e costuma aparecer s\u00f3 quando o tr\u00e1fego aumenta e a lat\u00eancia fica inconsistente, sem nenhuma mudan\u00e7a de c\u00f3digo.<\/p>\n\n\n\n
CPU f\u00edsica \u00e9 o n\u00facleo real do processador. Sem scheduler de hipervisor decidindo quando sua thread roda: o sistema operacional agenda diretamente no hardware.<\/p>\n\n\n\n
Esse ganho de previsibilidade some quando a dist\u00e2ncia f\u00edsica at\u00e9 o servidor cresce. Por isso baixa lat\u00eancia de rede<\/a> e baixo steal time resolvem problemas diferentes, mas se somam no resultado final que o usu\u00e1rio percebe.<\/p>\n\n\n\n Steal time mede o percentual de tempo em que sua vCPU est\u00e1 pronta para executar, mas o hipervisor est\u00e1 ocupado rodando outra VM no mesmo core. Voc\u00ea pediu processamento e n\u00e3o recebeu.<\/p>\n\n\n\n Em CPU f\u00edsica, steal time \u00e9 zero por defini\u00e7\u00e3o: n\u00e3o existe compartilhamento de n\u00facleo, ent\u00e3o n\u00e3o existe hipervisor decidindo prioridade.<\/p>\n\n\n\n %st acima de 10% por per\u00edodo sustentado (cerca de 20 minutos) indica conten\u00e7\u00e3o de host:<\/p>\n\n\n\n Em APIs e bancos de dados, steal time soma direto ao tempo de resposta: uma query de 10ms com 15% de steal passa a levar 11,5ms. Em batch jobs e processamento ass\u00edncrono, o mesmo steal time importa muito menos, porque o SLA ali \u00e9 de throughput total, n\u00e3o de lat\u00eancia por requisi\u00e7\u00e3o.<\/p>\n\n\n\n Gastar em CPU dedicada para eliminar steal time de uma fila noturna raramente compensa; para uma API de checkout, costuma se pagar r\u00e1pido.<\/p>\n\n\n\n Noisy neighbor \u00e9 quando outro tenant no mesmo host consome recursos de forma agressiva e degrada sua performance, mesmo com quotas de CPU configuradas no orquestrador.<\/p>\n\n\n\n Um estudo de pesquisadores da UFES, UFC, UFMG, USP e Universidade do Minho, aceito para publica\u00e7\u00e3o na IEEE ICC 2026, quantificou esse efeito em um cluster Kubernetes controlado. Sob ru\u00eddo combinado de CPU, mem\u00f3ria, disco e rede:<\/p>\n\n\n\n An\u00e1lise de causalidade de Granger confirmou influ\u00eancia unidirecional do tenant agressivo sobre as v\u00edtimas em 10 de 10 rodadas, com p-valor m\u00e9dio de 0,003. ResourceQuotas bem configuradas no Kubernetes n\u00e3o isolam hardware: conten\u00e7\u00e3o em cache de CPU ou controlador de mem\u00f3ria escapa do orquestrador.<\/p>\n\n\n\n Conten\u00e7\u00e3o em um recurso vaza para outro. Sob estresse de mem\u00f3ria, o tenant limitado a CPU registrou aumento de 13,49% em I\/O de disco, mesmo sem carga adicional de disco configurada. Sob ru\u00eddo combinado, esse aumento chegou a 20,01%.<\/p>\n\n\n\n Isso ocorre porque a falta de mem\u00f3ria for\u00e7a o kernel a despejar p\u00e1ginas do page cache agressivamente ou a recorrer ao swap, multiplicando as leituras e escritas no disco. Quando a CPU \u00e9 throttled, o processamento tamb\u00e9m se acumula em fila, e parte dela se manifesta como I\/O em espera. Na pr\u00e1tica: um pico inexplic\u00e1vel de I\/O na sua VM pode ter origem em conten\u00e7\u00e3o de mem\u00f3ria ou CPU em outro tenant, n\u00e3o em um gargalo real na sua camada de armazenamento.<\/p>\n\n\n\n A disputa por disco penaliza sobretudo picos, n\u00e3o a opera\u00e7\u00e3o t\u00edpica, o que torna esse gargalo mais dif\u00edcil de perceber olhando s\u00f3 a m\u00e9dia.<\/p>\n\n\n\n Os autores traduziram isso em recomenda\u00e7\u00e3o de capacidade: workloads de CPU coexistindo com vizinhos de alto consumo pedem de 2 a 2,5 vezes mais provisionamento para manter o SLA original. N\u00e3o \u00e9 exagero de seguran\u00e7a, \u00e9 o custo real de operar em multi-tenant sem isolamento de hardware garantido.<\/p>\n\n\n\n APIs, bancos transacionais, trading: steal time se traduz direto em p99 de lat\u00eancia. SLA sob 20ms com conten\u00e7\u00e3o intermitente de 10-15% j\u00e1 pode violar o contrato. Vale considerar CPU dedicada ou vCPU fixada (pinned).<\/p>\n\n\n\n Batch, filas, workers: toleram melhor a varia\u00e7\u00e3o, porque o que importa \u00e9 o total processado, n\u00e3o a lat\u00eancia por unidade.<\/p>\n\n\n\n Se beneficiam da flexibilidade da vCPU, j\u00e1 que o scheduler realoca n\u00facleos conforme picos de acesso. Se voc\u00ea est\u00e1 decidindo entre tipos de servidor virtual<\/a>, mapeie primeiro se o tr\u00e1fego \u00e9 constante ou intermitente.<\/p>\n\n\n\n Raramente exigem performance constante, ent\u00e3o overcommit de vCPU \u00e9 desej\u00e1vel para reduzir custo. Mais vCPUs significam mais “c\u00e9rebros” trabalhando pelo mesmo objetivo, mas o ganho s\u00f3 vira performance real de infraestrutura cloud<\/a> quando a aplica\u00e7\u00e3o de fato paraleliza a carga. Uma aplica\u00e7\u00e3o single-threaded n\u00e3o se beneficia de vCPUs adicionais, ganhe voc\u00ea 2 ou 16.<\/p>\n\n\n\n Para monitorar a conten\u00e7\u00e3o em tempo real (snapshots pontuais), utilize:<\/p>\n\n\n\n O problema desses dois comandos \u00e9 que eles capturam s\u00f3 um recorte de 30 segundos em tempo real. Para provar ao suporte do provedor um problema sustentado<\/em> por 15-20 minutos, a ferramenta can\u00f4nica no ecossistema Linux \u00e9 o sar (pacote sysstat), que coleta e ret\u00e9m dados hist\u00f3ricos:<\/p>\n\n\n\n Se %st sustentado passa de 10% por 15-20 minutos \u2014 confirmado no hist\u00f3rico do sar \u2014 o problema \u00e9 conten\u00e7\u00e3o de host, n\u00e3o c\u00f3digo da aplica\u00e7\u00e3o. A a\u00e7\u00e3o \u00e9 conversar com o provedor sobre migra\u00e7\u00e3o de host ou migrar para CPU dedicada.<\/p>\n\n\n\n Para monitoramento cont\u00ednuo em vez de coletas pontuais, vale expor m\u00e9tricas nativas como node_cpu_seconds_total{mode=”steal”} (node exporter) ou usar perf, alimentando dashboards no Grafana. Snapshots via CLI ajudam a diagnosticar um incidente j\u00e1 em curso; um dashboard cont\u00ednuo mostra o pico antes de virar chamado.<\/p>\n\n\n\n O sintoma \u00e9 parecido, load average alto com pouco uso aparente de CPU, mas a causa \u00e9 outra: threads presas em espera de disco. Vale checar iowait e o percentual de processos em estado D antes de assumir que o problema \u00e9 CPU.<\/p>\n\n\n\n Um exemplo real: uma VM com load average de 5.0 e top\/iotop mostrando pouca atividade. iostat -x exp\u00f5e %iowait elevado com algum %steal simult\u00e2neo. O Linux conta como load average tanto processos execut\u00e1veis quanto em espera de I\/O, ent\u00e3o carga alta com pouco uso de CPU vis\u00edvel \u00e9 leitura incompleta da m\u00e9trica, n\u00e3o paradoxo. Migrar a VM para outro host costuma normalizar tudo de imediato.<\/p>\n\n\n\n Reuna, antes de abrir o chamado:<\/p>\n\n\n\n Steal time varia ao longo do dia. Um snapshot de 30 segundos em hor\u00e1rio calmo n\u00e3o captura o pico das 14h \u2014 por isso o hist\u00f3rico do sar (ou uma s\u00e9rie cont\u00ednua no Grafana) pesa mais como evid\u00eancia do que um recorte isolado. Vale automatizar essa coleta.<\/p>\n\n\n\n Dimensionar uma VM n\u00e3o \u00e9 s\u00f3 somar vCPUs. RAM, disco e a propor\u00e7\u00e3o de overcommit do provedor entram na equa\u00e7\u00e3o. Para builds de Next.js e Nuxt.js SSR, a recomenda\u00e7\u00e3o pr\u00e1tica \u00e9 de no m\u00ednimo 2 vCPUs e 4 GB de RAM, abaixo disso o build pode travar.<\/p>\n\n\n\n A base dessa escolha \u00e9 dupla: o perfil real da sua carga, medido em steal time e throughput, e a transpar\u00eancia do provedor sobre como ele lida com overcommit. Antes de migrar de plano, rode mpstat (ou sar) por uma hora em hor\u00e1rio de pico e registre o %st m\u00e9dio. Sem esse n\u00famero, qualquer upgrade \u00e9 aposta, n\u00e3o diagn\u00f3stico.<\/p>\n\n\n\n Um provedor s\u00f3lido n\u00e3o esconde a propor\u00e7\u00e3o de aloca\u00e7\u00e3o atr\u00e1s de “vCPUs ilimitadas” gen\u00e9ricas: ele documenta a raz\u00e3o real de vCPU por core em cada plano.<\/p>\n\n\n\n Para quem roda Kubernetes ou Docker Swarm em cima de VMs cloud, o overhead de virtualiza\u00e7\u00e3o n\u00e3o desaparece, ganha uma camada extra de complexidade. O Kubernetes n\u00e3o aloca vCPUs exclusivas para os pods; ele utiliza cgroups (CFS Quota) no kernel do Linux para limitar o tempo de uso da CPU, medido em millicores. Isso significa que a conten\u00e7\u00e3o ocorre em dois n\u00edveis simult\u00e2neos:<\/p>\n\n\n\n Isso explica por que um pod com resources.limits.cpu: “2” \u00e0s vezes sofre throttling ou lat\u00eancia mesmo quando o cluster relata uso baixo de CPU: o throttling do CFS acontece no node, mas a causa raiz pode estar um n\u00edvel abaixo, na disputa por hardware entre VMs. Monitorar s\u00f3 m\u00e9tricas do Kubernetes (kubectl top, Prometheus) n\u00e3o mostra steal time do host. Vale correlacionar as duas fontes antes de escalar horizontalmente.<\/p>\n\n\n\n Para quem constr\u00f3i no Locaweb Cloud, dimensionar vCPU corretamente \u00e9 o primeiro passo antes de escalar a aplica\u00e7\u00e3o. Se sua VM est\u00e1 sofrendo com steal time ou voc\u00ea precisa de mais previsibilidade, vale avaliar os planos de Locaweb Cloud<\/a> com propor\u00e7\u00e3o de aloca\u00e7\u00e3o transparente, ou o Servidor VPS<\/a> para cargas com perfil mais est\u00e1vel. Para proteger o tr\u00e1fego entre sua aplica\u00e7\u00e3o e os usu\u00e1rios finais, o Certificado SSL<\/a> fecha a configura\u00e7\u00e3o de produ\u00e7\u00e3o.<\/p>\n\n\n\nOnde a diferen\u00e7a aparece: steal time<\/h2>\n\n\n\n
O que a m\u00e9trica mede<\/h3>\n\n\n\n
N\u00fameros de refer\u00eancia<\/h3>\n\n\n\n
\n
O impacto varia por tipo de carga<\/h3>\n\n\n\n
Ru\u00eddo de vizinho: o que a pesquisa mostra<\/h2>\n\n\n\n
O fen\u00f4meno e o estudo<\/h3>\n\n\n\n
\n
O efeito colateral entre recursos<\/h3>\n\n\n\n
Assinaturas de degrada\u00e7\u00e3o por recurso<\/h3>\n\n\n\n
\n
O custo pr\u00e1tico em provisionamento<\/h3>\n\n\n\n
Quando o gap importa de verdade<\/h2>\n\n\n\n
Cargas latency-sensitive<\/h3>\n\n\n\n
Cargas de throughput<\/h3>\n\n\n\n
Web servers com tr\u00e1fego intermitente<\/h3>\n\n\n\n
Ambientes de dev e homologa\u00e7\u00e3o<\/h3>\n\n\n\n
Como diagnosticar conten\u00e7\u00e3o na sua VM<\/h2>\n\n\n\n
Comandos de diagn\u00f3stico r\u00e1pido e hist\u00f3rico<\/h3>\n\n\n\n
# Vis\u00e3o de CPU com steal time na \u00faltima coluna\n\niostat -c 1 30\n\n# Detalhamento por core, incluindo %st\n\nmpstat -P ALL 1 30<\/code><\/pre>\n\n\n\n# Exibe m\u00e9tricas de CPU, incluindo %steal, do dia atual\n\nsar -u<\/code><\/pre>\n\n\n\nQuando o gargalo \u00e9 I\/O, n\u00e3o CPU<\/h3>\n\n\n\n
Evid\u00eancia para abrir chamado<\/h3>\n\n\n\n
\n
Escolhendo o plano certo: vCPU n\u00e3o \u00e9 o \u00fanico fator<\/h2>\n\n\n\n
E se sua carga roda em containers?<\/h2>\n\n\n\n
\n
Fechando a conta<\/h2>\n\n\n\n
FAQ \u2013 Perguntas frequentes sobre vCPU e CPU f\u00edsica<\/h2>\n\n\n\n