SQL Server 2008内存及I/O性能监控

核心提示：在针对window 32位系统环境下，编者对SQL Server 2008进行了内存性能和I/O性能的监控和诊断，并作了分析。文中主要分三个模块，分别为：SQL Server 2008内存性能介绍、SQL Server 2008内存管理与系统视图和SQL Server 2008的I/O性能诊断。

在针对window 32位系统环境下，编者对SQL Server 2008进行了内存性能和I/O性能的监控和诊断，并作了分析。文中主要分三个模块，分别为：SQL Server 2008内存性能介绍、SQL Server 2008内存管理与系统视图和SQL Server 2008的I/O性能诊断。

内存相关概念

如下均是针对Window 32位系统环境下，64位的不在下面描述状况下。

用户模式和内核模式(user mode& kernel mode)

为了防止用户程序访问并篡改操做系统的关键部分，Windows使用了2种处理器存取模式：用户模式和内核模式。顾名思义，内核模式是给操做系统核心代码和基本驱动用的，用户模式给用户应用程序。在内核模式下程序能够访问全部的内存和硬件，并使用全部的处理器指令。操做系统程序比用户程序有更高的权限，使得系统设计者能够确保用户程序不会意外的破坏系统的稳定性。

物理内存(Physical Memory)

即实际购买的内存的大小，内存条上的容量。CPU的地址线能够直接进行寻址的内存空间大小，在32位操做系统平台上，CPU的最大寻址空间为4GB，也便可以支持最大4G的物理内存空间。在32位操做系统上即使你购买的是64G内存，也只能说拥有4GB的物理内存空间

虚拟内存(Virtual Memory)

若是计算机缺乏运行程序或操做所需的随机存储内存，则Windows使用虚拟内存进行补偿。虚拟内存将计算机的RAM和硬盘上的临时空间组合在一块儿，当RAM不足时，虚拟内存将数据从RAM移动到称为“分页文件”的空间中，将数据移入与移出分页文件能够释放RAM，以便完成工做。

虚拟地址空间(Virtual Address Space，简称VAS)

在Windows系统中，任何一个进程都被赋予了其本身的虚拟地址空间，该虚拟地址空间覆盖了一个至关大的范围，对于32位系统的虚拟地址空间范围从0x00000000~0xffffffff(4GB)。Windows采用分页机制，将4G的地址空间分红固定大小的页，而且将虚拟地址中的每一页映射到物理内存中。

在缺省的状况下虚拟地址空间中的低2G，即0x0000000~0x7FFFFFFFF是用户地址空间，而4G虚拟地址空间中的高2G即0x8000000~0xFFFFFFFF是分配给内核模式。实际上用户进程拥有的虚拟地址空间只有2GB。

虚拟内存管理器(Virtual Memory Manager)

虚拟内存管理器负责虚拟地址空间和物理内存的地址映射，若是缺少足够内存，则须要使用到page file文件来保持临时数据也即虚拟内存，同时使用page table entry(PTE)来跟踪每个地址映射关系。

到这里为止，64G的内存有60G都没法访问，岂不是浪费了，那怎么办?

/3GB和increaseUserVA

经过/3GB的方式，能够减小内核模式占用地址空间，从而增长SQL Server进程的地址空间。默认状况下，用户模式和内核模式各自占用2G寻址空间，3G选项可使得SQL Server得到多1G的虚拟地址空间。

/3GB开关用法：

在Boot.ini文件中修改其中的段落便可

或者使用bootcfg命令

在Windows Server 2008中能够运行BCDEdit命令，加以调整。

物理地址扩展PAE(Physical Address Extension)

物理地址扩展(PAE)是32位Intel CPU的一种扩展，这样能够在32位系统上支持最大64G的物理内存，即4GB以上物理内存容许将更多物理内存映射为应用程序的虚拟地址空间。

使用方式,在Boot.ini文件中修改其中的段落便可：

在Windows Server 2008操做系统下也能够经过如下命令执行

/PAE和/3GB

二者的目标是不一样的，又能够在一样的地方进行配置，因此不免产生疑惑，简单的来讲就是若是计算机可用物理内存超过16GB，就须要确保boot.ini文件中没有/3gb参数便可。

地址窗口化扩展插件AWE(Address Windowing Extensions)

AWE是Windows的内存管理功能的一组扩展，它可以使应用程序使用的内存量超过经过标准32位寻址可以使用的2~3G内存。AWE容许应用程序获取物理内存，而后将非分页内存的视图映射到32位地址空间。虽然32位地址空间限制为4GB，可是非分页内存却能够远远大于4GB。

在SQL Server 2008下，能够登陆SQL Server Management Studio，找到相应的数据库实例，点击右键选择属性，而后在“选择页”中点击内存，在服务器内存选项中，复选使用AWE分配内存便可。

SQLServer的内存管理

SQL Server 主要的内存组件是缓冲池。其中高速数据缓冲区用以把数据从磁盘加载到内存中，实现数据的高速读写。而过程高速缓冲区则用来存储相应的执行计划，减小编译过程，也是高速缓冲仓库的主要构成部分。用户仓库高速缓冲是用户仓库的主要组成本部分。对象仓库则仅仅是内存块组成的内存池，不须要进行LRU或成本计算例如SQL Server网络接口(SNI)利用对象存储仓库做为网络缓冲池。

SQL Server 内存管理器由一个三层的层次结构组成。该层次结构的底层为内存节点。下一层由内存 Clerk、内存缓存和内存池组成。最后一层由内存对象组成。这些对象一般用于在 SQL Server 实例中分配内存。

