FlushCache 消息在特定时间出现在日志中

Question

最近我们遇到了很多数据库性能问题，我一直在尝试找出原因。我们没有 DBA（我是一名软件开发人员），所以我只是在摸索，而且我在网上找到的大部分内容对我来说就像一门外语。

我们每天早上都会重新启动 SQL Server，因为这是它在工作日运行的唯一方式。我注意到每天早上 5 点左右，我们开始每两分钟在日志中收到一条消息：

FlushCache：在 97168 毫秒内清理了 11848 个 buf，其中 7432 次写入（避免了 8139 个新的脏 buf）用于 db 9:0

最后一个未完成的目标：4，avgWriteLatency 32

平均吞吐量：0.72 MB/秒，I/O 饱和度：11635，上下文切换 18849

当然，每次的数字都不同，但是在我重新启动服务器之前，它以该模式一遍又一遍地传递相同的消息。我不知道如何解释这一点，我一直在尝试谷歌搜索，我收集到的只是这意味着 I/O 可能有问题，并且某些事情花费的时间比预期的要长。我们最近改用SSD，所以我认为这应该不是写入问题。

任何人都可以对此有所了解吗？

Answer 1

错误日志中的 FlushCache 消息是由检查点日志记录引起的，在这种情况下是由长检查点（定义为比恢复间隔时间长的检查点）引起的。无论是否记录，2012 年之前和 2012+ 年的行为都不同。在 SQL Server 2012 之前，要获取检查点日志记录，您必须打开跟踪标志 (T3504)。但是从 SQL Server 2012 开始，当遇到长检查点时，默认情况下会记录该消息。

现在至于“这真的很糟糕吗？”的问题。，您确实需要根据上下文开始查看这些数字。仅刷新大约 93 MB 的脏缓冲区需要 97 秒以上的时间。这看起来可能是大量数据搅动（在实际检查点本身期间，大约 64 MB 的缓冲区也被弄脏了）和可能跟不上数据修改和/或其余部分的潜在存储的混合的 I/O 工作负载。

我要做的是验证您的存储子系统的健康状况，查看等待时间，然后获得实例的整体性能图。查看逻辑磁盘性能计数器，了解吞吐量、延迟和IOps的整体 I/O 流失情况。它将帮助您更生动地描绘磁盘的性能。如果你有能力对你的存储进行基准测试，如果你还没有对它进行基线测试，你应该看看这些卷有什么能力（SQLIO是一个很好的实用程序）以及他们现在正在做什么（很高兴当数量与当前基准进行比较时，有一个基准基线）。

这是一篇解释此消息的精彩文章 -工作原理：FlushCache 消息何时添加到 SQL Server 错误日志？

编辑：重新阅读你的问题，我一定错过了这个评论：

我注意到每天早上 5 点左右我们开始收到这条消息

根据上述指导，查看此时您的存储上发生了什么。这听起来像是教科书式的预定操作，它对存储造成了影响，导致检查点性能受到影响并且“很长”。