La disabilitazione dell'hyperthreading migliorerà le prestazioni sulla nostra installazione di SQL Server

Correlato a: Saggezza attuale su SQL Server e Hyperthreading

Di recente abbiamo aggiornato il nostro server di database Windows 2008 R2 da un X5470 a un X5560 . La teoria è che entrambe le CPU hanno prestazioni molto simili, semmai l'X5560 è leggermente più veloce.

Tuttavia, le prestazioni di SQL Server 2008 R2 sono state piuttosto scarse nell'ultimo giorno e l'utilizzo della CPU è stato piuttosto elevato.

L'aspettativa di vita della pagina è enorme, stiamo ottenendo quasi il 100% di hit della cache per le pagine, quindi la memoria non è un problema.

Quando ho corso:

SELECT * FROM sys.dm_os_wait_stats 
order by signal_wait_time_ms desc

Ho ottenuto:

wait_type waiting_tasks_count wait_time_ms max_wait_time_ms signal_wait_time_ms
-------------------------------------------------- ---------- -------------------- -------------------- -------------------- --------------------
XE_TIMER_EVENT 115166 2799125790 30165 2799125065
REQUEST_FOR_DEADLOCK_SEARCH 559393 2799053973 5180 2799053973
SOS_SCHEDULER_YIELD 152289883 189948844 960 189756877
CXPACKET 234638389 2383701040 141334 118796827
SLEEP_TASK 170743505 1525669557 1406 76485386
LATCH_EX 97301008 810738519 1107 55093884
LOGMGR_QUEUE 16525384 2798527632 20751319 4083713
WRITELOG 16850119 18328365 1193 2367880
PAGELATCH_EX 13254618 8524515 11263 1670113
ASYNC_NETWORK_IO 23954146 6981220 7110 1475699

(10 righe interessate)

Ho anche corso

-- Isolate top waits for server instance since last restart or statistics clear
WITH Waits AS (
   SELECT 
        wait_type, 
        wait_time_ms / 1000. AS [wait_time_s],
        100. * wait_time_ms / SUM(wait_time_ms) OVER() AS [pct],
        ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS [rn]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE',
    'SLEEP_TASK','SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR','LOGMGR_QUEUE',
    'CHECKPOINT_QUEUE','REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH',
    'BROKER_TASK_STOP','CLR_MANUAL_EVENT','CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE',
    'FT_IFTS_SCHEDULER_IDLE_WAIT','XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN'))

SELECT W1.wait_type, 
    CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
    CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
    CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2 ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 95; -- percentage threshold

E ottenuto

wait_type wait_time_s pct running_pct
CXPACKET 554821.66 65.82 65.82
LATCH_EX 184123.16 21.84 87.66
SOS_SCHEDULER_YIELD 37541.17 4.45 92.11
PAGEIOLATCH_SH 19018.53 2.26 94.37
FT_IFTSHC_MUTEX 14306.05 1.70 96.07

Ciò mostra enormi quantità di tempo nella sincronizzazione di query che coinvolgono il parallelismo (CXPACKET elevato). Inoltre, molte di queste domande sui problemi vengono eseguite aneddoticamente su più core (non abbiamo suggerimenti MAXDOP in nessun punto del nostro codice)

Il server non è stato caricato per più di un giorno circa. Stiamo riscontrando una grande varianza con le esecuzioni delle query, in genere molte query sembrano essere più lente rispetto al nostro precedente server DB e la CPU è davvero elevata.

La disabilitazione dell'hyperthreading può aiutare a ridurre l'utilizzo della CPU e aumentare la velocità effettiva?

Sento ancora che testare il tuo carico di lavoro specifico , secondo la risposta originale, è l'unico modo per essere sicuri. Non è una risposta ideale quando si sta tentando di mettere a punto un sistema di produzione (quindi chiederei se fosse possibile ottenere un banco di prova identico in sistemi in cui sia le prestazioni che la disponibilità contano davvero) ma è l'unica a cui mi sento davvero a mio agio con.

Possiamo parlare della teoria se l'hyperthreading debba danneggiare o migliorare le cose in generale (trovo che abbia più probabilità di danneggiare che aiutare sui server, quindi per una distribuzione "generica" ​​probabilmente lo disabiliterei), ma c'è solo un modo per vedere con certezza se farà la differenza nel tuo caso specifico, e cioè provarlo e vedere.

Sono d'accordo