内存节点(sys.dm_os_memory_nodes)提供低级分配器的界面和实现。在NUMA中内存节点和CPU节点能够对应起来的，在 SQL Server 中，只有内存 Clerk 可访问内存节点。

内存 Clerk(sys.dm_os_memory_clerks) 访问内存节点界面以分配内存。内存节点还会跟踪 Clerk 分配的内存以进行诊断。分配大量内存的每一个组件，都必须使用 Clerk 界面来建立其本身的内存 Clerk 并分配其所有内存。各组件会在 SQL Server 启动时建立其相应的 Clerk。

内存对象(sys.dm_os_memory_objects)是指多个堆。它们所提供的分配的粒度比内存 Clerk 所提供的分配的粒度更精细。SQL Server 组件使用内存对象，而不使用内存 Clerk。内存对象使用内存 Clerk 的页分配器接口来分配页。内存对象不使用虚拟内存接口或共享内存接口。根据分配模式的不一样，组件能够建立不一样的内存对象类型来分配任意大小的区域。

SQL Server的缓冲池只提供8KB的内存块;大于8KB的大内存块需求是被单独管理的，且通常是直接从操做系统或者说是从缓冲池外获取到的，此外只有数据高速缓冲页面才能使用AWE内存，而且须要单独跟踪。

SQLServer的内存方面的系统视图

sys.dm_os_memory_cache_clock_hands 返回特定缓存时钟的每一个指针的状态。提供给用户关于每一个缓存存储区和用户存储区的时钟指针信息——指针是否正在转动、圈数、被移除的条目数量等。此视图对于查找当前时钟指针的状态以及时钟指针的移动历史很是有用。

sys.dm_os_memory_cache_counters 返回缓存运行情况的快照。提供有关已分配的缓存条目、缓存条目的使用状况以及内存源的运行时信息。提供给用户每一个存储区的总结信息——使用的内存数量、条目数、正在使用的条目数。用户可使用该视图找到缓存的内存使用，以及一个缓存中的条目数量。

sys.dm_os_memory_cache_hash_tables 针对 SQL Server 实例中的每一个活动缓存返回一行。即用户关于缓存存储区的散列表信息——最大、最小、平均桶长等。此视图对于查找缓存存储区中每一个缓存表的每一个散列桶的条目分布很是有用。

sys.dm_os_memory_cache_entries 返回有关缓存中全部条目的信息。使用此视图可对缓存条目进行跟踪，直至它们的关联对象。还可以使用此视图获取有关缓存条目的统计信息。

sys.dm_os_sys_info返回一组有关计算机和有关 SQL Server 可用资源及其已占用资源的有用杂项信息。

sys.dm_os_sys_memory 从操做系统返回内存信息。SQL Server 受操做系统级别的外部内存条件和基础硬件物理限制的约束并对其有所响应。肯定整个系统的状态是评估 SQL Server 内存使用量的重要方面。

sys.dm_os_virtual_address_dump则返回有关调用进程的虚拟地址空间中的页范围的信息。

DBCC MemoryStatus命令提供了SQL Server的当前内存状态的快照，也能够做为咱们分析内存瓶颈的重要依据。

内存压力

对于SQL Server占用内存资源的监控主要集中在页面吞吐能力、页面错误和可用内存上上，对虚拟内存的监控，则重点在于分页文件的使用率上。下面提供了几种对象、计数器和相应的阈值及描述。

SQL Server提供的sys.dm_os_performance_counters计数器视图，主要对缓冲区管理器和内存管理器的一些计数器进行监控，好比页面的生存周期、检查点、惰性写入器和缓冲命中率等指标。

如下为缓冲池内数据库缓冲池中各个数据库的分布状况。

如下为返回当前数据库中每一个对象的缓存页计数，加以适当的修改咱们也能够获得数据缓冲池中对象数据页和索引页的分布状况。

下为缓冲池中前十位消耗内存最大的内存组件。

咱们须要重点关注的内存组件为如下：

sys.dm_exec_cached_plans针对 SQL Server 为了加快查询执行而缓存的每一个查询计划返回一行。能够用此动态管理视图来查找缓存的查询计划、缓存的查询文本、缓存计划占用的内存量，以及从新使用缓存计划的计数。一样咱们还能够和sys.dm_exec_sql_text联合起来进一步加工获取到缓冲最大的前10条SQL。

CACHESTORE_SQLCP—SQL执行计划(临时缓存计划、自动参数化计划和预编译计划)

CACHESTORE_OBJCP—对象计划(存储过程、函数、触发器等执行计划)

CACHESTORE_PHDR—Bound Trees是在SQL Server中代数化的结构过程，被用于视图、约束和默认值。

CACHESTORE_XPRO是预约义的系统存储过程，这里仅包含实现过程的函数名称和DLL名称。

如下SQL用来确认在缓冲区外进行分配了内存的内部组件(即经过多页分配器请求内存)，借以了解内存是否存在压力。

sys.dm_exec_cached_plans针对 SQL Server 为了加快查询执行而缓存的每一个查询计划返回一行。能够用此动态管理视图来查找缓存的查询计划、缓存的查询文本、缓存计划占用的内存量，以及从新使用缓存计划的计数。一样咱们还能够和sys.dm_exec_sql_text联合起来进一步加工获取到缓冲最大的前10条SQL。

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、RAID一、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、RAID五、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，而后进行去定位和识别。