Dato che ho una CPU compatibile con Hyper-Threading , mi chiedo, è una cattiva idea assegnare più core di CPU virtuali rispetto al numero di core di CPU fisici come suggerisce il seguente avviso:

Trascrizione:

Più macchine virtuali sono assegnate alla macchina virtuale rispetto al numero di CPU fisiche sul sistema host. È probabile che ciò riduca le prestazioni della tua macchina virtuale. Si prega di considerare di ridurre il numero di CPU virtuali.

Qualcuno può mettere un ragionamento su questo argomento?

Edit1:

La CPU in questione è Intel Core i7-4700HQ, Ark Intel , benchmark CPU

EDIT2:

Supponiamo che non ci siano HW obsoleti, come HDD (invece di un SSD) e / o RAM bassa (16 GB qui, minimo vm.swappiness, 4 GB per questa VM) e così via.

Hardware / sistema operativo / software

Host : Linux Mint 18 Cinnamon 64-bit (completamente aggiornato); Versione del kernel 4.4.0-47-generica

Ospite : Windows 8.1 Pro 64-bit (completamente aggiornato)

Processore : Intel Core i7-4700HQ , (6 MB di cache, 4 core fisici o 8 tramite Hyper-Threading), benchmark CPU

VirtualBox : Versione 5.1.10 r112026 (Qt5.5.1)

Aggiunte agli ospiti : installato e aggiornato

Strumento di benchmark n. 1 : WinRAR versione 5.40 final a 64 bit

Strumento di benchmark n. 2 : VeraCrypt versione 1.19 finale a 64 bit

Preparazione

In entrambi i casi ho aspettato dopo l'avvio fino a quando CPU, RAM, unità disco non hanno raggiunto risultati stabili vicino al punto zero.

Metodo

1. Clonazione della macchina virtuale originale per avere due identiche.
2. Ho, per il secondo passaggio, dal momento che il riavvio disabilitato Antivirus ha sottolineato in fondo a questa risposta e ha aggiornato WinRAR in entrambi i casi da una versione Beta a quella finale.
3. Ho fatto la stessa preparazione indicata in precedenza.
4. La macchina virtuale è stata eseguita in primo piano, senza che sia in esecuzione alcuna altra applicazione affamata di tempo della CPU, ho disabilitato ciò che potevo allo scopo di non influenzare il test.
5. Per includere la potenziale memorizzazione nella cache all'interno o all'esterno del sistema, ho eseguito lo stesso test due volte di conseguenza. Il vantaggio è quasi nessuno.

risultati

WinRAR

1. 4 core => 7.5 minuti (il tempo più breve è meglio)

   

   WinRAR con 4 core abilitati, 1,5GiB elaborati in 7,5 minuti.

2. 8 core => 4,5 minuti (il tempo più breve è meglio)

   

   WinRAR con 8 core abilitati, 1,5GiB elaborati in 4,5 minuti.

veracrypt

1. 4 core => velocità 2.6 GiB / s ( migliore è la velocità più alta)

   

   Veracrypt con 4 core attivati, HW accelerazione AES (AES-NI) Velocità di 2,6 GB / s.

2. 8 core => velocità 3,9 GiB / s ( migliore è la velocità più alta)

   

   Veracrypt con 8 core attivati, HW accelerazione AES (AES-NI) Velocità di 3,9 GB / s.

Conclusione

Ho potuto eseguire tutti i test necessari. Ma immagino che, se questi due, uno dei quali è un test di compressione piuttosto complesso, il secondo è un insieme di test di crittografia piuttosto complessi, quale sarebbe il punto.

Entrambi i benchmark mostrano una marcata differenza. Non vedo motivo di credere che i loro risultati siano inaccurati, poiché ho seguito una preparazione e un metodo piuttosto rigorosi, inoltre questi test hanno avuto luogo nella RAM per escludere il collo di bottiglia dell'I / O. Dal mio punto di vista, l'avvertimento menzionato nella domanda può applicarsi ad alcune condizioni, ma certamente non tutte. Avendo condiviso con voi questi risultati piuttosto notevoli, sono certo che sarete d'accordo con me sul fatto che questo avviso probabilmente non dovrebbe essere preso così seriamente su CPU moderne con Hyper-Threading con l'ultima versione di VirtualBox. Una cosa è certa: non prendermi per la parola e provarla alle tue condizioni, prima di decidere di applicare questa impostazione in modo permanente.

