Núcleos de CPU virtualizados x threads

Temos um sistema host KVM no Ubuntu 9.10 com uma CPU Xeon Quad-core mais recente com hyperthreading. Conforme detalhado na página do produto da Intel , o processador possui 4 núcleos, mas 8 threads. / proc / cpuinfo e htop listam 8 processadores, embora cada um indique 4 núcleos no cpuinfo. O KVM / QEMU também relata 8 VCPUs disponíveis para atribuir aos convidados.

Minha pergunta é: quando estou alocando VCPUs para convidados da VM, devo alocar por núcleo ou por segmento? Como o KVM / QEMU reporta que o servidor possui 8 VCPUs para alocar, devo definir um convidado para usar 4 CPUs, onde anteriormente o configuraria para usar 2 (assumindo 4 VCPUs totais disponíveis)? Eu gostaria de obter o máximo possível do hardware host sem alocar demais.

Atualização: a resposta do Chopper3 é sem dúvida a abordagem correta. No entanto, eu ainda adoraria ouvir especialistas em hardware que pudessem elucidar os aspectos de desempenho de threads versus núcleos ... alguém?

Defina o número mais baixo de vCPUs que seus servidores precisam para desempenhar suas funções, não os aloque demais, ou você pode facilmente desacelerar suas VMs.

Normalmente, o HT funciona bem em cargas de trabalho mais pesadas no IO - a CPU pode agendar mais tarefas de processamento na fila da outra CPU virtual enquanto a primeira CPU virtual aguarda no IO. Na verdade, todos os subsistemas HT o atraem é a alternância de contexto acelerada por hardware - que é o padrão de carga de trabalho que também é usado ao alternar entre VMs. Portanto, o HT (normalmente) reduzirá um pouco a desaceleração quando você tiver mais VMs do que núcleos, desde que cada VM obtenha um núcleo virtual.

A atribuição de várias vCPUs a uma VM pode melhorar o desempenho se os aplicativos na VM forem gravados para segmentação, mas também dificultará a vida do hypervisor; ele precisa alocar tempo em 2 ou 4 CPUs ao mesmo tempo - portanto, se você tiver uma CPU quad-core e uma VM com quad-vCPU, apenas uma VM poderá ser agendada durante esse intervalo de tempo (enquanto pode executar quatro diferentes VMs de vCPU única) de uma vez só).

Isso é bastante complicado. Dependendo das cargas, o HT pode aumentar o desempenho em ~ 30% ou diminuí-lo. Normalmente, aconselho a não alocar mais vCPUs do que você tem núcleos físicos, para uma única VM, mas se a VM estiver bastante inativa (e, é claro, essa VM não precisará de muitas CPUs), ela pode ser dada como vCPUs como você tem threads. Você realmente não quer dar a uma única VM mais vCPUs do que os núcleos agendáveis, é o que estou conseguindo. De qualquer forma, o conselho do @ Chopper3 é correto - não dê à VM mais CPUs v do que o necessário.

Portanto, dependendo de quão carregadas e críticas são suas VMs, você não faz uma avaliação geral, mantém a contagem de núcleos físicos ou atinge a contagem de threads por VM.

Agora, entrando na questão do HT, geralmente é uma coisa boa de se ter, especialmente quando você compromete mais vCPUs em suas VMs do que núcleos físicos ou até threads, porque facilita o agendador do Linux agendar esses vCPUs.

Uma última coisa, com o kvm, uma vCPU atribuída a uma VM é apenas um processo no host, agendado pelo agendador do Linux, para que todas as otimizações normais que você pode fazer aqui se apliquem facilmente. Além disso, a configuração de núcleos / soquetes é exatamente a maneira como esse processo será exibido para o SO convidado da VM, no host ainda é apenas um processo, independentemente de como a VM o vê.

Penso em elaborar a resposta do Chopper3: se os sistemas estiverem na maior parte ociosos da CPU, não atribua um monte de vcpu, se eles são intensos na CPU, tenha muito cuidado para não atribuir uma classificação geral. Você deve poder alocar um total de 8 vCPU sem contenção. Você pode fazer uma localização geral, mas, se o fizer, verifique se nenhum convidado, especialmente um que consome muita CPU, tem 8 vcpu ou você terá contenção. Não sei se o mecanismo do agendador KVM é mais específico do que isso.

O exposto acima é baseado no seguinte entendimento de vCPU versus CPU fixada, mas também na suposição de que o KVM permitirá que um único convidado (ou vários convidados) monopolize toda a CPU real de outras pessoas se você alocar (/ eles) threads suficientes. vCPU ~ encadeamento do host, CPU convidada CPU = núcleo do host, CPU convidada (Não reproduzi com vCPU mista e CPU fixada no mesmo convidado, porque não tenho Hyperthreading.)