Come risolvere i tipi di attesa RESOURCE_SEMAPHORE e RESOURCE_SEMAPHORE_QUERY_COMPILE

Stiamo cercando di capire la causa principale delle query del server sql a esecuzione lenta che colpiscono / recuperano i dati da uno dei database, dimensioni 300 GB, ospitati sul server con la seguente configurazione:

Windows server 2003 R2, SP2, Enterprise Edition, 16 GB RAM, 12 CPU 32 bit

SQL server 2005, SP4, Enterprise Edition, 32 bit.

Abbiamo già informato gli affari sull'aggiornamento a 64 bit che richiederebbe più di un mese.

Ma per il problema attuale, stiamo cercando di raccogliere i dati se siamo in grado di risolvere la pressione della memoria o alla fine giungere a una conclusione per aumentare la RAM.

Azione completata: le reindicizzazioni e le statistiche di aggiornamento sono appropriate per questo DB.

Come mostrato di seguito, abbiamo notato il tipo di attesa del semaforo negli ultimi 5 giorni, eseguito durante le ore di caricamento:

Poche informazioni dopo le query di seguito: dimensione del buffer = 137272

SELECT SUM(virtual_memory_committed_kb)
FROM sys.dm_os_memory_clerks
WHERE type='MEMORYCLERK_SQLBUFFERPOOL'

e memoria semaforo = 644024 per query sottostante

 SELECT SUM(total_memory_kb)
FROM sys.dm_exec_query_resource_semaphores

Di seguito sono riportate ulteriori informazioni raccolte da dm_exec_query_resource_semaphorese sys.dm_exec_query_memory_grantsdmv's

Quindi, dalle informazioni sopra raccolte e dai dati SP_Blitz il semaforo delle risorse sembra essere il problema.

La memoria "target_memory_kb" assegnata per l'ID del semaforo della risorsa è troppo bassa, rispetto ai 16 GB di RAM disponibili.

Nota * per analisi su 8 ore di esecuzione 'target_memory_kb' è sempre inferiore a 1 GB, rispetto ai 16 GB disponibili?

quale potrebbe essere il problema qui e come risolvere, si prega di suggerire

Grazie

Oh, dio, ho delle brutte notizie qui.

Su un sistema operativo a 32 bit, SQL Server utilizza solo i primi 4 GB di memoria per cose come l'area di lavoro delle query. (E sta combattendo il sistema operativo anche per quel 4 GB - anche qualsiasi altra app in esecuzione competerà per quella memoria.)

4 GB potrebbero sembrare molto, ma è relativamente semplice scrivere una query che necessita di diversi GB di memoria per funzionare. Quando un numero sufficiente di query richiede memoria sufficiente, SQL Server genera RESOURCE_SEMAPHORE in attesa perché le query non possono ottenere memoria sufficiente per iniziare. RESOURCE_SEMAPHORE_QUERY_COMPILE significa che non possono nemmeno avere abbastanza memoria per compilare un piano di esecuzione - e sì, è piuttosto male.

Quindi, come lo risolvi?

• Passa a un sistema operativo a 64 bit (il sistema operativo in esecuzione è comunque a lungo fuori supporto)
• Passa a una build a 64 bit di SQL Server
• Riduci le richieste di memoria sul server (non eseguire altre app su questa scatola, e questo è particolarmente critico sulle scatole a 32 bit poiché siamo limitati a soli 4 GB)
• Usa più memoria con le opzioni AWE / PAE - tranne che non funziona per RESOURCE_SEMAPHORE attende perché SQL Server può utilizzare solo i primi 4 GB per l'area di lavoro della query
• Ottimizza le query e gli indici in modo che abbiano bisogno di meno memoria

Esito anche a dire l'ultimo, perché il problema a 32 bit è così grave, ed è davvero difficile con le versioni precedenti di SQL Server. Se ci si trovava su una corrente, è possibile passare attraverso la cache del piano e ordinare le query in base alla concessione di memoria, trovare i destinatari della concessione più grandi e ottimizzare quelli. Non è un'opzione su questo antico antico, però.