sql-server – 在特定时间出现在日志中的FlushCache消息

MsSQL 2020-05-19

我们最近遇到了很多数据库性能问题,而且我一直试图看看能不能找出原因.我们没有DBA(我是一名软件开发人员),所以我只是把它放在一边,而我在网上发现的很多内容对我来说就像一本外语.

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

FlushCache: cleaned up 11848 bufs with 7432 writes in 97168 ms
(avoided 8139 new dirty bufs) for db 9:0

last target outstanding: 4,avgWriteLatency 32

average throughput: 0.72 MB/sec,I/O saturation:
11635,context switches 18849

这些数字当然每次都不同,但在我重新启动服务器之前,它在该模式中反复出现相同的消息.我不知道如何解释这一点,我一直在尝试谷歌,我所收集到的是,这意味着I / O可能出现问题,而且事情需要花费的时间超过预期.我们最近改用SSD,所以我认为它不应该是写入问题.

谁能对此有所了解？

解决方法

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

现在关于“这真的很糟糕吗？”的问题,你真的需要根据它们的背景开始查看这些数字.花了97秒才刷新大约93 MB的脏缓冲区.看起来这可能是大量数据流失的混合(在实际检查点本身期间,大约64 MB的缓冲区也被弄脏了)以及可能无法跟上数据修改和/或其他数据的存储I / O工作量.

我要做的是验证存储子系统的运行状况,查看等待,然后获得实例的整体性能图.查看逻辑磁盘perfmon计数器,了解整体I / O流失与吞吐量,延迟和IOps的关系.它将帮助您描绘磁盘的运行情况.如果您有能力对存储进行基准测试,如果您尚未对其进行基线测试,那么您应该看看这些卷的功能(SQLIO是一个很好的实用工具)以及他们现在正在做什么(这很好当数量与当前基准相比时,有一个基准基线).

这是一篇很好的文章,解释了这条消息 – How It Works: When is the FlushCache message added to SQL Server Error Log?

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