Hyper-V e Hyper-threading: attivato o disattivato?

Con le nuove CPU Xeon che supportano Hyper-threading, qual è la saggezza attuale per quanto riguarda l'utilizzo (o meno) su una macchina host Hyper-V?

Inizialmente avevo l'impressione che accenderlo in un ambiente host virtuale potesse essere dannoso in quanto le CPU "extra" non erano dei veri core. Tuttavia, ho anche letto commenti (non confermati) sulla falsariga di MS che fa un duro lavoro per far funzionare Hyper-V in un ambiente Hyper-threading.

Qualcuno ha qualche solida informazione o esperienza in questo senso? Saluti!

Il vecchio problema con Hyper-Threading in Virtual Server 2005, senza diventare eccessivamente tecnico, è che la cache della CPU è stata avvelenata, cioè non ha memorizzato nella cache quasi nulla perché i contesti di ciò che stava accadendo su ogni thread non erano correlati - facendoli competere per il cache su chip.

I chip più recenti hanno cache più grandi e più intelligenti, quindi questo è meno un problema.

È l'ideale per avere acceso o spento? Dipende molto dal carico di lavoro. Se entrambi i thread eseguono la stessa VM e la stessa attività, sarebbe quasi sicuramente un GRANDE vantaggio avere. Se stessero facendo cose non correlate con un sacco di I / O RAM casuali (ad esempio diverse VM diverse), renderebbe disponibile solo metà della cache del chip per ognuno - che in teoria potrebbe essere più lento - In realtà raramente lo è più.

Se si dispone di chip di vecchia generazione, è possibile che si desideri verificare le dimensioni della cache dei chip: nella virtualizzazione, la cache più grande consente di ottenere il meglio. La RAM è davvero MOLTO più lenta delle CPU, ma non è così vicina come le unità disco.

NOTA: Quello che stai leggendo che dice "spegni" è stato trovato riguardo ai chip che erano single core con Hyper-Threading - Ad esempio questa era la risposta ufficiale nel giorno (2005/2006?) - http: //www.VirtualServerFAQ .com / tiki-index.php? page = VirtualServerHostDualCore

Steve Radich http://www.VirtualServerFAQ.com

Secondo Windows IT Pro, vuoi lasciarlo acceso:

• John Savill, WindowsITPro.com, 2009-03-08, D. L'hyper-threading influisce su Hyper-V? (Archiviato qui .)

R. Il nuovo processore Intel Core i7 a quattro core consente l'hyper-threading, che divide ciascun core del processore in due core virtuali per (potenzialmente) migliorare le prestazioni.

Il problema con Hyper-V e hyper-threading è che si assegna un numero di core del processore a ciascuna macchina virtuale (VM). Immagina di assegnare un processore ciascuno a due macchine virtuali guest dalla console di gestione Hyper-V, pensando che ciascuno utilizzerà un core separato. Che cosa succede se l'hypervisor assegna ciascuna VM allo stesso core fisico, con ciascuna che ottiene un core virtuale? Potresti ottenere prestazioni pessime e tre core fisici che non fanno molto, dove ti piacerebbe che ogni VM avesse il proprio core fisico.

Fortunatamente, non è così. Microsoft ha lavorato molto su Hyper-Threading e Hyper-V. Essenzialmente, sebbene l'Hyper-Threading possa aiutare le prestazioni a volte, non danneggerà mai le prestazioni, quindi l'Hyper-Threading dovrebbe essere abilitato.

I programmi che sono a conoscenza dell'hyperthreading sono in grado di distinguere tra un nucleo fisico e un nucleo logico (virtuale) e allocare le risorse di conseguenza.

L'hyperthreading riduce il costo del cambio di contesto consentendo la memorizzazione degli stati di due processi in un dato momento, anziché un solo stato alla volta. Il cambio di contesto è generalmente considerato molto costoso, perché è necessario caricare l'intero stato di un processo nella CPU. Ciò significa che se è in esecuzione un processo ad alta intensità di CPU, la CPU hyperthreaded può passare frequentemente tra quel processo e altri senza incorrere in gran parte delle prestazioni.

Il vantaggio di eseguire server virtuali è che è possibile creare un ampio pool di risorse che possono essere allocate in tempo reale a diversi server, se necessario. Ciò include la riallocazione dei core della CPU e il bilanciamento del carico tra tutti i core disponibili. Se l'hypervisor non conosce la differenza tra un core fisico e un core logico, allora hai ragione: alcuni core fisici possono rimanere inattivi mentre altri sono fissati al 100% di utilizzo della CPU mentre entrambi i loro core logici sono in competizione per CPU tempo. Tuttavia, se l'hypervisor è in grado di distinguere tra core fisici e logici, tenterà di bilanciare il carico della CPU tra le CPU fisiche prima di allocare più processi a due core logici che appartengono allo stesso core fisico.

Non ho studiato il problema in dettaglio, ma Microsoft non consiglia l'utilizzo dell'hyperthreading con Exchange 2010 a causa di problemi di "pianificazione e monitoraggio della capacità". Potresti voler testare i tuoi carichi di lavoro prima di scegliere una configurazione o l'altra.

Hyperthreading: Wow, processori gratuiti!

Spegnilo. Mentre le moderne implementazioni del multithreading simultaneo (SMT), noto anche come hyperthreading, possono assolutamente migliorare il throughput della CPU per la maggior parte delle applicazioni, i vantaggi di Exchange 2013 non superano gli impatti negativi. Si scopre che può esserci un impatto significativo sull'utilizzo della memoria sui server Exchange quando l'hyperthreading è abilitato a causa del modo in cui il garbage collector del server .NET alloca gli heap. Il garbage collector del server esamina il numero totale di processori logici all'avvio di un'applicazione e alloca un heap per processore logico. Ciò significa che l'utilizzo della memoria all'avvio per uno dei nostri servizi che utilizzano il garbage collector del server sarà vicino al doppio con l'hyperthreading attivato rispetto a quando è spento. Questo significativo aumento della memoria, insieme all'analisi dell'effettivo aumento della velocità effettiva della CPU per i carichi di lavoro di Exchange 2013 nei test di laboratorio interni ci ha portato a una raccomandazione delle migliori pratiche che l'hyperthreading dovrebbe essere disabilitato per tutti i server Exchange 2013. I benefici non superano l'impatto negativo.

Copiato da: http://blogs.technet.com/b/exchange/archive/2013/05/06/ask-the-perf-guy-sizing-exchange-2013-deployments.aspx