Tuning de VM no Proxmox: tipo de CPU, NUMA e ballooning

VM lenta raramente é culpa do hipervisor. Na maioria dos casos que atendemos, a causa é uma configuração padrão inadequada à carga, um recurso superdimensionado que virou problema, ou contenção no host que ninguém está medindo.

Este texto cobre os ajustes que produzem diferença real, na ordem de impacto — e, igualmente importante, os que não valem a pena mexer.

Antes de qualquer ajuste: meça no lugar certo

O erro de diagnóstico mais comum é olhar as métricas de dentro da VM.

O sistema convidado não enxerga contenção do host. Ele reporta CPU baixa enquanto espera fatia de processamento que não recebe; reporta I/O lento sem saber que o storage compartilhado está saturado por outra VM. A VM não tem como saber que está esperando.

O que olhar no host:

• Tempo de espera por CPU (steal time), que indica que a VM está pronta para executar e não recebe fatia.
• Latência de I/O do storage, não só a taxa de transferência. Latência alta com vazão baixa é o sinal clássico de saturação.
• Pressão de memória e uso de área de troca no nó.
• Uso da rede nas interfaces de storage e de VM, separadamente.

Regra: o host diz a verdade; o convidado diz a percepção. Compare os dois.

Tipo de CPU

O ajuste de maior impacto e o mais mal configurado.

O padrão histórico é conservador e esconde do convidado instruções que ele usaria — incluindo aceleração de criptografia, que faz diferença mensurável em qualquer carga com TLS.

A escolha certa:

• Cluster homogêneo: host, e aproveite tudo.
• Cluster heterogêneo: um modelo comum compatível com o nó mais antigo. Perde-se pouco e ganha-se liberdade de migrar.

E o detalhe que já custou muita manutenção emergencial: mudar o tipo de CPU exige desligar e ligar a VM. Reiniciar pelo sistema convidado não basta.

Topologia: sockets e cores

O Proxmox permite definir quantos sockets e quantos cores por socket a VM enxerga. A regra é simples e frequentemente violada:

Use um socket com vários cores, salvo quando a VM for maior que um nó NUMA físico.

Vários sockets virtuais fazem o sistema convidado assumir uma topologia NUMA que não corresponde à realidade, e ele passa a tomar decisões de agendamento ruins. Também há efeito de licenciamento: alguns produtos licenciam por socket.

NUMA: quando importa de verdade

Servidor com mais de um processador físico tem memória dividida entre eles. Acessar a memória "do outro processador" é mais lento — significativamente mais lento em cargas sensíveis à latência de memória.

Quando isso importa: VM grande, com mais memória ou mais núcleos do que cabe em um nó NUMA físico. Nesse caso, habilite NUMA na VM, para que o convidado enxerga a topologia e possa agendar de forma coerente.

Quando não importa: VM pequena que cabe folgadamente em um nó NUMA. Habilitar não traz ganho.

Em servidores com muitos núcleos por socket, a maioria das VMs cabe em um nó NUMA — então esse ajuste é para exceções, não para a regra. Vale saber que ele existe e reconhecer o sintoma: VM grande com desempenho inconsistente e uso de memória distribuído de forma estranha.

Memória: o balão custa mais do que parece

O balão de memória permite ao Proxmox recuperar memória não utilizada da VM. É útil para adensar ambientes de laboratório e desenvolvimento. Em produção, exige critério.

O problema: sistemas operacionais usam memória livre como cache de disco. Do ponto de vista do balão, essa memória "não está em uso" — e recuperá-la significa tirar o cache, fazendo o sistema ir ao disco para o que estava em memória. Você troca RAM por I/O, que é o oposto do objetivo.

A orientação:

• Produção crítica — banco de dados, servidor de aplicação, Windows Server: memória fixa, sem balão.
• Desenvolvimento e homologação: balão com faixa razoável, para adensar.
• Nunca overcommit agressivo de memória entre VMs de clientes ou cargas críticas. Memória é o recurso que menos tolera, e a degradação é imediata.

