Como projetar / medir espera de host físico com convidados de vários núcleos no ESXi

Question

Ouvi dizer que, se você tiver um convidado com N núcleos virtuais no ESXi, o hipervisor aguardará até que N processadores lógicos totais no host fiquem disponíveis simultaneamente antes de delegar o trabalho do convidado ao hardware. Portanto, o conselho é que você deve considerar cuidadosamente o aumento do guest por X núcleos, a menos que você realmente precise dos ciclos de processamento, pois você aumentará essa espera proporcionalmente a X, e você quer garantir que seu ganho com a adição de vcpus supere o custo deste aumento de atraso.

No exemplo extremo, suponha que os hosts ESXi hA e hB possuam hardware e configurações idênticas, e cada um tenha um único convidado (gA e gB, respectivamente) e os convidados sejam idênticos ao fato de que gA possui 1 cpu virtual e gB 2. Se você colocar a mesma carga de trabalho (não paralelizável) em ambos os hosts, o gA “deve” competir com a tarefa “mais rápido”.

1. O atraso de espera do proc é real? Confirmavel pela documentacao do VMWare?
2. Se é real (e não é óbvio a partir da documentação fornecida), existem equações para medir o impacto projetado de vcpu convidado aumenta antecipadamente? Ferramental para medir que tipo de impacto no mundo real o atraso já está tendo?

Se for relevante, o problema do mundo real que está provocando esta pergunta é que temos um MS SQL Server 2014 com 4 núcleos que rodam em média 60% de capacidade durante o dia com picos regulares para 100% e estamos tendo um debate interno sobre seja inteligente aumentar o número de convidados para 6 ou 8 núcleos para aliviar alguns problemas de desempenho que estamos enfrentando. O host tem (não sei o modelo, apenas as especificações) hexadecimal Intel de soquete duplo a 2,6 GHz com hyper-threading - portanto, 24 núcleos lógicos por host.

    

Answer 1

O Hyper-threading está mentindo sobre o número de núcleos para obter um aumento de alguns por cento. Você não tem 24 núcleos, você tem 12. Embora, eu me sentiria um pouco melhor em usar totalmente esses 12 núcleos para convidados com hyper-threading.

Quando um convidado ultrapassa o tamanho de um nó, você terá efeitos NUMA ao acessar CPUs remotas ou RAM. Para esses soquetes hex-core, definitivamente pela vCPU 8. Eles também se aplicam a sistemas operacionais no servidor físico sem um hipervisor. Provavelmente gerenciável, dado ESXi e MS SQL ter dimensionado muito maior. Apenas saiba que há retornos decrescentes.

Estrito co-agendamento, onde todas as vCPUs de uma VM são interrompidas se houver uma inclinação de agendamento, não foi usado desde o ESX 2 . O co-agendamento descontraído é mais uma decisão por vCPU. Você pode avaliar se as CPUs estão progredindo mais do que outras por % CSTP em esxtop .

Qualquer que seja o planejador, para o throughput máximo e a latência mínima, não substitua a vCPU. Esses hexágonos duplos recebem hóspedes totalizando 12 vCPU. Não há espera por CPU ociosa quando você efetivamente tem alguma dedicada ao convidado.

    

Answer 2

Há muitos conselhos ruins sobre VMware e práticas recomendadas extintas por aí.

Até mesmo o site da VMware promove soluções desatualizadas devido à falta de SEO.

Mas o modo correto de avaliar isso é usar uma ferramenta como vSphere Realize Operations Manager (vROPs) para obter uma recomendação de dimensionamento com base na sua atividade real.

Caso contrário, apenas aumente e teste o impacto. Vá para 5 vCPU e meça. Então 6 vCPU ... etc.

Além disso, leia um dos livros do Technical Deep Dive para entender melhor a alocação de recursos: link

Exemplo: