SQL Server - Qualcuno usa SUMA, trace flag 8048 o trace flag 8015?

Recentemente incluso l'avvio di SQL Server Trace Flag 8048 per risolvere un grave problema di contesa di spinlock in un sistema SQL Server 2008 R2.

Interessato a ricevere notizie da altri che hanno riscontrato casi di utilizzo in cui il valore delle prestazioni è stato fornito dal flag di traccia 8048 (promuovere la strategia di concessione della memoria di query dal nodo per-NUMA a per-core), il flag di traccia 8015 (SQL Server ignora il NUMA fisico) o SUMA ( accesso alla memoria sufficientemente uniforme interlacciato, opzione BIOS su alcune macchine NUMA).

Flag di traccia 8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -presented-per-Numa-node-may-bisogno-trace-flag-8048.aspx

Traccia flag 8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx

Seguono i dettagli cruenti del carico di lavoro del sistema, le metriche raccolte dal sistema problematico e le metriche raccolte dal sistema dopo l'intervento.

Il flag di traccia 8048 era una 'correzione', ma era la soluzione migliore? SQL Server ignorando NUMA fisica a causa del flag di traccia 8015 avrebbe ottenuto lo stesso risultato? Che dire dell'impostazione del BIOS per intercalare la memoria, lasciando al server il comportamento SUMA che imita SMP invece del comportamento NUMA?

Pace! tw: @sql_handle

Informazioni sul sistema: - Xeon E7540 a 4 hex core a 2,00 GHz, hyperthreaded - 128 GB RAM - WS2008R2 - MSSQL 2008 R2 SP2 - maxdop 6

Informazioni sul carico di lavoro: - 1000s di report pianificati / in coda gestiti da 2 server di applicazioni report. - 3 tipi di batch: giornaliero, settimanale, mensile - Tutte le connessioni dei server delle applicazioni di report a SQL Server vengono effettuate come un unico account di servizio - Concorrenza massima dei report = 90

Principali risultati sul sistema problematico: - Da Perfmon, intervalli di 15 secondi - - Il sistema rimane occupato al 95% -100% CPU occupata - - Ricerche di pagine buffer di SQL Server <10000 al / secondo

Da DMV di attesa e spinlock, intervalli di 5 minuti
- Elevati camerieri CMEMTHREAD e tempo di attesa
- Giri e backoff SOS_SUSPEND_QUEUE elevati

Il post sul blog dell'ingegnere CSS di Bob Dorr sul flag di traccia 8048 indica che i sistemi con più di 8 core per nodo NUMA possono riscontrare sintomi simili a causa di colli di bottiglia nella concessione della memoria delle query. Il flag di traccia 8048 cambierà la strategia in base al core anziché al nodo per-NUMA.

L'intervento

MSSQL è stato riavviato con -T8048 in atto. La differenza è stata immediatamente evidente: il tasso di ricerca delle pagine buffer è aumentato di oltre 1 milione e ha raggiunto gli 8 milioni al secondo. Il carico di lavoro batch problematico, che in precedenza non poteva essere completato in 24 ore, è stato completato in meno di 4 ore. Un altro carico di lavoro batch che non era al centro di indagini o interventi è stato presentato come parte della convalida del valore correttivo del flag di traccia 8048 (e garantendo che i suoi effetti collaterali indesiderati fossero minimi). Questo batch di report è stato precedentemente completato in 2 ore; con flag di traccia 8048 in atto il batch di report è stato completato in circa 20 minuti.

Anche ETL notturno ha riscontrato un vantaggio. Il tempo ETL è passato da circa 60 minuti a 40 minuti.

Raccogliendo informazioni da più punti, suppongo che l'alto grado di accodamento dei report, il conteggio dei report simultanei maggiore del conteggio dei thread hardware e l'account utente singolo per tutti i report combinati per esercitare pressione su un nodo NUMA fino a quando la pressione del thread di lavoro non lo ha causato a essere sfavorito per la successiva richiesta di connessione in entrata per lo stesso account utente, a quel punto il nodo NUMA successivo otterrebbe un numero di connessioni vicino all'istante. Ogni nodo NUMA finirebbe con un'alta probabilità di stressare il collo di bottiglia di concessione della memoria della query.

