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

Question

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

所以我的问题是，磁盘是否可以在8小时内达到每秒500次读写？

Answer 1

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

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

如果不考虑磁盘类型、工作负载等情况，任何数字都不会太好或太坏。

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

1. 用于存放临时数据库的Tempdb.
2. Multiple数据文件(4-8通常是一个好数字)的专用驱动器。
3. 启用了跟踪标志1118和1117。
4. 用于存放所有数据库的数据文件的专用驱动器。
5. 用于存放所有数据库日志文件的专用驱动器。
6. 用于存放日志文件的专用驱动器设置为正常的MB数，而不是默认的10%。
7. 和其他一些东西，简单地谷歌一下，你就会在网上找到很多东西。

按照最佳做法中的定义设置数据库设置后，使用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，考虑到它是一个固态硬盘，理想情况下你的总体延迟应该小于5。但即使它大于5，它也不一定是一个坏数字。

同样，这取决于工作负载。如果有很多查询正在访问tempdb (这在OLTP数据库中不应该真正发生)，那么您可能需要开始查看您的代码，并尝试优化那些经常访问tempdb的查询。

长话短说，与其先查看性能计数器，然后尝试找出是否存在问题，为什么不先询问SQL Server最困扰它的是什么，然后先尝试解决这个问题:)

尽管对于一个非常简短的问题，我的答案看起来很长，但相信我，在你得出任何结论之前，有很多事情要做，很多事情需要考虑。我的建议是阅读如何收集SQL Server指标，以及如何将它们转化为真正的结论。

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