Flush della cache di SQL Server e I / O del disco

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 SIMPLEin FULLha 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?

Altri hanno già segnalato il colpevole: SQL Server accumula gli aggiornamenti in memoria (nel pool buffer) e li elimina solo periodicamente (ai punti di controllo). Le due opzioni suggerite (-k e intervallo del punto di arresto) sono complementari:

• -k farà sì che il checkpoint produca richieste IO meno aggressive e duri più a lungo
• abbassando l' intervallo di recupero, il checkpoint si avvierà più spesso

Ma non ho risposto solo per rigurgitare i bei commenti che hai ricevuto fare molto :)

Ciò che stai vedendo, sfortunatamente, è un comportamento molto tipico dell'elaborazione in coda . Sia che si utilizzino le code di Service Broker o si scelga di utilizzare le tabelle come approccio alle code , il sistema è molto incline a questo tipo di comportamento. Questo perché l'elaborazione basata su accodamento è pesante, anche più pesante dell'elaborazione OLTP. Sia accodamento e dequeue primitive sono le operazioni di scrittura e non ci sono operazioni quasi leggere. In poche parole, l'elaborazione della coda genererà il maggior numero di scritture (= pagine più sporche e la maggior parte dei registri) rispetto a qualsiasi altro carico di lavoro, anche OLTP (cioè carico di lavoro simile a TPC-C ).

Cosa molto importante, le scritture di un carico di lavoro della coda seguono un modello di inserimento / eliminazione: ogni riga inserita viene eliminata molto rapidamente. Ciò è importante per distinguere da un modello di sola aggiunta di un carico di lavoro di inserimento pesante (ETL). Fondamentalmente stai alimentando il compito di pulizia dei fantasmi un pasto completo e puoi facilmente superarlo. Pensa a cosa significa:

• enqueue è un inserto, creerà una pagina sporca
• dequeue è un'eliminazione, sporcherà di nuovo la stessa pagina (potrebbe essere fortunato e catturare la pagina prima del checkpoint, quindi eviterà il doppio flush, ma solo se è fortunato)
• la pulizia fantasma pulirà la pagina, rendendola nuovamente sporca

Sì, significa davvero che potresti finire per scrivere una pagina tre volte sul disco, in tre diverse richieste IO, per ogni messaggio che elabori (caso peggiore). Significa anche che l'IO casuale dei checkpoint sarà davvero casuale poiché il punto di scrittura della pagina sarà visitato di nuovo da quelle teste mobili tra due checkpoint (il confronto con molti carichi di lavoro OLTP tende a raggruppare le scritture su alcuni "punti caldi", non code ...).

Quindi hai questi tre punti di scrittura, che corrono per contrassegnare la stessa pagina ancora e ancora. E questo prima di considerare qualsiasi divisione di pagina, anche l'elaborazione della coda potrebbe essere soggetta a causa dell'ordine di inserimento delle chiavi. In confronto, i carichi di lavoro OLTP "tipici" hanno un rapporto lettura / scrittura molto più bilanciato e le scritture OLTP sono distribuite su inserti / aggiornamenti / eliminazioni, spesso con aggiornamenti (modifiche allo "stato") e inserimenti che assumono la parte del leone. Le scritture di elaborazione delle code vengono esclusivamente inserite / eliminate con, per definizione, suddivisione 50/50.

Seguono alcune conseguenze:

• Checkpoint diventa un problema molto caldo (non è più una sorpresa per te)
• Vedrai una forte frammentazione (la frammentazione di per sé non avrà molta importanza in quanto non eseguirai scansioni di portata, ma l'efficienza dell'IO soffre e la pulizia dei fantasmi ha molto di più da lavorare, rallentandola ancora di più)
• Il throughput IO casuale dell'archiviazione MDF sarà il collo di bottiglia

La mia raccomandazione arriva in 3 lettere: S, S e D. Sposta il tuo MDF in una memoria in grado di gestire I / O casuali veloci. SSD. Fusion-IO se hai i soldi. Purtroppo questo è uno di quei sintomi che non possono essere risolti con RAM più economica ...

Modificare:

Come sottolinea Mark, hai due dischi logici supportati da un disco fisico. Forse hai provato a seguire le migliori pratiche e a dividere il registro su D: e i dati su C: ma purtroppo è inutile, C e D sono lo stesso disco. Tra i checkpoint si ottiene un throughput sequenziale ma non appena si avvia il checkpoint, le testine del disco iniziano a spostarsi e il throughput del log collassa, riducendo l'intero throughput dell'app. Assicurarsi di separare il registro DB in modo che non sia interessato dai dati IO (disco separato).