SQL Server 2008 I/O性能监控

原文首发于it168，链接见http://tech.it168.com/a2011/0221/1158/000001158998.shtml

　　I/O性能诊断

　　SQL Server性能非常依赖于I/O子系统。除非你的数据库适合物理内存，SQL Server经常地会有数据库页面进出缓存池。这样就发生了实质的I/O流量。同样，在事务被明确的提交前，日志记录需要写入磁盘。SQL Server为各种目的可以使用tempdb，例如存储中间结果，排序，保持行的版本或其他。所以好的I/O子系统对于SQL Server性能非常重要。

　　I/O的性能取决于以下一些方面：

　　磁盘类型包括IDE、SATA、SCSI、SAS、Fibre Channel drive等类型，其中IDE、SATA一般用在个人电脑上。

　　同时为了在数据安全、数据性能和数据容量之间做平衡，又发展出了RAID，RAID是一种把多块独立的磁盘按不同的方式组合起来形成一个硬盘组，从而提供比单个硬盘更高的存储性能和提高数据备份技术。RAID主要包括RAID0~RAID7等几个规范，常用的RAID类型为RAID0、RAID1、RAID5,RAID10。

　 　此外根据连接方式不同还可以分为：Direct Attached Storage(DAS)，Storage Area Networks(SAN)，Fibre Channel Storage Area Networks，iSCSI Storage Area Networks。

　　吞吐量和IOPS指标

　　吞吐量主要取决于阵列的架构，光纤通道的大小以及硬盘的个 数。阵列的架构与每个阵列不同，但也都存在内部带宽，不过在一般情况下，内部带宽都设计的很充足，不是瓶颈所在。其次是光纤通道对数据流量的影响，为了达 到1GB/s的数据流量要求，我们必须使用1GB*8=8GB的光纤卡，也可以用4块2GB的光纤卡。其实是硬盘的个数，可以参考以下指标计算方式，假设 为了满足1GB的数据流量要求，所必须的磁盘个数。

　　IOPS(Input/Output Operations Per Second)，即每秒进行读写(I/O)操作的次数，多用于数据库等场合，衡量随机访问的性能。

　　决定IOPS的主要取决于阵列的算法、cache命中率以及磁盘个数。Cache命中率取决于数据的分布、Cache Size的大小、数据的访问规则，以及Cache的算法。

　 　磁盘的限制，每个磁盘能处理的IOPS是有限制的，通常情况下每个磁盘的最大IOPS是确定的，比如IDE和SATA硬盘的IOPS大致在100以内 (我们可以使用HD Tune工具进行IOPS测试)，而且IOPS的测试结果与测试方式(例如随机读写和顺序读写、读和写的比例、传输数据库尺寸的大小、磁盘的数量)有很大 关系，尽管如此磁盘的IOPS指标还是对我们评估磁盘的压力和是否能够满足系统的性能需求有着一定的指导意义。

　　假设现在的业务需求是10000 IOPS，120块SCSI磁盘，那么在不同的Cache命中率、不同的读写比例情况下，不同的RAID级别对每块磁盘的IOPS需求是多少呢?

　　Raid 0 –每个磁盘的I/O计算= (读+写) /磁盘个数

　　Raid 1 --每个磁盘的I/O计算= [读+(2*写)]/2

　　Raid 5 --每个磁盘的I/O计算= [读+(4*写)]/磁盘个数

　　Raid 10 --每个磁盘的I/O计算= [读+(2*写)]/磁盘个数

　　此外当吞吐率超过85%时，会出现I/O瓶颈，因此单个磁盘IOPS计算规则为

　　((10000*(1-Cache命中率)*读比例)+10000*写比例*RAID系数)/磁盘数/0.85

　　即每块磁盘的IOPS大约在200左右即可满足RAID0、RAID5、RAID10的要求。

　　此外，关于SQL Server的部署一般规划和建议如下：

　　操作系统和SQL Server单独构建在RAID1的磁盘镜像上;出于高速和安全的原则，日志文件需要单独安装在RAID1/RAID10上;tempdb文件最好放在RAID0上，而数据文件出于安全、性能、容量、成本的综合考虑一般则使用RAID5。

　　在微软的technet上有一篇关于存储的最佳实践top 10(Storage Top 10 Best Practices)是这么要求的：

　　1. 了解SQL Server的IO特性和应用系统的IO需求规格。

　　2. 使用更多/更快的磁盘驱动以获取良好的性能

　　3. 不要过度优化存储，简单的设计通常能够提供良好的性能和灵活性。

　　4. 部署前验证配置。可以用SQLIO之类的工具模拟测试。

　　5. 始终把日志文件放在RAID10/RAID1上。

　　6. 把日志文件和数据文件从物理磁盘上隔离。

　　7. 认真考虑TempDB的数据配置。

　　8. 在数据文件的数量和CPU的容量之间平衡。

　　9. 不要忽视SQL Server的基础。

　　10.不要忽视存储的配置

　　对于SQL Server占用I/O资源的监控主要集中在磁盘响应时间、队列长度、磁盘读写和传输速度上。下面提供了几种对象、计数器和相应的阈值及描述。

　　Sys.dm_io_virtual_file_stats能够返回数据和日志文件的 I/O 统计信息，这也为我们从整体上了解各磁盘和数据库的吞吐量和等待时间有了一个直观的认识。

　 　sys.dm_io_pending_io_requests则对应SQL Server 中每个挂起的 I/O 请求，我们将sys.dm_io_pending_io_requests和Sys.dm_io_virtual_file_stats关联起来，则可以 查看当前是否有等待的IO，然后进行去定位和识别。