Core di CPU virtualizzati e thread

Abbiamo un sistema host KVM su Ubuntu 9.10 con una nuova CPU Xeon Quad-core con hyperthreading. Come dettagliato nella pagina del prodotto Intel , il processore ha 4 core ma 8 thread. / proc / cpuinfo e htop elencano entrambi 8 processori, anche se ognuno indica 4 core in cpuinfo. KVM / QEMU riporta anche 8 VCPU disponibili da assegnare agli ospiti.

La mia domanda è quando sto assegnando VCPU ai guest VM, dovrei allocare per core o per thread? Dato che KVM / QEMU riporta che il server ha 8 VCPU da allocare, dovrei andare avanti e impostare un guest in modo da utilizzare 4 CPU dove precedentemente avrei impostato l'uso 2 (supponendo che 4 VCPU totali disponibili)? Vorrei ottenere il massimo possibile dall'hardware host senza allocazione eccessiva.

Aggiornamento: la risposta di Chopper3 è senza dubbio l'approccio giusto. Tuttavia, mi piacerebbe comunque sentire gli esperti di hardware là fuori che potrebbero chiarire gli aspetti prestazionali dei thread rispetto ai core ... chiunque?

Imposta il numero più basso di vCPU di cui i tuoi server hanno bisogno per svolgere la loro funzione, non allocarle eccessivamente o potresti rallentare facilmente le tue VM.

In genere, HT funziona bene su carichi di lavoro più pesanti su IO: la CPU può pianificare più attività di elaborazione dalla coda dell'altra CPU virtuale mentre la prima CPU virtuale attende sull'IO. In realtà, tutti i sottosistemi HT sono la commutazione di contesto con accelerazione hardware, che è il modello di carico di lavoro utilizzato anche quando si passa da una macchina virtuale all'altra. Pertanto, HT (di solito) ridurrà un po 'il rallentamento quando si hanno più macchine virtuali che core, a condizione che ogni macchina virtuale ottenga un core virtuale.

L'assegnazione di più vCPU a una VM può migliorare le prestazioni se le app nella VM sono scritte per il threading, ma rende anche la vita più difficile per l'hypervisor; deve allocare tempo su 2 o 4 CPU contemporaneamente, quindi se si dispone di una CPU quad-core e una macchina virtuale quad-vCPU, solo una macchina virtuale può essere programmata durante tale intervallo di tempo (mentre può eseguire 4 macchine virtuali single-vCPU diverse subito).

Questo è piuttosto complicato. A seconda dei carichi, HT può aumentare le prestazioni di circa il 30% o ridurle. Normalmente consiglio di non allocare più vCPU di quante ne possiate core fisici, a una singola VM, ma se la VM è piuttosto inattiva (e, naturalmente, tale VM non richiederà davvero troppe CPU), può essere data come molte vCPU quante sono le discussioni. Non vuoi davvero dare a una singola VM più vCPU di quanti ne abbia i core programmabili . E in ogni caso, il consiglio di @ Chopper3 è giusto: non dare alla VM più v-CPU di quante ne richieda assolutamente.

Quindi, a seconda di quanto siano caricate e critiche le VM, non si esegue alcuna sovrallocazione, non si mantiene il conteggio dei core fisici o si sale fino al conteggio dei thread per VM.

Ora, entrando nella domanda di HT, è generalmente una buona cosa avere, specialmente quando si impegnano più vCPU sulle macchine virtuali di quanti siano i core fisici o persino i thread, perché rende più facile per lo scheduler Linux pianificare tali vCPU.

Un'ultima cosa, con kvm una vCPU assegnata a una VM è solo un processo sull'host, programmato dallo scheduler di Linux, quindi tutte le normali ottimizzazioni che puoi fare qui si applicano facilmente. Inoltre, l'impostazione core / socket è proprio il modo in cui questo processo verrà visualizzato per il SO guest della VM, sull'host è ancora solo un processo, indipendentemente da come lo vede la VM.

Penso di approfondire la risposta di Chopper3: se i sistemi sono principalmente cpu-idle, non assegnare un gruppo di vcpu, se sono cpu-intense, fai molta attenzione a non sovrallocare. Dovresti essere in grado di allocare un totale di 8 vCPU senza contesa. Puoi sovrallocare, ma se lo fai, assicurati che nessun singolo guest, in particolare un guest ad alta intensità di CPU, abbia 8 vcpu, altrimenti avrai contesa. Non conosco il meccanismo dello scheduler KVM per essere più specifico di così.

Quanto sopra si basa sulla seguente comprensione della vCPU rispetto alla CPU bloccata, ma anche sul presupposto che KVM consentirà a un singolo guest (o più guest) di eseguire il hog tutta la CPU effettiva da altri se si allocano (/ loro) abbastanza thread. vCPU ~ thread host, CPU ospite = CPU host, CPU ospite (non ho giocato con vCPU misto e CPU bloccata sullo stesso ospite, perché non ho Hyperthreading.)