L'apertura di più corsie per la concessione della memoria di query ha rimosso il collo di bottiglia. Ma non sono sicuro del costo. Il post CSS di Bob Dorr chiarisce che esiste un sovraccarico di memoria aggiuntiva con flag di traccia 8048. È un sovraccarico all'interno della regione di allocazione a pagina singola governata dalla memoria massima del server MSSQL 2008 R2? In tal caso, suppongo che il sistema avrà solo un numero in meno di pagine di database nella cache del pool di buffer. In caso contrario, è necessario ridurre la memoria massima del server per adattarla?

— sql_handle
fonte

Questo è un bel post.

Per rispondere alla tua ultima domanda, suppongo che la tua risposta sia "sì".

Detto questo, probabilmente avrei perseguito il soft numa prima di ricorrere alle tracce di traccia. Penso che tu abbia ragione sull'allocazione del nodo numa e questo potrebbe essere alla radice del tuo problema. Tramite soft numa, è possibile ridimensionare le richieste, in base al conteggio dei nodi numa (4?) - a 4, se questo è il numero corretto, e quindi assegnare, tramite indirizzo IP, ciascun host a un nodo numa specifico, inoltre a ciò, disabiliterei l'hyper threading. Insieme, il problema probabilmente diminuirebbe, tuttavia, lo farebbe a scapito di un minor numero di programmatori.

Con un pensiero separato, guarderei alla parametrizzazione forzata: il fatto che il tuo carico stia guidando la tua CPU così in alto è molto interessante e potrebbe valere la pena esaminarlo.

Infine, sui sistemi a più nodi, in genere ho l'output delle seguenti query che scaricano su una tabella ogni N secondi. Fornisce alcune interessanti analisi quando vengono implementate modifiche al carico di lavoro o flag di traccia:

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC

— Jeremy Lowell
fonte

Grazie per aver menzionato sys.dm_os_nodes e sys.dm_os_waiting_tasks. Sto scrivendo una serie di procedure memorizzate per profilare l'attività del sistema, prima per perseguire una linea di base in qualche modo ottimizzata, quindi per controllare le variazioni. In questo momento catturando attese e giri, poi arrivano i memory grant (incluso il dop per concessione di memoria) ... i prossimi singoli camerieri e nodi come hai discusso ... poi magari su impiegati di memoria e contatori di cache ...

— sql_handle

Un altro contatore interessante da guardare è in perfmon: SQLServer: Buffer Node :. I contatori di quella famiglia di interesse sono Pagine straniere, Pagine libere, Aspettativa di vita delle pagine, Pagine totali, Pagine target e Pagine rubate. Suppongo che prima di implementare il flag di traccia fosse presente una quantità molto elevata di pagine straniere: hai abilitato TF 834? In tal caso, ho scoperto che non alloca la memoria a ciascun nodo numa in modo equilibrato, il che porta a una quantità molto elevata di costose ricerche di memoria del nodo numa remoto. Il sistema su cui avevo questo problema conteneva 1 TB di RAM al momento.

— Jeremy Lowell,

punti buoni. Ho osservato le metriche del nodo buffer. La cosa più curiosa era che inizialmente il nodo 00 non aveva pagine straniere, mentre gli altri nodi avevano numeri enormi. Penso che ciò sia dovuto al fatto che il nostro ETL eseguiva il buffer ramp up con un numero di thread abbastanza basso da adattarsi interamente al nodo buffer / NUMA nodo 00. Non abbiamo il flag di traccia 834 abilitato, ma inizieremo presto a testarlo. Il nostro test del carico di lavoro su Linux Oracle 11gR2 ha mostrato grandi vantaggi nella memoria di pagine di grandi dimensioni, penso che vedremo anche miglioramenti in Windows con SQL Server.

— sql_handle,

@Mike Soft NUMA vs TF 8048. Penso che il soft NUMA mi consentirebbe di creare "nodi di memoria" all'interno dei nodi NUMA. Quindi, se avessi creato NUMA soft per ciascun core, ci sarebbero (forse) 24 corsie per le richieste di concessione della memoria delle query. Ma forse anche 24 nodi di memoria? Sarei un po 'preoccupato per l'overhead nella gestione di 24 nodi di memoria con ogni core che fa riferimenti a pagine' straniere 'ogni volta che attraversa un confine NUMA morbido, e riferimenti davvero stranieri quando attraversa un confine per fare riferimento a una pagina che è sia diversa NUMA morbido e NUMA duro. Armeggerò e vedrò se riesco a discernere qualcosa.

— sql_handle,