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

Question

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

所以我的问题是磁盘可以在最多 8 小时内每秒进行 500 次读写吗？

Answer 1

我认为您需要改变处理问题的方法，首先开始查看 SQL Server 中与 IO 相关的数字，例如 IO 延迟等指标。

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

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

我建议，首先确保您尽可能遵循所有最佳实践，例如：

1. Tempdb 的专用驱动器。
2. 用于您的 tempdb 的多个数据文件（4-8 通常是一个不错的数字）。
3. 启用跟踪标志 1118 和 1117。
4. 用于所有数据库的数据文件的专用驱动器。
5. 所有数据库的日志文件专用驱动器。
6. 自动增长设置为正常的 MB 数，而不是默认的 10%。
7. 还有一些其他的东西，只需 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 指标以及如何将它们转化为真实结论的信息。

没有任何一个指标可以单独得出一个问题或解决一个问题，它是一个企业应用程序，您需要在其上下文中查看很多东西才能得出有意义的结论。希望这可以帮助。