Messaggi FlushCache che compaiono nel registro in momenti specifici


22

Ultimamente abbiamo riscontrato molti problemi di prestazioni del database e ho cercato di capire se riuscissi a capire perché. Non abbiamo un DBA (sono uno sviluppatore di software), quindi sto solo cercando di farlo, e gran parte di ciò che trovo online mi sembra una lingua straniera.

Siamo stati riavviati SQL Server ogni mattina perché è l'unico modo in cui è operativo durante la giornata lavorativa. Ho notato che ogni mattina intorno alle 5 abbiamo iniziato a ricevere questo messaggio ogni due minuti nel registro:

FlushCache: ripulito 11848 bufs con 7432 scritture in 97168 ms (evitato 8139 nuovi bufs sporchi) per db 9: 0

ultimo obiettivo in sospeso: 4, avgWriteLatency 32

throughput medio: 0,72 MB / sec, saturazione I / O: 11635, switch di contesto 18849

I numeri differiscono ogni volta ovviamente, ma è sempre lo stesso messaggio in quel modello fino a quando non riavvio il server. Non sono sicuro di come interpretarlo, ci sto provando con Google e tutto quello che ho raccolto è che significa che potrebbe esserci qualcosa che non va nell'I / O e che qualcosa sta impiegando più tempo del previsto. Di recente siamo passati all'utilizzo di SSD, quindi non pensavo che dovesse trattarsi di un problema di scrittura.

Qualcuno potrebbe far luce su questo?


Risposte:


29

Il messaggio FlushCache nel registro degli errori è causato dalla registrazione del checkpoint e, in questo caso, da un checkpoint lungo (definito come checkpoint che impiega più tempo dell'intervallo di recupero). Che sia registrato o meno, il comportamento è diverso prima del 2012 e 2012+. Prima di SQL Server 2012, per ottenere la registrazione del checkpoint è necessario attivare un flag di traccia (T3504). Ma a partire da SQL Server 2012 quel messaggio viene registrato per impostazione predefinita quando viene rilevato un checkpoint lungo.

Ora, per quanto riguarda la domanda di "è davvero male ?" , devi davvero iniziare a guardare questi numeri dato il loro contesto. Ci sono voluti 97+ secondi per scaricare solo circa 93 MB di buffer sporchi. Sembra che questo potrebbe potenzialmente essere un misto di un sacco di sfornamento di dati (durante lo stesso checkpoint stesso, sono stati anche sporcati circa 64 MB di buffer) e potenzialmente un archivio che non è al passo con la modifica dei dati e / o il resto del carico di lavoro I / O.

Quello che farei è verificare l'integrità del tuo sottosistema di archiviazione , esaminare le attese e ottenere semplicemente un quadro complessivo delle prestazioni dell'istanza. Dai un'occhiata ai contatori di perfmon del disco logico e scopri qual è il churn I / O complessivo con throughput , latenza e IOps . Ti aiuterà a dipingere un quadro più vivido delle prestazioni dei dischi. Se hai la possibilità di eseguire il benchmark del tuo spazio di archiviazione, se non lo hai già fatto, dovresti vedere di cosa sono capaci questi volumi in questione ( SQLIO è una grande utilità per quello) e cosa stanno facendo in questo momento (è bello avere una base di riferimento quando i volumi sono stati alzati per confrontarsi con un benchmark attuale).

Ecco un ottimo articolo che spiega questo messaggio: come funziona: quando viene aggiunto il messaggio FlushCache al registro errori di SQL Server?

EDIT : rileggere la tua domanda, devo aver perso questo commento:

Ho notato che ogni mattina intorno alle 5 siamo iniziati a ricevere questo messaggio

Guarda cosa sta succedendo sul tuo archivio in questo momento secondo la guida sopra. Sembra un'operazione programmata per i libri di testo che sta causando un tributo alla memoria causando sofferenza e "durata" delle prestazioni del checkpoint.


2
SQLIO è stato superato da Diskspd.exe in base al collegamento fornito. Ecco il link a Diskspd.exe: gallery.technet.microsoft.com/DiskSpd-a-robust-storage-6cd2f223
Tim Coker
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.