• nella migliore delle ipotesi la raccomandazione è "prova HyperThreading sul tuo carico di lavoro e guarda cosa succede". Lo stiamo facendo proprio adesso mentre scrivo, e ... non va bene!
• probabilmente dovresti sempre iniziare con HyperThreading disabilitato, poiché è il più sicuro

Sembra che dovremmo accordare due cose:

1. MAXDOP (gradi massimi di parallelismo). Tutto quello che ho letto indica che avere questo illimitato è probabilmente una cattiva idea e la documentazione di Microsoft dice:

   L'impostazione di questa opzione [MAXDOP] su un valore maggiore [di 8] spesso causa consumo di risorse indesiderate e degrado delle prestazioni.

   qualcosa di più alto di quanto 8non sia generalmente raccomandato .. quindi l'ho impostato su 4per ora. Inizialmente era zero (illimitato).

2. Soglia di costo per il parallelismo. Apparentemente il default di 5qui è considerato un default piuttosto basso secondo alcuni post di MVP SQL che ho trovato - possiamo sintonizzarlo per ridurre quanto parallelismo viene persino tentato dallo scheduler.

Ma onestamente sembrano soluzioni alternative; Penso che la vera soluzione per il nostro carico di lavoro (indice full-text pesante) sia disabilitare HT.

Anandtech ha scoperto che con il puro carico di lettura, faceva un po 'male, e con un carico pesante di scrittura, era un po' una vittoria. Non ho visto nulla per farmi pensare che ti farà ottenere un successo molto peggiore del -5% o una vittoria molto migliore del 15%. Nota cosa con un Atom, è una vittoria enorme, ma è una cpu molto strana.

Tutto quello che hai cambiato è stato il CPU? Sei passato da 12 MB di cache e 4 thread, quindi 3 MB di cache per thread, a 8 MB di cache e 8 thread, quindi 1 MB per thread. Ora, questo è semplicissimo, ma scommetto che è quello che ti sta uccidendo, hai usato per eseguire query nella cache e ora eseguirle dalla RAM perché hanno bisogno di più di 1 MB ma meno di 3 MB. La disattivazione di HT probabilmente aiuterà, ma tornerei alla vecchia CPU. Disattiva HT e ottieni 2 MB per thread, ma se il tuo carico di lavoro si blocca con così tanto, non sarà di aiuto. È possibile che la vecchia CPU da 12 MB di cache sia enormemente più veloce per il tuo carico di lavoro.

Vorrei provare a disattivare HT e vedere se si tratta di un miglioramento, ma sospetto che la cache sia il re per il carico di lavoro e potrebbe essere necessario tornare al chip da 12 MB.

L'hyperthreading è, nella migliore delle ipotesi, solo un modo per astrarre l'attività che si allontana dal sistema operativo e lo posiziona on-die, con accesso diretto alla cache L1 e L2, che rende più veloce lo scambio di attività.

