来源: it168 发布时间: 2011-04-12 11:04 阅读: 10820 次 推荐: 1 原文链接 [收藏]
以下均是针对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、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，然后进行去定位和识别。
