Question

我们的Web应用程序每天处理大量并发请求，每天8小时。此时，根据性能监视器，磁盘I / O（特别是在tempdb数据库日志文件中）每秒最多可读取470次读写操作。当此数字超过500时，性能监视器会将磁盘标记为忙。但所使用的磁盘是高性能SSD驱动器，可在AWS上托管，最高可处理5000 IOPS。

所以我的问题是磁盘确定，每秒最多500次读写 - 最多8小时？

Answer 1

我认为你需要改变你的方法，首先在SQL Server中查看IO相关数字，IO延迟等指标。

默认情况下，SQL Server会为您收集此信息，如果您在SQL Server中看到较大的延迟，则转到服务器并开始收集性能计数器和其他内容。

如果不考虑磁盘类型，工作负载等情况，没有数字太好或太差。

我建议，首先要确保您遵循所有可行的最佳做法，例如：

Tempdb的专用驱动器。
tempdb的多个数据文件（4-8通常是一个很好的数字）。
启用跟踪标志1118和1117。
所有数据库的数据文件的专用驱动器。
所有数据库的日志文件专用驱动器。
自动增长设置为健康的MB数，而不是默认的10％。
还有一些其他的东西，只需google它，你就会在网上找到很多东西。

按照最佳做法中的定义设置数据库设置后，使用SQL Server DMV开始查看每个驱动器的IO延迟。我通常用来检查延迟的查询是：

SELECT tab.[Drive], tab.volume_mount_point AS [Volume Mount Point], 
    CASE 
        WHEN num_of_reads = 0 THEN 0 
        ELSE (io_stall_read_ms/num_of_reads) 
    END AS [Read Latency],
    CASE 
        WHEN num_of_writes = 0 THEN 0 
        ELSE (io_stall_write_ms/num_of_writes) 
    END AS [Write Latency],
    CASE 
        WHEN (num_of_reads = 0 AND num_of_writes = 0) THEN 0 
        ELSE (io_stall/(num_of_reads + num_of_writes)) 
    END AS [Overall Latency],
    CASE 
        WHEN num_of_reads = 0 THEN 0 
        ELSE (num_of_bytes_read/num_of_reads) 
    END AS [Avg Bytes/Read],
    CASE 
        WHEN num_of_writes = 0 THEN 0 
        ELSE (num_of_bytes_written/num_of_writes) 
    END AS [Avg Bytes/Write],
    CASE 
        WHEN (num_of_reads = 0 AND num_of_writes = 0) THEN 0 
        ELSE ((num_of_bytes_read + num_of_bytes_written)/(num_of_reads + num_of_writes)) 
    END AS [Avg Bytes/Transfer]
FROM (SELECT LEFT(UPPER(mf.physical_name), 2) AS Drive, SUM(num_of_reads) AS num_of_reads,
             SUM(io_stall_read_ms) AS io_stall_read_ms, SUM(num_of_writes) AS num_of_writes,
             SUM(io_stall_write_ms) AS io_stall_write_ms, SUM(num_of_bytes_read) AS num_of_bytes_read,
             SUM(num_of_bytes_written) AS num_of_bytes_written, SUM(io_stall) AS io_stall, vs.volume_mount_point 
      FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS vfs
      INNER JOIN sys.master_files AS mf WITH (NOLOCK)
      ON vfs.database_id = mf.database_id AND vfs.file_id = mf.file_id
      CROSS APPLY sys.dm_os_volume_stats(mf.database_id, mf.[file_id]) AS vs 
      GROUP BY LEFT(UPPER(mf.physical_name), 2), vs.volume_mount_point) AS tab
ORDER BY [Overall Latency];

您应该开始考虑的数字是Overall Latency，考虑到它是一个SSD，您的总体延迟应该理想地小于5。但即使它超过5，也不一定是坏数字。

同样取决于工作量。如果很多查询都在命中tempdb（在OLTP数据库中不应该发生这种情况），那么你可能需要开始查看代码并尝试优化大量访问tempdb的查询。

长话短说而不是首先查看性能计数器，然后尝试弄清楚它是否是一个问题，为什么不首先问问SQL Server最困扰的是什么并尝试先解决它:)

即使我的答案看起来很长，但是很短的问题，但相信我还有很多工作要做，在得出任何结论之前还有很多事要考虑。我的建议是阅读如何收集SQL Server指标以及如何使用它们转化为真正的结论。

单独一个度量标准无法解决问题或修复问题，它是一个企业应用程序，您需要在其上下文中查看大量内容才能得出有意义的结论。希望这可以帮助。

我们什么时候应该关注磁盘I / O？

1 个答案: