特定の時間にログに表示されるFlushCacheメッセージ

最近、多くのデータベースパフォーマンスの問題が発生しており、その理由を理解できるかどうかを確認しようとしてきました。私たちにはDBA（私はソフトウェア開発者）がいないので、私はただそれを翼に乗せているようなもので、オンラインで見つけたものの多くは外国語のように読めます。

SQL Serverは毎朝再起動します。これが、稼働中にSQL Serverを操作できる唯一の方法だからです。毎朝午前5時ごろに、ログで2分ごとにこのメッセージを取得し始めていることに気付きました。

FlushCache：db 9：0の97168ミリ秒で7432の書き込みで11848 bufsをクリーンアップ（8139の新しいダーティbufsを回避）

最後の未解決のターゲット：4、avgWriteLatency 32

平均スループット：0.72 MB /秒、I / O飽和：11635、コンテキストスイッチ18849

数字はもちろん毎回異なりますが、サーバーを再起動するまで同じパターンで何度も同じメッセージが表示されます。私はこれをどのように解釈するかわからない、私はそれについてグーグルにしようとしてきたし、私が集めたのは、I / Oに何か問題があるかもしれないということであり、何かが予想以上に時間がかかっているということです。最近SSDの使用に切り替えたので、書き込みの問題になるとは思いませんでした。

誰もこれに光を当てることができますか？

エラーログのFlushCacheメッセージは、チェックポイントロギングが原因で、この場合は長いチェックポイント（リカバリ間隔よりも長い時間がかかるチェックポイントとして定義されている）が原因です。ログに記録されるかどうかにかかわらず、動作は2012年以前と2012以降で異なります。SQL Server 2012より前は、チェックポイントログを取得するには、トレースフラグをオンにする必要がありました（T3504）。ただし、SQL Server 2012以降では、長いチェックポイントが検出されると、デフォルトでそのメッセージがログに記録されます。

さて、「これは実際に悪いのか？」、コンテキストを考慮してこれらの数値を確認する必要があります。約93 MBのダーティバッファのみをフラッシュするのに97秒以上かかりました。これは、大量のデータチャーン（実際のチェックポイント自体の間、約64 MBのバッファもダーティになった）と、データの変更や残りに追いついていないストレージが混在する可能性があるようですI / Oワークロードの。

私は何だろうと、あるストレージ・サブシステムの健全性を確認し、待機を見て、ちょうどインスタンスの全体的なパフォーマンスの画像を取得します。見てみましょうカウンターパフォーマンスモニタの論理ディスクを、全体的なI / Oの解約はしているものを見るスループット、レイテンシー、およびIOPS。ディスクのパフォーマンスをより鮮明に描くのに役立ちます。ストレージのベンチマークを行う能力がある場合、まだベースラインを設定していない場合は、問題のこれらのボリュームの能力（SQLIOはそのための優れたユーティリティです）および現在実行していることを確認する必要があります（現在のベンチマークと比較するためにボリュームが立ち上がったときのベンチマークベースラインがあります）。

このメッセージを説明するすばらしい記事があります- 仕組み：SQL ServerエラーログにFlushCacheメッセージが追加されるのはいつですか？

編集：あなたの質問を読み直して、私はこのコメントを見逃したに違いない：

毎朝午前5時ごろにこのメッセージを受け取り始めていることに気づきました

上記のガイダンスに従って、現時点でストレージで何が起こっているかを確認してください。これは、チェックポイントのパフォーマンスが低下し、「長く」なる原因となる、ストレージに負荷をかけている教科書のスケジュールされた操作のように聞こえます。