Siamo impegnati a testare un sistema OLTP che abbiamo sviluppato in .NET 4.0 ed esegue SQL Server 2008 R2 sul retro. Il sistema utilizza le code di SQL Server Service Broker, che sono molto performanti, ma stiamo riscontrando una tendenza peculiare durante l'elaborazione.
Richieste di processo di SQL Server a una velocità elevata per 1 minuto, seguite da ~ 20 secondi di maggiore attività di scrittura su disco. Il seguente grafico illustra il problema.
Yellow = Transactions per second
Blue = Total CPU usage
Red = Sqlsrv Disk Write Bytes/s
Green = Sqlsrv Disk Read Bytes/s
Durante la risoluzione dei problemi, abbiamo provato quanto segue senza alcuna modifica significativa nel modello:
- Agente SQL Server arrestato.
- Ha ucciso quasi tutti gli altri processi in esecuzione (No A / V, SSMS, VS, Windows Explorer, ecc.)
- Rimossi tutti gli altri database.
- Disabilitato tutti i timer di conversazione (non utilizziamo trigger).
- Allontanato da un approccio basato sulla coda dei messaggi a un design di monitoraggio della tabella semplice / grezzo.
- Usato diversi carichi da leggero a pesante.
- Risolti tutti i deadlock.
Sembra che SQL Server stia accumulando la sua cache e scrivendola sul disco a intervalli di tempo specifici, ma non riesco a trovare nulla online per supportare questa teoria.
Successivamente, ho intenzione di spostare la soluzione nel nostro ambiente di test dedicato per vedere se riesco a replicare il problema. Qualsiasi aiuto nel frattempo sarebbe molto apprezzato.
Aggiornamento 1 Come richiesto, con un grafico che include le pagine / sec di Checkpoint , l' aspettativa di durata della pagina e alcuni contatori di latenza del disco.
Sembra che il Checkpoint (linea blu chiaro) sia la causa della prestazione ridotta (linea gialla) che stiamo osservando. ^
La latenza del disco rimane relativamente coerente durante l'elaborazione e l'aspettativa di vita della pagina non sembra avere alcun effetto evidente. Abbiamo anche regolato la quantità di RAM disponibile per SQL Server, che non ha avuto un grande effetto. Anche la modifica del modello di recupero SIMPLE
in FULL
ha fatto poca differenza.
Aggiornamento 2 Modificando l '"Intervallo di ripristino" come segue, siamo riusciti a ridurre l'intervallo in cui si verificano i checkpoint:
EXEC sp_configure 'show advanced options',1
GO
RECONFIGURE
GO
EXEC sp_configure 'recovery interval', '30'
GO
RECONFIGURE
GO
EXEC sp_configure 'show advanced options',0
GO
RECONFIGURE
Non sono sicuro che si tratti di una cattiva pratica?
FULL
o BULK_LOGGED
, si comporta comunque come se fosse in SIMPLE
fino a quando non si esegue un backup completo.