SQL Server diventa più lento nel tempo fino a quando non è necessario riavviarlo

Abbiamo un database con un carico di lavoro misto OLAP / OLTP. Le query sono abbastanza ad-hoc e vengono create dinamicamente nel server delle applicazioni di livello intermedio. Quando si avvia il server, le prestazioni sono abbastanza accettabili, ma il consumo di memoria aumenta sempre di più fino all'esaurimento di tutta la memoria disponibile (30 GB). Successivamente, il sistema diventa sempre più lento.

I comandi come Dbcc freeproccachenon hanno alcun effetto.

Non ci sono molte transazioni in select * from sys.dm_tran_session_transactions(non più di quando il sistema va bene), alcune volte questo elenco è vuoto.

Il primo risultato di dbcc memorystatusè

VM Reserved               42136628
VM Committed               1487176
Locked Pages Allocated    24994048
Reserved Memory               1024
Reserved Memory In Use           0

Un riavvio di SQL Server risolve il problema per un po '.

1. Cosa causa questo comportamento? Come può essere evitato?
2. Se una soluzione reale per la causa è troppo difficile, esiste un comando che impone a SQL Server di rilasciare effettivamente tutta la memoria senza un riavvio DBMS completo?

Il server è in esecuzione su hardware dedicato (non una macchina virtuale). Avevamo alcuni lavori programmati, ma li abbiamo disabilitati per un po ', senza modifiche. Esistono altre applicazioni di livello intermedio in esecuzione sullo stesso server, ma utilizzano non più di 2 GB di memoria, CPU trascurabile e quasi nessun I / O. Abbiamo riavviato tutte queste applicazioni senza alcuna modifica.

Suggerirei di raccogliere le metriche delle prestazioni su questo server, in modo da poter eliminare le congetture dalla risoluzione di questi tipi di problemi. Vedi questo articolo per una guida più completa se non sai da dove cominciare.

In particolare, vorrei controllare i contatori delle prestazioni Memory\Available MBytese Paging File(_Total)\% Usagepoiché hai detto che i problemi iniziano a verificarsi solo quando il pool di buffer è pieno. I numeri che si ottengono da questi contatori possono indicare che l'impostazione della memoria massima del server deve essere regolata (su o giù) per la quantità di memoria fisica allocata al server. Come ho già detto qui , non consiglio di basare l'impostazione della memoria massima sulla quantità di memoria fisica se non come ipotesi istruita per un punto di partenza . Misura sempre il risultato e regola da lì.

Se la quantità di memoria libera è troppo bassa (<500) o l'utilizzo del file di paging è superiore a zero , ciò può indicare che l'istanza di SQL Server è stata sovraccaricata: su SQL Server 2008 R2, l'impostazione di memoria massima del server controlla solo le dimensioni del pool di buffer e non altro utilizzo della memoria come la cache del piano. Inoltre, SQL Server non si preoccupa delle altre applicazioni che potresti avere in esecuzione sul sistema. Questo ulteriore utilizzo della memoria può esercitare pressioni sulla memoria di Windows, o di altre applicazioni, causando probabilmente lo scambio del disco. Questo è qualcosa che vuoi evitare a tutti i costi, in particolare se il file di paging esiste su un volume supportato da un semplice mirror RAID 1. La mia sensazione è che questo sia il problema e il backup dell'impostazione di memoria massima del server dovrebbe risolvere il problema.

Se la quantità di memoria libera è elevata (> 1000) e l'utilizzo del file di paging è zero, è possibile aumentare leggermente la memoria massima del server (con incrementi di 256 MB) per massimizzare l'utilizzo della memoria del server. Questo molto probabilmente non risolverà il problema, tuttavia, dovrai cercare altrove, probabilmente i contatori del disco fisico e l'aspettativa di vita della pagina del pool buffer. Se le query bloccano il pool di buffer, non c'è altro da fare se non migliorare le prestazioni del disco, aumentare la quantità di memoria fisica disponibile per il server in modo che tutte le pagine di dati possano adattarsi alla memoria contemporaneamente o modificare il database per non occupare tanto spazio fisico (magari utilizzando la compressione di riga o di pagina o ricostruendo gli indici con un valore superiore FILLFACTOR).

Ho pubblicato un articolo su questo argomento qui che approfondisce questo problema e come risolverlo.

Generalmente la tendenza alla lentezza nel tempo dovrebbe essere inversa, perché quando le pagine dei database si spostano nella cache, le prestazioni dovrebbero migliorare (l'aspettativa di vita della pagina e il rapporto di buffer buffer aumentano con il tempo), hai impostato la tua memoria massima su (total_physical_mem - 2GB)?

Sembra che un paio di query stiano causando la fuoriuscita di SQL Server e la pagina in molte cose. È possibile provare Resource Governor per limitare il consumo di memoria delle query grandi e medie, in modo che le query dell'applicazione dispongano sempre di un buffer sufficiente.