我们正在忙于负载测试我们在.NET 4.0中开发的OLTP系统,并在后面运行SQL Server 2008 R2。该系统使用性能非常出色的SQL Server Service Broker队列,但是在处理过程中我们遇到了一种特殊的趋势。
SQL Server处理请求的速度为1分钟,然后增加磁盘写入活动的时间约20秒。下图说明了该问题。
Yellow = Transactions per second
Blue = Total CPU usage
Red = Sqlsrv Disk Write Bytes/s
Green = Sqlsrv Disk Read Bytes/s
在故障排除期间,我们尝试了以下操作,但模式没有任何重大变化:
- 停止SQL Server代理。
- 几乎杀死了所有其他正在运行的进程(没有A / V,SSMS,VS,Windows资源管理器等)
- 删除了所有其他数据库。
- 禁用所有对话计时器(我们不使用任何触发器)。
- 从消息队列驱动的方法转移到简单/粗略的表监视设计。
- 从轻到重使用了不同的负载。
- 修复了所有死锁。
似乎SQL Server可能正在建立其缓存并以特定的基于时间的时间间隔将其写入磁盘,但是我找不到任何在线资源来支持该理论。
接下来,我计划将解决方案移至我们专用的测试环境,以查看是否可以重现问题。在此期间的任何帮助将不胜感激。
Update 1 根据要求,提供一个图形,其中包括Checkpoint Pages / Sec,Page Life Expectancy和一些磁盘延迟计数器。
似乎检查点(浅蓝色线)是导致我们观察到的性能下降(黄线)的原因。^
磁盘延迟在处理过程中保持相对一致,并且页面预期寿命似乎没有任何明显的影响。我们还调整了可用于SQL Server的ram数量,这也没有太大的影响。将恢复模式从更改SIMPLE
为FULL
也没有什么不同。
更新2 通过如下更改“恢复间隔”,我们设法减小了检查点的间隔:
EXEC sp_configure 'show advanced options',1
GO
RECONFIGURE
GO
EXEC sp_configure 'recovery interval', '30'
GO
RECONFIGURE
GO
EXEC sp_configure 'show advanced options',0
GO
RECONFIGURE
我不确定这是否是不好的做法?
FULL
或中BULK_LOGGED
,在SIMPLE
执行完整备份之前,数据库的行为也仍与数据库一样。