sql-server – 来自sql server的高磁盘I / O还是高磁盘I / O减慢sql server?

前端之家收集整理的这篇文章主要介绍了sql-server – 来自sql server的高磁盘I / O还是高磁盘I / O减慢sql server?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我一直在与DBA和几个硬件人员讨论sql服务器上的性能问题.通常一切都很好,但是在过去的几周里,我们在sql server中遇到了巨大的延迟峰值.很明显,sql Server正在等待磁盘I / O.但我不断被告知,sql Server正在要求异常高的I / O.事实并非如此.我可以从正在运行的东西中看到没有任何异常,并且所有DBA关心的是导致阻塞的原因等等,这是无用的.例如,我们看到备份的主要内容是ASPState数据库上的操作,我们用它来管理Web服务器上的ASP会话状态.这些操作通常从未在Sp_who2活动结果中看到,因为它们发生得非常快.数据库处于简单恢复模式,并且日志记录是miminal.但是,在这些延迟峰值期间,我们可以看到数据库上的很多选择和更新操作被阻止或等待.我确定发生了什么事情,某人或某个工作正在运行导致用于该数据库日志和数据文件的raid阵列上的大量磁盘使用的东西.问题在于证明这一点,因为没有人愿意承认他们正在做一些杀死我们网站的事情.

我的问题是我可以记录哪些性能计数器或任何可以帮助显示sql服务器正在等待I / O,但不是因为它要求超过normaly,而不是因为磁盘是忙于响应来自sql server的请求通常会这么快?

解决方法

看看下面的perfmon计数器:

> SQL Server,Buffer Manager Object
页面查找/秒
页面读数/秒
预读页面/秒
> SQL Server,Access Methods Object
全扫描/秒
范围扫描/秒
跳过幻影记录/秒
> SQL Server,Wait Statistics Object
页面IO锁定等待

驱动大量IO请求的sql Server将通过大量扫描,增加页面查找和页面读取以及高页面IO锁存等待得到证实.对于具有高物理读数的条目,值得一看sys.dm_exec_query_stats.他们可以迅速找出罪魁祸首.

通常将问题作为性能故障排除问题处理,遵循像Waits and Queues这样的方法逻辑是正确的方法.你DBA似乎正在做正确的事,所以你应该听他说.

猜你在找的MsSQL相关文章