back_button
Considerações sobre CPU e Memória
Tipos de CPU
A configuração do tipo de CPU permite que você escolha com base na geração e nos recursos da CPU, garantindo funcionalidade consistente mesmo que a infraestrutura de nuvem privada use CPUs diferentes. No entanto, a migração ao vivo entre CPUs Intel e AMD não é garantida.
Selecionar “host” na parte inferior do menu suspenso usará a mesma CPU do host físico, maximizando a eficiência. Porém, isso impede a migração ao vivo entre hosts de gerações diferentes, o que pode causar problemas se novas unidades HRPC forem adicionadas ao data center virtual no futuro.
A maioria dos sistemas operacionais modernos funciona com x86-64-v2, que suporta conjuntos de instruções como SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT e CMPXCHG16B. A opção x86-64-v2-aes inclui instruções de criptografia AES, permitindo um desempenho mais rápido para softwares de criptografia.
Escolher x86-64-v3 habilita o uso de instruções AVX e AVX2, enquanto x86-64-v4 adiciona suporte para instruções AVX-512.
Todos os modelos de nuvem privada HRPC a partir do 6Gt suportam x86-64-v4.
A tabela a seguir resume essas informações:
Processador | x86-64-v1 | x86-64-v2 | x86-64-v2-aes | x86-64-v3 | x86-64-v4 |
---|---|---|---|---|---|
Instruções Suportadas | Conjunto de instruções base x86-64 | SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CMPXCHG16B | x86-64-v2 + AES | AVX, AVX2, BMI1, BMI2, FMA, MOVBE | Família AVX-512 (AVX-512F, AVX-512CD, AVX-512DQ, AVX-512BW, AVX-512VL, etc.) |
Intel Xeon | Série Intel Xeon 3000/5000/7000 (1ª Geração) | Série Intel Xeon 5500 (Nehalem) e posteriores | Série Intel Xeon 5600 (Westmere) e posteriores | Intel Xeon E3 v3 (Haswell) e posteriores, Intel Xeon E5/E7 v3 (Haswell-EP/EX) e posteriores, Processadores Intel Xeon Escaláveis 1ª Geração (Skylake-SP) e posteriores | Processadores Intel Xeon Escaláveis 2ª Geração (Cascade Lake-SP) e posteriores, Processadores Intel Xeon Escaláveis 3ª Geração (Ice Lake-SP) |
AMD Opteron | Série AMD Opteron 100/200/800 (SledgeHammer) | Série AMD Opteron 4200/6200 (Bulldozer) e posteriores | Série AMD Opteron 4300/6300 (Piledriver) e posteriores | Não aplicável | Não aplicável |
AMD EPYC | Não aplicável | 1ª Geração AMD EPYC (Naples) | 1ª Geração AMD EPYC (Naples) | Série AMD EPYC 7002 (Rome) e posteriores | Série AMD EPYC 7003 (Milan) e posteriores |
Gerenciamento de Memória KVM e Driver de Ballooning
Em resumo, o driver de Ballooning é desnecessário na infraestrutura HRPC e é recomendado que seja desativado.
No KVM, definir o valor de “Memória Mínima” igual ao valor de “Memória” parece criar uma alocação de memória fixa. No entanto, devido à natureza do gerenciamento de memória do Linux, a memória alocada e o uso real diferem. O sistema reserva memória na inicialização, mas ela só é usada ativamente quando dados são gravados nela, tornando o uso de memória efetivamente dinâmico.
Isso pode ser observado na seção “Uso de Memória” do resumo do host ou da máquina virtual. Por exemplo, uma máquina virtual com 32GiB de memória atribuída pode usar apenas 13,56GiB na realidade.

Em um sistema Proxmox VE típico, máquinas virtuais podem ser criadas enquanto houver memória disponível. No entanto, se o “Uso de Memória” exibido parecer baixo, os administradores podem alocar mais memória do que a fisicamente disponível, levando a um excesso de comprometimento de memória. Quando as máquinas virtuais demandam mais memória repentinamente, isso pode causar instabilidade, potencialmente acionando o Out-Of-Memory Killer no sistema operacional do host, que pode encerrar processos críticos do sistema aleatoriamente.
O HRPC 6Gf é projetado para uso empresarial com foco em isolamento, garantindo que máquinas virtuais não possam ser criadas além da capacidade de memória disponível.
Se a máquina host ficar sem memória e o dispositivo de Ballooning estiver ativado, o Driver de Ballooning força o sistema operacional convidado a liberar memória desnecessária (por exemplo, caches de disco, páginas sujas), devolvendo-a ao sistema operacional do host. Esse processo aumenta a carga da CPU e as operações de E/S, levando a atrasos e instabilidade, especialmente em sistemas de alta disponibilidade (HA) sensíveis à latência.
Como mencionado anteriormente, o hipervisor personalizado no HRPC 6Gf impede a criação desnecessária de máquinas virtuais, tornando o dispositivo de Ballooning amplamente irrelevante neste ambiente.