Otimizando o overhead de vCPU causado por gargalos de storage em máquinas virtuais

Quando uma máquina virtual apresenta lentidão, o instinto primário de muitos administradores de infraestrutura é abrir o gerenciador de tarefas do sistema operacional convidado. Ao observar a CPU cravada em 100%, a conclusão precipitada costuma ser a falta de poder computacional. No entanto, no ecossistema de virtualização, o que parece ser um gargalo de processamento é, na grande maioria das vezes, um problema severo de latência de storage mascarado.

A relação entre o armazenamento de dados e o consumo de ciclos de processador no hypervisor é íntima e complexa. Cada operação de leitura ou gravação que uma VM envia para um datastore exige coordenação. Se os discos físicos, a rede de armazenamento (SAN) ou as controladoras virtuais não conseguem acompanhar o ritmo, a CPU não fica ociosa. Ela entra em um estado de espera ativa, consumindo recursos reais do host físico enquanto aguarda o retorno dos dados.

Resumo em 30 segundos

O alto uso de CPU reportado pelo sistema operacional convidado frequentemente reflete ciclos desperdiçados em estado de I/O wait, aguardando respostas do datastore.

Adicionar mais vCPUs para resolver lentidão agrava o problema, aumentando o overhead de agendamento do hypervisor (CPU Co-Stop).

Substituir controladoras de disco emuladas por adaptadores paravirtualizados (PVSCSI) ou vNVMe reduz drasticamente o consumo de CPU por operação de I/O.

Latência fantasma e o alto uso de CPU reportado pelo sistema operacional convidado

Para entender como o storage rouba ciclos de CPU, precisamos olhar para o comportamento do sistema operacional convidado (Guest OS). Quando uma aplicação solicita um bloco de dados, o kernel do sistema operacional envia um comando SCSI ou NVMe para a controladora de disco virtual. A partir desse milissegundo, a thread responsável por essa requisição fica bloqueada aguardando a confirmação (acknowledgment) de que o dado foi lido ou gravado.

Em sistemas Linux, esse tempo de espera é categorizado como I/O wait (ou wa no comando top). Em ambientes Windows, isso se manifesta como um alto tempo ativo de disco e, paradoxalmente, picos de uso de CPU em processos de sistema. O processador virtual está literalmente gastando energia e tempo de clock apenas esperando o subsistema de discos responder.

Figura: Representação visual de um núcleo de CPU desperdiçando ciclos em estado de I/O wait enquanto aguarda dados de um storage lento.

Essa latência fantasma engana as ferramentas de monitoramento internas da VM. Como o Guest OS não tem visibilidade da infraestrutura física subjacente, ele interpreta a demora na entrega dos blocos de dados como uma carga de trabalho pesada. O resultado é um diagnóstico incorreto que leva a ações corretivas desastrosas na configuração da máquina virtual.

Como o I/O wait de datastores se transforma em ciclos desperdiçados no hypervisor

Descendo uma camada na arquitetura, o hypervisor (seja VMware ESXi ou KVM) precisa gerenciar essas requisições pendentes. Quando uma VM utiliza uma controladora de disco emulada por software, o hypervisor precisa traduzir cada comando do Guest OS para um formato que o hardware físico entenda. Esse processo de tradução exige ciclos reais da CPU do host.

Se o datastore de destino (um array all-flash, um cluster vSAN ou um storage NAS) estiver sofrendo com alta latência, as filas de comandos no hypervisor começam a encher. No vSphere, podemos observar isso através de duas métricas fundamentais de storage: DAVG (Device Average Latency) e KAVG (Kernel Average Latency).

A DAVG mede o tempo que o storage físico leva para responder. Já a KAVG mede o tempo que o comando passa preso na pilha de armazenamento do próprio hypervisor.

⚠️ Perigo: Ignorar a métrica KAVG é um erro crítico. Se a DAVG está baixa (storage rápido) mas a KAVG está alta (acima de 2 milissegundos), o gargalo não está nos discos físicos. O gargalo está na forma como a VM está processando o I/O, gerando um overhead massivo de CPU no host.

