sp_BlitzFirst -文件统计解释

Question

我让sp_BlizFirst每12分钟运行几天，以获取各种统计数据。

不过，我意识到，除了I/O档之外，它似乎并没有收集到很多与文件相关的性能数据。

是否有足够的信息根据等待统计和I/O档来决定I/O是否是一个问题？我在闪电战中找不到任何提到磁盘avg的地方。读取时间磁盘avg。写到时间了，阿夫格。磁盘队列长度，我认为也应该考虑吗？

有人能对下面的情况给出一些反馈吗？我的并行性数据肯定需要正确地查看(CXPACKET)，但我对磁盘i/o性能也很好奇。我认为，OLDEDB是由链接服务器和Idera诊断管理器每隔1分钟监视一次实例引起的。

我从https://www.sqlskills.com/blogs/paul/are-io-latencies-killing-your-performance/上读到:每个人都对什么是好的还是坏的I/O延迟有自己的想法，我的看法是:优秀：< 1ms非常好：< 5ms很好:5- 10 1ms很好:10-20 1ms糟糕: 20 - 100 1ms糟糕得惊人:100-500 1ms哇！>500 1ms！

如果我这么说的话，我就属于坏蛋了。

这是我的等待统计数字：

服务器1

平均读取I/O档为23.91

最大读I/O档为1162。

平均写入I/O失速为0.71。

最大写I/O失速为139。

这是完整的摘录。

服务器2

平均读数I/O档为26.28

最大读I/O档为428。

平均写I/O失速为2.60

最大写I/O失速为667。

这是完整的摘录。

Answer 1

免责声明:我是sp_BlitzFirst的作者之一，也是第一个应答者工具包。

等待统计部分位于顶部是有原因的:您需要将重点放在顶级等待类型上。如果SQL Server没有等待它们，那么驱动器的速度或速度并不重要。很好的例子:假设您拥有一个托管在服务器上的只读数据库，它有足够的内存来缓存整个数据库，并且您的查询都没有碰到TempDB。一旦数据在缓存中，你的驱动器的速度有多慢重要吗？有点-维护任务，如备份和索引重建-但不适用于最终用户查询。

现在，看看您的服务器的前3位等待：

• CXPACKET 1 530小时-与并行相关
• OLEDB 502小时(通常是无害的，但我把它留在那里，因为有时它不是大量无害的)
• LATCH_EX 250小时-通常与CXPACKET并驾齐驱
• PAGEIOLATCH_SH 191个小时-从数据文件读取数据页。

嘿，伙计-你最等的时间比你的储藏室要大十倍。

忘了储藏室吧:你撞错树了。集中精力在你的顶级等待类型上。要调优并行性，请转到https://BrentOzar.com/go/cxpacket。短篇小说：

• 将并行性的成本阈值设置为50 (有些人会说是40或75，这也没关系)
• 将MAXDOP设置为每个处理器中的核数
• 查找读取大量数据的查询，并对其或所需的索引进行优化。我最喜欢的方式是服务提供商_BlitzCache @SortOrder =‘read’
• 询问SQL Server它希望在查询执行过程中有哪些索引。我最喜欢的方法是服务提供商_BlitzIndex @GetAllDatabases = 1。