Saggezza attuale su SQL Server e Hyperthreading?

Molti articoli disponibili (vedi l'articolo SQL 2000 originale di Slava Oks e l'aggiornamento SQL 2005 di Kevin Kline ) raccomandano di disabilitare l'hyperthreading su server SQL o almeno di testare il tuo carico di lavoro specifico prima di abilitarlo sui tuoi server.

Questo problema sta gradualmente diventando meno rilevante poiché i veri processori multi-core sostituiscono quelli hyperthreaded, ma qual è la saggezza attuale su questo problema? Questo consiglio cambia con SQL 2005 a 64 bit o SQL 2008 o Windows Server 2008?

Idealmente, questo dovrebbe essere testato in anticipo in un ambiente di gestione temporanea, ma per quanto riguarda i server che sono già entrati in produzione con HT abilitato? Come posso sapere se i problemi di prestazioni che stiamo riscontrando potrebbero essere correlati a HT? Esiste una combinazione specifica di contatori di perfoni che potrebbe indirizzarmi in quella direzione, al contrario di tutte le altre cose che normalmente perseguo quando lavoro per migliorare le prestazioni di SQL?

Edit : Questo è particolarmente attraente a causa del potenziale per un tutta la linea di miglioramento per alcuni dei miei server ad alta cpu, ma il cliente sta andando a voler vedere qualcosa di concreto che mi aiuta a identificare quali server potrebbe davvero beneficiare di disattivazione hyperthreading. Naturalmente, la risoluzione dei problemi convenzionale delle prestazioni è in corso, ma a volte qualche piccolo aiuto.

In SQLOS viene creato uno scheduler per ciascun processore logico visualizzato da SQL Server. Con hyperthreading abilitato, ciò equivale a raddoppiare gli scheduler. Uno degli scopi di SQLOS è ridurre al minimo e prevenire il cambio di contesto, motivo per cui viene creato un solo scheduler per ciascun processore logico. Una volta che SQLOS ha creato gli scheduler, il numero totale di lavoratori viene diviso tra gli scheduler. SQLOS implementa una forma di pianificazione cooperativa in quanto i lavoratori producono lo scheduler in quanto richiede risorse non disponibili o raggiungono la sua esecuzione quantistica consentendo ad altri lavoratori di eseguire sullo scheduler. Ciò mantiene il cambio di contesto al minimo poiché lo scheduler sta facendo il lavoro e sono legati uno per uno.

Comprendendo questo background, l'hyperthreading funziona in qualche modo al contrario di come SQLOS è specificamente progettato per funzionare. In particolare, il parallelismo può essere problematico con l'hyperthreading e può comportare elevate attese CXPACKET poiché SQLOS potrebbe tentare di eseguire una query in DOP 8 su ciò che è in realtà un sistema DOP 4. Se l'utilizzo della CPU è basso, potresti non accorgertene, ma maggiore è l'utilizzo della CPU, più problematica potrebbe diventare. Di recente ho avuto una discussione su Twitter al riguardo, e il consenso era "Dipende" dal fatto che potesse aiutare o meno.

Se hai molti segnali in attesa sul tuo server, ma hai un basso utilizzo della CPU, potresti vedere i vantaggi che abilitano l'hyperthreading che raddoppierà i tuoi programmatori interni e diffonderà di più gli operai, il che significa che non aspetteranno di essere eseguiti nella coda eseguibile quanto a lungo. Tuttavia, se il tuo carico di lavoro utilizzava fortemente il parallelismo, ottieni pesanti attese CXPACKET in sys.dm_os_wait_stats, potresti provare a disabilitare l'hyperthreading per vedere se riduce le tue attese.

In realtà l'hyperthreading non è scomparso, i nuovi chip quad-core Nehalem di Intel hanno l'hyperthreading. Per quanto sia raccomandato o meno, "dipende" come sempre, ogni situazione è probabilmente diversa.

È improbabile che HT sia la causa principale di qualsiasi problema di prestazioni, ma senza ulteriori dettagli, è difficile dire cosa sia. Esegui alcune sessioni perfmon, con frequenze di campionamento abbastanza lunghe, come una volta ogni 30 - 60 secondi, e ottenendo CPU, lunghezza della coda del disco sui dati e dischi del registro, l'aspettativa di vita della pagina è una buona misura se hai abbastanza memoria. Se hai costantemente più dell'80% di CPU o se le code del tuo disco sono a tre cifre, hai riscontrato il problema.

SQL Server 2000 su un HP DL360 G3:

Ho eseguito un rapporto sei volte e ho gettato via la fuga iniziale e registrato gli ultimi cinque. Ho quindi riavviato nuovamente il database e ho riacceso Hyperthreading. Ho eseguito il rapporto altre sei volte, conservando i dati delle ultime cinque corse.

osservazioni:

• La disattivazione dell'hyperthreading non costa 2 volte nell'uso apparente della CPU, solo circa 1,5 volte.
• La disattivazione dell'hyperthreading rende un rapporto casuale di lunga durata eseguito il 5,2% più veloce (in media).

Esecuzioni ripetute del rapporto:

Con Hyperthreading: 20,95%, 21,1%, 21,9%, 20,8%, 20,5%
Tempi di esecuzione in ms: 20282, 21141, 20188, 22297, 25282. Media 21838

Senza hyperthreading: 29,4%, 28,2%, 29,1%, 28,2%, 27,1%
Tempi di esecuzione in ms: 20125, 20156, 19937, 21656, 21656. Media 20706