Quando a KAVG sobe, o hypervisor gasta um tempo precioso gerenciando filas de I/O em vez de executar instruções computacionais úteis. Isso afeta não apenas a VM problemática, mas todas as outras máquinas virtuais que compartilham os mesmos núcleos físicos do servidor (noisy neighbor effect).

A armadilha de adicionar mais vCPUs para compensar a lentidão de leitura e gravação

O erro mais comum na administração de infraestrutura virtual é o superdimensionamento reativo. Ao ver a VM lenta e com "alta CPU", o administrador desliga a máquina e dobra a quantidade de vCPUs (de 4 para 8, por exemplo). Essa ação, na tentativa de dar mais fôlego ao sistema, cria um efeito cascata que destrói a performance do storage.

O hypervisor utiliza um agendador (scheduler) complexo para alocar tempo de processador físico para as vCPUs. Quando uma VM tem múltiplas vCPUs, o hypervisor precisa encontrar núcleos físicos disponíveis simultaneamente para executar as instruções. Esse conceito é conhecido como co-agendamento (co-scheduling).

Figura: Metáfora visual do gargalo de agendamento: múltiplas vCPUs tentando acessar uma única fila de storage congestionada.

Se a VM já estava gastando ciclos esperando pelo storage, adicionar mais vCPUs significa que agora o hypervisor precisa agendar mais núcleos físicos apenas para que eles também fiquem parados em estado de I/O wait. Isso aumenta drasticamente uma métrica chamada CPU Co-Stop (ou %CSTP).

O aumento do Co-Stop atrasa o processamento das interrupções de hardware. Quando o storage finalmente entrega o dado solicitado, a controladora virtual envia uma interrupção para a vCPU avisando que o dado chegou. Se a vCPU estiver "congelada" aguardando agendamento devido ao excesso de núcleos, a interrupção não é processada imediatamente. A latência percebida pela aplicação dispara, mesmo que o array de storage físico tenha respondido em microssegundos.

Substituindo controladoras emuladas por PVSCSI e vNVMe para destravar o barramento

A solução definitiva para eliminar o overhead de CPU causado por I/O de storage não é adicionar processador, mas sim otimizar o caminho dos dados. Isso é feito substituindo as controladoras de disco padrão por opções desenhadas especificamente para ambientes virtualizados.

Por padrão, muitas VMs são criadas com a controladora LSI Logic SAS. Ela é altamente compatível com quase todos os sistemas operacionais, mas funciona através de emulação estrita de hardware. Cada I/O exige que o hypervisor simule o comportamento elétrico de uma placa física, o que custa muitos ciclos de CPU.

Para cargas de trabalho intensivas em storage (bancos de dados, servidores de arquivos, sistemas ERP), a recomendação absoluta é utilizar a controladora PVSCSI (Paravirtualized SCSI) ou a moderna vNVMe (Virtual Non-Volatile Memory Express).

A PVSCSI é uma controladora ciente da virtualização. Ela não emula hardware físico. Em vez disso, ela cria um canal de comunicação direto e otimizado entre o Guest OS e o hypervisor. Isso permite agrupar múltiplos comandos de I/O em uma única interrupção de CPU (interrupt coalescing), reduzindo o overhead de processamento em até 30% em comparação com a LSI Logic.

A controladora vNVMe vai um passo além. Desenhada para a era dos datastores baseados em memória flash (SSDs NVMe), ela reduz drasticamente a sobrecarga da pilha de armazenamento. O protocolo NVMe foi criado do zero para paralelismo, suportando múltiplas filas profundas, o que exige significativamente menos ciclos de CPU por operação de I/O (IOPS) do que o protocolo SCSI tradicional.

Comparativo de controladoras de armazenamento virtual

Característica	LSI Logic SAS	VMware Paravirtual (PVSCSI)	Virtual NVMe (vNVMe)
Mecanismo	Emulação de hardware	Paravirtualização (Driver específico)	Paravirtualização otimizada para Flash
Overhead de CPU	Alto (Muitas interrupções)	Baixo (Agrupamento de interrupções)	Muito Baixo (Filas paralelas nativas)
Foco de Uso	Compatibilidade legada	Alta performance (Bancos de dados, IOPS alto)	Datastores All-Flash e NVMe-oF
Profundidade de Fila	Limitada (Geralmente 32-64)	Alta (Até 254 por dispositivo)	Altíssima (Múltiplas filas de 64k)

