我们每天早上都重新启动了sql Server,因为这是它在工作日运行的唯一方式.我注意到每天凌晨5点左右,我们开始在日志中每两分钟收到一条消息：
FlushCache: cleaned up 11848 bufs with 7432 writes in 97168 ms
(avoided 8139 new dirty bufs) for db 9:0last target outstanding: 4,avgWriteLatency 32
average throughput: 0.72 MB/sec,I/O saturation:
11635,context switches 18849
这些数字当然每次都不同,但在我重新启动服务器之前,它在该模式中反复出现相同的消息.我不知道如何解释这一点,我一直在尝试谷歌,我所收集到的是,这意味着I / O可能出现问题,而且事情需要花费的时间超过预期.我们最近改用SSD,所以我认为它不应该是写入问题.
谁能对此有所了解？
解决方法
现在关于“这真的很糟糕吗？”的问题,你真的需要根据它们的背景开始查看这些数字.花了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?
编辑：重新阅读你的问题,我一定错过了这个评论：
I noticed that every morning around 5 am we are started to get this message
根据上述指导,了解您的存储空间目前发生的情况.这听起来像教科书的预定操作会对存储造成损害,导致检查点性能受损并且“长”.
