Perché sono necessari riavvii periodici per garantire il buon funzionamento della mia istanza?

Abbiamo un server DB di produzione su SQL 2005. Tutto funziona normalmente per un po ', ma dopo un paio di settimane vediamo un notevole calo delle prestazioni. Solo il riavvio di SQL Server riporta le prestazioni alla normalità.

Alcuni retroscena:

• Esecuzione di oltre 1200 database (principalmente tenant singolo, alcuni multi-tenant). Prima che qualcuno dia lezioni sul passaggio al multi-tenant, ci sono validi motivi per mantenere questa struttura ......
• La RAM è di 16 GB. Dopo il riavvio, SQL Server non impiega troppo tempo per tornare a 15 GB di utilizzo.
• Connessioni DB attive sono circa 80 connessioni - che riteniamo abbastanza buone considerando che esiste un pool di connessioni per server Web per processo - quindi non abbiamo un problema di perdita di connessione.

Abbiamo provato diverse cose in orari non di punta: - Esegui DBCC DROPCLEANBUFFERS (con un CHECKPOINT) per cancellare la cache dei dati. Non ha alcun effetto, né cancella l'utilizzo della RAM). - Esegui FREEPROCCACHE e FREESYSTEMCACHE per cancellare i piani di query e la cache di proc memorizzata. Nessun effetto.

Ovviamente il riavvio di SQL Server non è l'ideale in un ambiente di produzione attivo. Ci manca qualcosa. Qualcun altro lo attraversa?

AGGIORNAMENTO: 28 aprile-2012 Stiamo ancora combattendo questo problema. Ho ridotto la memoria per SQL Server a 10 GB, solo per escludere qualsiasi contesa con il sistema operativo. Mi sto avvicinando al restringimento, ma ho bisogno di aiuto dal mio prossimo passo.

Ecco cosa ho trovato, dopo aver riavviato SQL Server, il file della pagina si sposta tra 12,3 GB e 12,5 GB. Rimarrà così per giorni. I thread totali del server si bloccheranno tra 850 e 930, anche stabili e coerenti per giorni e giorni (sqlserver è costantemente compreso tra 55 e 85 di quelli a seconda del traffico).

Quindi, c'è "un evento". Non ho idea di quale sia l'evento, non riesco a vederlo nei registri e non riesco a vedere nulla di coerente nel giorno della settimana o nel momento in cui si verifica, ma tutti i suddetti file di pagina passano a 14.1 o 14.2 GB, e i thread passano tra il 1750 e il 1785.

Controllando perfom quando ciò accade, oltre 900 di quei thread sono sqlserver. Quindi vado a sp_who2 per vedere da dove provengono questi thread ... e ci sono solo le connessioni db usate circa 80.

Quindi ... qualcuno ha qualche idea su come posso localizzare il resto di questi 900 thread su SQL Server e cosa stanno facendo?

AGGIORNAMENTO: giugno-01-2012 Sto ancora combattendo il problema. Per chiunque stia ancora leggendo, il problema con i thread che saltano su è stato risolto. Ciò è stato causato dal software di backup automatico ComVault. Stava creando un thread che cercava di eseguire il backup di database che non erano più presenti (stava mantenendo un elenco di database precedenti) anziché semplicemente eseguire il backup dei database correnti.

Ma il problema persiste e dobbiamo riavviarlo ogni settimana, dare o prendere qualche giorno. Lavorare con il team di Rackspace per vedere se possono far luce.

Dici che tutto va bene, poi dopo un paio di settimane, le prestazioni diminuiscono. (Di solito, le persone sostengono che le prestazioni diminuiscono rapidamente, o in momenti specifici o ad intervalli apparentemente casuali. Ciò potrebbe significare cattive prestazioni di I / O o blocchi di tempeste o query ad alta intensità di CPU in esecuzione in periodi strani, o un lavoro programmato pesante o la mancanza di indicizzazione o cattive statistiche che causano query ad alta intensità di CPU o letture del disco. O altre cose.) Le settimane sono insolite.