I test con VMWare hanno indicato che la disabilitazione di HT non ha fatto alcuna differenza riconoscibile sotto carico standard e un aumento del 5% sotto carico pesante, dovuto al fatto che ESXi è abbastanza intelligente da conoscere la differenza tra il thread "reale" e il thread "falso" (c'è molto di più, ma in parole povere). SQL Server 2005 non è poi così intelligente, ma combinato con un sistema operativo aggiornato ci dovrebbe essere un piccolo vantaggio nel disabilitare l'HT.

Detto questo, concordo con Ronald sul fatto che molto probabilmente sarà la tua cache L2. Un calo del 33% nella dimensione della cache è sostanziale e quando specifichiamo i nostri server SQL andiamo sempre alla cache sulla velocità di clock non elaborata ogni volta.

In base alla mia esperienza, HT stava facendo sì che le operazioni di I / O impiegassero un'eternità sui miei nodi attivi su un cluster di Windows 2008 R2 (con SQL Server 2008 R2). Un fatto interessante è che non si rifletteva né nelle statistiche di attesa né nel pssdiag che ho corso per il supporto Microsoft.

Il modo in cui ho notato I / O basso è stato solo guardando i contatori del sistema operativo per il disco fisico. Come ha sottolineato Sam, ne ho scritto qui e qui

Se NON si verificano problemi di I / O e sono associati alla CPU, ti suggerisco di iniziare in questo modo:

Individua quali processi e blocchi T-SQL stanno causando il maggior utilizzo della CPU. Nella nostra esperienza, dopo aver risolto il problema con l'I / O (disattivando HT) abbiamo identificato il codice che stava funzionando in modo orribile nel 2008 R2 e stava andando bene nel 2005. Ne ho scritto qui .

Mentre sei sotto carico, esegui sp_whoisactive di Adam Machanic. Puoi scaricarlo da qui . Stavamo riscontrando un utilizzo della CPU molto elevato a causa dell'eccessiva quantità di letture logiche (20 milioni per query) a causa di un piano davvero scadente. I nostri processi eseguivano join anti-semi con tabelle partizionate.

La mia prossima raccomandazione è quella di eseguire il profiler per identificare un insieme di codice T-SQL che sia ad alto contenuto di CPU e letture logiche I / O.

Con i passaggi precedenti siamo stati in grado di ottimizzare i processi offensivi e passare dall'85% di utilizzo della CPU a quasi zero.

Buona fortuna e sentiti libero di scrivermi se trovi una soluzione poiché vorrei aggiungere il caso al mio blog.

Grazie

Oscar

È difficile stabilire se HT sia buono o cattivo.

Dipende davvero dal modello di caricamento del server basato sull'esperienza e sulla lettura. Cioè, quando influisce sulle prestazioni, fa così male : altrimenti non te ne accorgi.

La teoria che ho letto è che i thread condividono la cache, il che significa che in condizioni avverse ogni thread può sovrascrivere la cache dell'altro thread. Se non hai molto parallelismo o il tuo carico è composto da molte brevi query, potrebbe non interessarti.

Ho provato con MAXDOP e l'affinità del processore (nel mio ultimo vero ruolo DBA su SQL Server 2000) ma non ho mai trovato nulla di conclusivo: ma solo per il mio negozio in quel momento.

Come test rapido, è possibile impostare l'affinità del processore per utilizzare solo i core fisici (i numeri inferiori) e vedere cosa succede.

Tuttavia, al massimo perdi metà dei tuoi core. Al giorno d'oggi potrebbe non importare rispetto a quello con cui giocavo qualche anno fa quando era 2 contro 4 o 4 contro 8. Ora sono 8 contro 16 o 16 contro 32.

Modifica: un test di Slava Oks

Sfortunatamente, non penso che otterrai una risposta più definitiva di "prova a disattivare l'hyperthreading e vedi se questo aiuta".

Nonostante la risposta utile di Jonathan nel mio thread originale (che hai collegato nella tua domanda), non sono mai stato in grado di ottenere prove definitive sull'impatto dell'HT sui server specifici su cui stavo indagando. Nel mio caso, i server erano già programmati per la sostituzione, quindi semplicemente lasciamo che quei rimpiazzi "prendano cura del problema" per così dire.

Il mio consiglio:

Prova un'impostazione MAX Grado di parallelismo a livello di server pari a 1 . Il parallelismo su SQL è comunque molto utile per query più grandi e più lunghe, e il tuo carico (presumo) consiste comunque in un numero enorme di query più piccole. Questo dovrebbe eliminare completamente le attese di CXPACKET. Ciò potrebbe far sì che alcune singole query vengano eseguite leggermente più a lungo, ma dovrebbe consentire una maggiore "velocità effettiva" delle query totali sul server.

Ho ottenuto buoni risultati facendo questo sui server OLTP. Altri tipi di server (server di report, server di elaborazione, data warehousing) necessitano sicuramente di un MAXDOP superiore.

E per essere chiari, questa impostazione consentirebbe comunque a SQL di utilizzare più thread per ogni singola tabella in un JOIN, quindi non stai davvero eliminando del tutto il parallelismo.

Almeno vale la pena provare, poiché questa modifica delle impostazioni ha effetto immediato e non richiede nemmeno il riavvio del servizio SQL: http://msdn.microsoft.com/en-us/library/ms181007.aspx
Ciò significa che è possibile cambiare torna immediatamente se le cose iniziassero all'inferno.

La disattivazione dell'hyperthreading nel BIOS richiederebbe un riavvio completo del server, quindi è un po 'più rischioso.

Per la cronaca, abbiamo anche avuto prestazioni inaspettatamente cattive dopo un aggiornamento del server. Si è scoperto essere a causa di problemi con il risparmio energetico del BIOS e della CPU. L'impostazione predefinita sul server (HP) era di ignorare il controllo del sistema operativo della velocità della CPU e utilizzare il proprio algoritmo. La modifica del controllo del sistema operativo e l'aggiornamento del BIOS hanno comportato miglioramenti significativi. C'erano alcune note di rilascio (non le trovo ora) che c'era un bug del BIOS che bloccava la CPU allo stato di prestazione più basso.

https://serverfault.com/a/196329/6390