Defina o menor número de vCPUs que seus servidores precisam para executar sua função, não aloque-os excessivamente ou você poderá facilmente reduzir a velocidade suas VMs.
Temos um sistema host KVM no Ubuntu 9.10 com um novo Xeon Quad-core com hyperthreading. Conforme detalhado na página do produto da Intel , o processador tem 4 núcleos, mas 8 segmentos. / proc / cpuinfo e htop ambos os processadores da lista 8, embora cada um declare 4 núcleos em cpuinfo. O KVM / QEMU também relata 8 VCPUs disponíveis para designar aos convidados.
Minha pergunta é quando estou alocando VCPUs para convidados da VM, devo alocar per-core ou por thread? Como o KVM / QEMU relata que o servidor tem 8 VCPUs para alocar, devo ir em frente e configurar um convidado para usar 4 CPUs onde anteriormente eu teria configurado para usar 2 (supondo que 4 VCPUs totais estivessem disponíveis)? Eu gostaria de obter o máximo possível do hardware host sem alocação excessiva.
Atualização: A resposta de Chopper3 é, sem dúvida, a abordagem correta. No entanto, eu ainda adoraria ouvir de qualquer especialista em hardware por aí que poderia elucidar os aspectos de desempenho de threads versus núcleos ... alguém?
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. Realmente, todos os subsistemas de HT fazem com que você seja a comutação de contexto acelerada por hardware - que é o padrão de carga de trabalho que também é usado ao alternar entre as VMs. Portanto, o HT (geralmente) reduzirá um pouco a lentidão quando você tiver mais VMs do que núcleos, desde que cada VM tenha um núcleo virtual.
Atribuir várias vCPUs a uma VM pode melhorar o desempenho se os aplicativos na VM forem gravados para encadeamento, mas também dificulta a vida do hipervisor; ele precisa alocar tempo em 2 ou 4 CPUs de uma só vez - portanto, se você tiver uma CPU quad-core e uma VM quad-vCPU, somente uma VM poderá ser programada durante essa timeslice (embora possa executar 4 VMs individuais de vCPU diferentes de uma vez).
Isso é bastante complicado. Dependendo das cargas, o HT pode aumentar o desempenho em ~ 30% ou diminuí-lo. Normalmente, eu aconselho a não alocar mais vCPUs do que os núcleos físicos, a uma única VM, mas se a VM estiver bastante inativa (e, é claro, essa VM realmente não exigirá muitas CPUs), ela pode ser entregue como muitos vCPUs como você tem threads. Você realmente não quer dar uma única VM mais vCPUs do que você tem núcleos agendáveis é o que eu estou recebendo. E em qualquer caso, o conselho do @Chopper3 está certo - não dê à VM mais CPUs v do que absolutamente requer.
Portanto, dependendo de quão carregadas e críticas são as suas VMs, você não fica sobrecarregado de forma alguma, mantém a contagem de núcleos físicos ou vai tão alto quanto a contagem de threads por VM.
Agora, entrando na questão do HT, geralmente é bom ter isso, especialmente quando você consolida mais vCPUs em suas VMs do que em núcleos físicos ou mesmo em encadeamentos, porque isso facilita o agendamento do Linux essas vCPUs.
Uma última coisa, com o kvm a vCPU atribuído a uma VM, é apenas um processo no host, agendado pelo escalonador do Linux, portanto, todas as otimizações normais que você pode fazer aqui se aplicam facilmente. Além disso, a configuração dos núcleos / soquetes é apenas a maneira como esse processo será exibido para o sistema operacional convidado da VM. No host, ele ainda é apenas um processo, independentemente de como a VM o vê.
Eu penso em elaborar a resposta do Chopper3: se os sistemas são quase todos cpu-idle, não atribua um monte de vcpu, se eles são intensos em cpu, tenha muito cuidado para não sobrecarregar. Você deve poder alocar um total de 8 vCPU sem contenção. Você pode aumentar a alocação, mas se fizer isso, certifique-se de que nenhum convidado, especialmente um convidado intensivo de CPU, tenha 8 vcpu, ou você terá contenção. Eu não sei o mecanismo do agendador KVM para ser mais específico do que isso.
O acima é baseado na seguinte compreensão de vCPU versus CPU fixada, mas também a suposição de que o KVM permitirá que um único convidado (ou vários convidados) roube toda a CPU real de outros se você alocá-la (/ eles) o suficiente tópicos. vCPU ~ thread de host, CPU guest CPU = host Core, CPU convidado (Não joguei com vCPU misto e coloquei CPU no mesmo convidado, porque não tenho Hyperthreading.)