Come progettista del sistema operativo sono completamente d'accordo con il risultato delle misurazioni. La quantità di cazzate prodotte altrove sull'argomento è incredibile.

Vedi il numero di core logici come il numero di thread / processi paralleli che possono essere eseguiti da HW. Ciò si ottiene duplicando, ad esempio, i registri e i puntatori di istruzioni di un core della CPU. Il core della CPU ora decide quale thread (puntatore istruzioni) usare. Deciderà di utilizzare l'altro thread poiché le istruzioni del thread corrente non sono disponibili nella cache e devono essere recuperate ad esempio dalla memoria o dalla cache L3. Questo meccanismo creerà un potenziale miglioramento del 10-30% delle istruzioni / secondi o delle prestazioni della CPU.

Se esegui una singola applicazione con un thread, non sarai in grado di ottenere questo vantaggio, ma se esegui due applicazioni ad alto carico su un vecchio HT Pentium, sarai in grado di ottenere i benefici. Lo stesso vale ovviamente per le applicazioni che hanno più di un thread. Il mio sistema Linux ha 200 thread, quindi sono sempre presenti alcuni vantaggi che dipendono dal carico effettivo. Tutte queste osservazioni si applicano senza virtualizzazione.

Virtualbox limita solo il numero di thread che possono essere eseguiti in parallelo per ogni macchina virtuale (VM), ma l'utilità di pianificazione del processo host modificherà i processori logici e quindi i processori fisici su cui i processi VM vengono eseguiti in modo dinamico. Se si eseguono applicazioni con carico elevato su una macchina virtuale, i core logici aggiuntivi offriranno lo stesso vantaggio del 10% -30%. Il carico può essere una singola applicazione multi-thread o un insieme di diverse applicazioni.

Sui sistemi moderni con VT-x o AMD-V non vi è alcuna penalità di prestazione per massimizzare il numero di core logici, poiché non vi è alcuna penalità di prestazione evidente per l'esecuzione di più macchine virtuali contemporaneamente. Il limite è rappresentato dalle prestazioni del chip della CPU, quindi non è possibile eseguire il rendering dei video su 3 VM contemporaneamente senza rallentare ciascuna VM, poiché devono condividere la stessa CPU fisica.

Il tuo sistema host potrebbe diventare irresponsabile, se esegui il rendering di un video su una VM con tutti i core logici presenti, ma avresti quasi lo stesso problema, se avessi eseguito l'app di rendering sul tuo host. Almeno in VM hai una scelta e potresti risolverlo limitando il carico massimo della CPU all'80% -90% o riducendo il numero di core per questo motivo.

I miei due migliori centesimi sono di non usare mai tutti i core / thread, basta lasciare uno o due come host.

Quindi, nel tuo caso, dai agli ospiti un core sei, mai un ottavo core (perché hai solo 8 thread sull'host).

Se il numero di thread disponibili (da non confondere con i core) sull'host è:

• Se <2, meglio non usare affatto macchine virtuali
• Se 2, utilizzare le macchine virtuali in modalità mono-core o correre un rischio e utilizzare guest dual core
• Se> 2, utilizzare meglio una formula

Per più di due thread tendo ad usare questa formula:

• N = Numero di thread per l'host
• M = Numero di macchine virtuali simultanee che voglio eseguire (presupponendo un equilibrio uguale, lo stesso numero di core guest per ciascun guest)
• Formula = (N-1) / M se l'host ha solo 4 thread o meno
• Formula = (N-2) / M se l'host ha più di 4 thread

La mia esperienza mi dice che è molto più fluido e meno rischioso non superare tale limite di formula.

Avvertenza: non è consentito modificare il numero di core guest durante l'esecuzione del guest, ma è consentito ridurre l'utilizzo della CPU dal 100% al 75% o anche al 50%, non meno errori del guest.

Quindi a volte tendo a dare a sei ospiti 6 sei core su un host a 8 thread (il numero della formula come se fosse un solo ospite anziché due ospiti), ma limitandoli al 50% della velocità della CPU (quindi entrambi gli ospiti possono usare 1 / 2 volte la CPU), ma solo quando so che gli ospiti eseguiranno app con un rapporto di parallelo più grande, come nel caso del confronto / unione di immagini, ecc.