Validando a redução de latência cruzando métricas de CPU Ready e KAVG no esxtop

A teoria da otimização precisa ser comprovada na prática. Após alterar a controladora de disco de uma VM crítica para PVSCSI ou vNVMe, o administrador deve validar a melhoria utilizando ferramentas de linha de comando do hypervisor, como o esxtop no VMware vSphere.

O objetivo é cruzar as métricas de contenção de CPU com as métricas de latência de storage. Na tela de CPU do esxtop (pressionando a tecla c), devemos observar a métrica %RDY (CPU Ready). Essa métrica indica a porcentagem de tempo que a VM estava pronta para executar instruções, mas teve que esperar pelo agendador do hypervisor. Um %RDY alto (acima de 5% a 10% por vCPU) indica contenção severa.

Ao mesmo tempo, na tela de discos virtuais (pressionando a tecla v), monitoramos a métrica KAVG.

Figura: Representação de um terminal mostrando a queda drástica das métricas de CPU Ready e KAVG após a otimização da controladora.

💡 Dica Pro: Pressione 'v' no esxtop para ver a visão de disco por máquina virtual. Expanda a VM pressionando 'e' e digitando o Group ID (GID). Isso mostrará a latência exata de cada disco virtual (VMDK) associado àquela máquina.

Se a mudança de controladora foi bem-sucedida, você notará dois comportamentos simultâneos:

A métrica KAVG cairá para valores próximos a zero milissegundos, indicando que o hypervisor não está mais lutando para processar as filas de I/O emuladas.
A métrica %RDY e o uso geral de CPU da VM cairão proporcionalmente, provando que os ciclos de processador que antes eram desperdiçados em I/O wait foram finalmente liberados.

O caminho para a eficiência de infraestrutura

A otimização de ambientes virtualizados exige uma mudança de mentalidade. O sintoma visível no sistema operacional raramente aponta para a causa raiz na infraestrutura física. Continuar injetando vCPUs em máquinas virtuais que sofrem de gargalos de storage é uma prática destrutiva que degrada a performance de todo o cluster de servidores.

A adoção de controladoras paravirtualizadas como PVSCSI e a transição para padrões modernos como vNVMe não são apenas "boas práticas" opcionais. Elas são requisitos arquitetônicos fundamentais para extrair o verdadeiro valor de datastores all-flash e redes de armazenamento de alta velocidade. Revise seus templates de implantação hoje mesmo e garanta que o caminho entre o processador e o disco esteja livre de emulações desnecessárias.

Referências & Leitura Complementar

VMware vSphere 8.0 Performance Best Practices (VMware Docs).
Understanding CPU Ready Time and Co-Stop (VMware Knowledge Base).
NVM Express Base Specification (NVMexpress.org / SNIA).
Configuring VMware Paravirtual SCSI (PVSCSI) controllers (VMware KB 1010398).

Por que adicionar mais vCPUs piora a performance de storage da VM?

Mais vCPUs aumentam a dificuldade do hypervisor em agendar os ciclos simultaneamente (fenômeno conhecido como CPU Co-Stop). Isso atrasa o processamento das interrupções de I/O da controladora de disco. Quando o storage responde, a VM demora a perceber, aumentando a latência sentida pela aplicação.

Qual a diferença entre LSI Logic SAS e PVSCSI no consumo de CPU?

A PVSCSI é paravirtualizada e totalmente ciente do hypervisor. Ela descarrega o processamento de I/O e agrupa interrupções, reduzindo drasticamente o overhead de vCPU em cargas de trabalho com alto IOPS. Já a LSI Logic exige emulação pesada de hardware, consumindo ciclos preciosos do host para cada comando de leitura ou gravação.

O uso de controladoras vNVMe reduz o overhead de vCPU?

Sim. A controladora vNVMe foi desenhada especificamente para datastores all-flash modernos. O protocolo NVMe é altamente paralelo, exigindo significativamente menos ciclos de CPU por operação de I/O em comparação com a pilha SCSI tradicional, destravando o verdadeiro potencial de discos de estado sólido.