E mantenha folga no nó. Host que começa a usar área de troca degrada todas as VMs simultaneamente, com sintoma difuso e diagnóstico demorado.

Disco: as opções que mudam desempenho

• Controladora VirtIO SCSI single é a recomendação atual, com melhor paralelismo.
• Fila de I/O dedicada melhora cargas com muitas operações concorrentes.
• Modo de cache. O padrão conservador é seguro. Modos agressivos aumentam desempenho e assumem risco de perda de escrita em queda de energia — decisão que exige entender a troca, nobreak confiável e, mesmo assim, raramente vale em produção.
• Descarte de blocos habilitado, com o disco marcado como SSD quando o storage é SSD. Sem isso, em thin provisioning o disco só cresce e nunca devolve espaço apagado.
• Limites de IOPS por VM em ambiente compartilhado. Não é otimização da VM — é proteção das vizinhas contra uma que faz indexação pesada.

Rede

• Modelo VirtIO, sempre. Placa emulada é ordens de grandeza pior.
• Múltiplas filas para VMs com tráfego alto e vários núcleos, permitindo distribuir o processamento de rede.
• Limite de banda por VM em ambiente multi-cliente.
• Rede de VM separada das redes de storage, cluster e gestão.

O que não vale a pena

Igualmente importante:

• Fixar VMs a núcleos específicos (pinning). Só faz sentido em cargas muito específicas e de latência extrema. Na maioria dos casos, atrapalha o agendador e reduz a flexibilidade do cluster.
• Páginas grandes de memória. Ganho pequeno na maioria das cargas, complexidade real na operação.
• Modo de cache agressivo para ganhar desempenho em produção sem entender o risco.
• Dar mais núcleos do que a aplicação usa. Mais núcleos virtuais do que a carga aproveita piora o desempenho: o hipervisor precisa agendar todos eles, e a contenção aumenta. Aplicação de thread única não fica mais rápida com 16 núcleos — fica mais lenta de agendar.

Esse último item merece destaque, porque contraria a intuição e é muito comum. Dimensione pelo uso medido, não por generosidade.

O roteiro de diagnóstico

Quando uma VM está lenta:

1. Meça no host: espera por CPU, latência de I/O, pressão de memória, uso de rede.
2. Verifique o tipo de CPU — conservador demais?
3. Verifique o balão — a VM está paginando?
4. Verifique o disco: VirtIO SCSI? Descarte habilitado? Storage saturado?
5. Verifique a rede: modelo VirtIO? Interface compartilhada com storage?
6. Verifique superdimensionamento de núcleos.
7. Só então olhe dentro da VM: processo consumindo, atualização em segundo plano, antivírus varrendo, aplicação mal configurada.

Na nossa experiência, os itens 1 a 4 respondem pela grande maioria dos casos.

Erros comuns

• Diagnosticar lentidão pelas métricas do convidado.
• Deixar o tipo de CPU no padrão conservador em produção.
• Usar host em cluster heterogêneo e travar a migração.
• Descobrir que mudar o tipo de CPU exige desligar a VM no dia da manutenção.
• Vários sockets virtuais sem necessidade.
• Balão ativo em banco de dados e em servidor Windows.
• Overcommit agressivo de memória entre cargas críticas.
• Disco emulado em vez de VirtIO SCSI.
• Descarte de blocos desabilitado, com disco que só cresce.
• Nenhum limite de IOPS, com uma VM degradando todas as vizinhas.
• Dar mais núcleos do que a aplicação aproveita.
• Fixar núcleos e páginas grandes sem medir ganho.
• Host operando sem folga, usando área de troca.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, fazemos a revisão de desempenho com medição no host e no convidado: tipo e topologia de CPU ajustados ao parque e ao crescimento, memória dimensionada com a política de balão correta por tipo de carga, disco e rede com os modelos e as opções certas, limites por VM em ambiente compartilhado e a identificação de superdimensionamento — que costuma devolver capacidade sem comprar nada. Entregamos o antes e depois medido, não impressão.

Suas VMs estão lentas e o hardware parece ocioso? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.