Server 2012 IO延迟和等待类型

Question

我正在研究一个系统，它有一份资源密集型的保藏工作。它访问相同LUN上的两个不同的数据文件。一个用于关系数据，一个用于blobs。在工作期间，关系数据文件的读取延迟平均超过250 5ms，而在LOB数据上只有5 5ms。这是使用sys.dm_io_virtual_file_stats测量的(两个样本间隔12小时，包括保藏-在其他12小时内，延迟为20 is )。

我使用“谁是活跃的”对等待状态进行采样。在这种情况下，我没有看到任何PAGEIOLATCH等待时间足够大，足以解释250 In。sys.dm_os_wait_stats支持这一点，平均PAGEIOLATCH_EX为5 5ms，PAGEIOLATCH_SH为15 5ms。我看到的是等待LCK_M的时间很长(由于内务管理的性质，这是可以解释的)。

我的问题是：LCK_M等待可以在虚拟文件统计中贡献io_stall_read_ms时间吗？

为了防止内部管理的细节问题，它使用多个级联熟料(包括每项1MB的LOB数据)删除小批数据。系统使用同步提交的AlwaysOn。

Answer 1

在sys.dm_io_virtual_stats中看到的等待是聚合的，而不是点值。如果您在某一段时间内做了大量的事务，它将显示出更高的聚合->更高的平均延迟。有关此dmv工作方式的更多信息，可在https://sqlperformance.com/2013/10/t-sql-queries/io-latency上找到。

当您想了解Server实例的I/O性能时，虚拟文件统计数据是一个很好的起点。如果您在查看等待统计数据时看到与I/O相关的等待，那么查看sys.dm_io_virtual_file_stats是逻辑的下一步。但是，请理解您正在查看的数据是一个聚合数据，因为相关事件之一(例如重新启动、离线数据库等)最后清除了这些统计数据。如果您看到延迟较低，则I/O子系统将与性能负载保持一致。但是，如果您看到延迟时间很长，那么存储是一个问题，这不是一个预先确定的结论。要真正了解发生了什么，您可以开始快照文件统计，如这里所示，或者您可以简单地使用性能监视器来实时查看延迟。在PerfMon中创建一个数据收集器集非常容易，它捕获物理磁盘计数器Avg。磁盘Sec/Read和Avg。存储数据库文件的所有磁盘的磁盘Sec/Read。

LCK_M不会贡献给IO_STALL_READ_MS，因为这些计数器只与IO相关。

Answer 2

我错过了显而易见的解释。

io_stall测量提交和完成io之间的差异。等待状态只有在查询没有有用的功能时才会测量。

我所看到的数字表明：

1. 由于内务管理负载，IO延迟显著增加。
2. 内务查询通常可以找到其他有用的工作来完成，而不是等待IO完成。(否则我会看到高PAGEIOLATCH等待)