Messages FlushCache apparaissant dans le journal à des moments spécifiques

Nous avons eu beaucoup de problèmes de performances de base de données ces derniers temps, et j'ai essayé de voir si je pouvais comprendre pourquoi. Nous n'avons pas de DBA (je suis un développeur de logiciels), donc je suis en quelque sorte en train de le lancer, et une grande partie de ce que je trouve en ligne se lit comme une langue étrangère pour moi.

Nous avons redémarré SQL Server tous les matins car c'est la seule façon dont il est opérationnel pendant la journée de travail. J'ai remarqué que chaque matin vers 5 heures du matin, nous commençons à recevoir ce message toutes les deux minutes dans le journal:

FlushCache: nettoyé 11848 bufs avec 7432 écritures en 97168 ms (évité 8139 nouveaux bufs sales) pour db 9: 0

dernière cible en attente: 4, avgWriteLatency 32

débit moyen: 0,72 Mo / s, saturation E / S: 11635, commutateurs de contexte 18849

Les chiffres diffèrent à chaque fois bien sûr, mais c'est le même message encore et encore dans ce modèle jusqu'à ce que je redémarre le serveur. Je ne sais pas comment interpréter cela, j'ai essayé de Google à ce sujet et tout ce que j'ai rassemblé, c'est que cela signifie qu'il pourrait y avoir quelque chose de mal avec les E / S et que quelque chose prend plus de temps que prévu. Nous sommes récemment passés à l'utilisation de SSD, donc je ne pensais pas que cela devrait être un problème d'écriture.

Quelqu'un pourrait-il nous éclairer là-dessus?

Le message FlushCache dans le journal des erreurs est provoqué par la journalisation du point de contrôle, et dans ce cas par un long point de contrôle (qui est défini comme un point de contrôle qui prend plus de temps que l'intervalle de récupération). Qu'il soit connecté ou non, le comportement est différent avant 2012 et 2012+. Avant SQL Server 2012, pour obtenir la journalisation des points de contrôle, vous devez activer un indicateur de trace (T3504). Mais à partir de SQL Server 2012, ce message est enregistré par défaut lorsqu'un long point de contrôle est rencontré.

Maintenant, en ce qui concerne la question "est-ce vraiment mauvais ?" , vous devez vraiment commencer à examiner ces chiffres en fonction de leur contexte. Il vous a fallu plus de 97 secondes pour vider seulement environ 93 Mo de tampons sales. Il semble que cela pourrait être un mélange de nombreuses pertes de données (pendant le point de contrôle lui-même, environ 64 Mo de tampons étaient également sales) et potentiellement un stockage qui ne suit pas la modification des données et / ou le reste de la charge de travail d'E / S.

Ce que je ferais, c'est de vérifier la santé de votre sous - système de stockage , de regarder les attentes et d'obtenir simplement une image globale des performances de l'instance. Jetez un oeil à disque logique compteurs perfmon et voir ce que le taux de résiliation global E / S avec le débit , la latence et IOps . Il vous aidera à brosser un tableau plus vivant de la performance des disques. Si vous avez la possibilité de comparer votre stockage, si vous ne l'avez pas déjà défini, vous devriez voir de quoi ces volumes en question sont capables ( SQLIO est un excellent utilitaire pour cela) et ce qu'ils font en ce moment (c'est agréable de avoir une référence de référence lorsque les volumes ont été comparés à une référence actuelle).

Voici un excellent article expliquant ce message - Comment cela fonctionne: Quand le message FlushCache est-il ajouté au journal des erreurs SQL Server?

EDIT : En relisant votre question, j'ai dû manquer ce commentaire:

J'ai remarqué que chaque matin vers 5 heures du matin, nous commençons à recevoir ce message

Voyez ce qui se passe sur votre stockage en ce moment selon les instructions ci-dessus. Cela ressemble à une opération planifiée de manuel qui pèse sur le stockage, ce qui fait que les performances du point de contrôle souffrent et sont "longues".