È necessario comprendere l'errore di esecuzione della query parallela

Oggi abbiamo riscontrato un peggioramento delle prestazioni sul nostro server sql di produzione. Durante questo periodo abbiamo registrato diversi "The query processor could not start the necessary thread resources for parallel query execution"errori. La lettura che ho fatto suggerisce che ciò ha a che fare con quante CPU utilizzare quando si esegue una query complessa. Tuttavia, quando ho controllato durante l'interruzione il nostro CPU Utilization was only at 7%. C'è qualcos'altro a cui potrebbe riferirsi anche questo che non ho ancora incontrato? È forse questo il colpevole del degrado delle prestazioni o sto inseguendo un'aringa rossa?

I miei valori sp_configure per questo sono i seguenti:

name                                minimum maximum config_value run_value
cost threshold for parallelism      0       32767   5            5

Pochi mesi fa, ho riscontrato una situazione simile in cui l'impostazione MAXDOP era predefinita e una query di fuga esauriva tutti i thread di lavoro.

Come Remus ha sottolineato, questo si chiama fame di thread dei lavoratori .

Ci sarà un dump della memoria creato sul tuo server quando si verifica questa condizione.

Se si è su 2008R2 + SP1 e versioni successive, sys.dm_server_memory_dumpsverrà visualizzato anche il percorso del file di dump.

Ora torniamo al problema:

Esiste 1 thread di monitoraggio dello scheduler per nodo NUMA e poiché hai 2 nodi NUMA ci saranno 2 thread di monitoraggio dello scheduler che sono responsabili del controllo dello stato di tutti gli scheduler ogni 60 secondi per quel particolare nodo NUMA assicurandosi che lo scheduler sia bloccato o non.

Ogni volta che una nuova richiesta di lavoro viene estratta dalla coda di lavoro degli scheduler, il contatore dei processi di lavoro viene incrementato. Pertanto, se lo scheduler ha una richiesta di lavoro in coda e non elabora una delle richieste di lavoro in 60 secondi, lo scheduler viene considerato bloccato.

A causa di una query "run-away" o di un ampio parallelismo, sorge una condizione in cui i thread di lavoro iniziano esauriti poiché tutti i thread sono occupati da quella singola query di run-time o da un eccessivo blocco prolungato e nessun lavoro può essere eseguito a meno che quel processo offensivo non venga ucciso.

La tua scommessa migliore è prima sintonizzare il tuo impostazione del massimo grado di parallelismo . L'impostazione predefinita 0 indica che SQL Server può utilizzare tutte le CPU disponibili per l'elaborazione parallela e esaurendo tutti i thread di lavoro.

Esistono molte ragioni che possono portare all'esaurimento dei thread di lavoro:

• Ampie catene di blocco lunghe che causano l'esaurimento dei thread di lavoro di SQL Server
• Un ampio parallelismo porta anche all'esaurimento dei fili dei lavoratori
• Ampia attesa per qualsiasi tipo di "blocco" - spinlock, chiavistelli. Un spinlock orfano è un esempio.

Fare riferimento alla mia risposta qui che ti mostrerà come calcolare il valore MAXDOP per l'istanza del tuo server.

Inoltre, consiglio vivamente di iniziare a raccogliere le informazioni sulle statistiche di attesa sull'istanza del server di database.

Potrebbero esserci diversi motivi. Molto probabilmente è che eri senza lavoratori. Vederemax_worker_threads . La condizione si chiama "distacco dei lavoratori". I lavoratori potrebbero essere rubati con uno qualsiasi dei vari modi (nessuno dei quali comporterebbe un elevato utilizzo della CPU, tra l'altro), come avere molte richieste bloccate o fare cose stupide in CLR (es. Richieste HTTP).

Il sintomo che vedi è la vittima del problema, non la causa. Non possiamo raccomandare una soluzione senza conoscere la causa. È necessario raccogliere contatori perf, DMV e controllare ERRORLOG per ulteriori informazioni.