La mia ipotesi è che un'altra applicazione sul tuo server stia perdendo memoria. L'ho visto con un software antivirus (il cattivo di tutti i software server preferiti di DBA) e software di monitoraggio di terze parti. Verificherei il controllo dell'utilizzo della memoria di SQL Server, nel tempo, e afferrerei anche tutto l'uso della memoria di tutte le altre applicazioni sulla scatola. Se hai limiti fissi per l'utilizzo della memoria di SQL Server e hai impostato per non consentire il paging, potrebbero essere altre app a essere pagate e stanno esaurendo la capacità di I / O.

Non è difficile da cercare. Se non stai già mantenendo le metriche sul server, vorrei semplicemente avviare Perfmon e farlo prendere un campione ogni 30 o 60 minuti. Dopo alcuni giorni, è possibile che si verifichi un aumento dell'utilizzo della memoria di altre applicazioni.

Ci sono messaggi di errore nel registro di SQL Server che indicano che "parti significative di SQL Server sono state pagate"? Sarebbe anche un grande indizio.

Vorrei congratularmi con te per essere riuscito a eseguire 1200 DB su una singola istanza di SQL Server con solo 16 GB di RAM e avere solo questo tipo di problemi dopo un paio di settimane di funzionamento regolare. Bella storia da raccontare nel capitolo PASS locale.

Ora per risolvere: la tua RAM è di 16 GB sia per SQL che per OS. Suppongo che l'impostazione di memoria massima sia di 15 GB o max. Ciò potrebbe causare il pool di buffer che utilizza tutta la memoria e soffoca il sistema operativo. Stai dicendo che cancellare il pool di buffer e le cache non mostra alcuna differenza, inoltre il tuo PLE è superiore a 300. Ciò testimonia contro i colli di bottiglia di memoria. Come sono la CPU e l'IO sul server (specifiche / statistiche)?

Esegui select * from sys.dm_exec_request where session_id>50 and session_id<>@@spide quali sono le contese di risorse che vedi (wait_type, wait_time, last_wait_type, wait_resource).

1200 database, un sistema operativo e forse altre cose? Sì, penso che il server stesso avrà bisogno di più di 1 GB di RAM per funzionare, soprattutto considerando che, se si imposta 15 GB come impostazione di memoria massima di SQL Server, per i thread è comunque necessaria memoria aggiuntiva al di fuori di quel 15 GB.

Abbasserei SQL Server fino a 14 GB per dare al server un po 'più di respiro.

Inoltre, un esempio fornito in "Risoluzione dei problemi interni e risoluzione dei problemi di SQL Server 2008" per le quote di memoria su un sistema SQL Server 2008 x64 con utilità di backup di terze parti con 16 GB di RAM:

• 2 GB per Windows
• 1 GB per thread di lavoro
• 1 GB per MPA, ecc.
• 1 GB per il programma di backup
• 11 GB per SQL Server

Nel libro mostra come determinare il numero massimo di thread che puoi avere e come calcolare la quantità di memoria che occuperanno. Esegui questo (cambia il tipo di server in modo che corrisponda al tuo server) per capire quanta memoria avrai bisogno dei tuoi thread.

declare @servertype int

set @servertype=1
/*
1: x86 (32-bit)
2: x64 (64-bit)
3: IA64

*/

select max_workers_count *
    (
        case @servertype when 1 then .5
            when 2 then 2
            when 3 then 4
            else .5
        end
    )
from sys.dm_os_sys_info

Se la memoria del database è distribuita uniformemente su tutti i database, si hanno solo 12,8 Meg per ciascun database (15 * 1024) / 1200/12,8. Hai bisogno di più memoria.

Devi capire perché le prestazioni stanno rallentando. Stai vedendo il blocco, il blocco, ecc.? Come sono le statistiche di attesa?

I comandi DBCC cancelleranno solo i buffer di memoria e non rilasceranno la memoria sul sistema operativo.

Sai che SQL Server sta effettivamente consumando la memoria? Suggerirei di impostare la sessione Perfmon o iniziare a raccogliere informazioni DMV dopo un riavvio per scoprire cosa sta facendo e lavorando SQL Server. Prendi nota anche se gli utenti svolgono più lavoro del normale durante il periodo di raccolta (come l'elaborazione di fine mese, ecc.). Stai eseguendo SSRS, SSIS o SSAS sullo stesso server?

Hai 1200 database nel sistema, qual è il DB di dimensioni maggiori che hai?