突破2G内存限制 SQL2005 AWE应用测试
只有 SQL Server 2005 Enterprise Edition、Standard Edition 和 Developer Edition 支持 AWE，并且 AWE 只能应用于 32 位操作系统。SQL Server 2005 Analysis Services (SSAS) 不能利用 AWE 映射内存。如果可用物理内存小于用户模式虚拟地址空间，则无法启用 AWE。
转载：http://tech.ddvip.com/2008-08/122008456058960.html
参考页面：http://support.microsoft.com/kb/274750/zh-cn
在我们虚拟化系列文章的数据库测试中，我们看到了数据库的测试过程会用到大量的内存，这很容易达到32bit Windows的一处限制：进程内存被限制为2GB，而通常服务器里面4GB或更多的内存很是常见，这么多内存是怎么应用的呢？它们怎么在数据库应用方面发挥力量呢？我们下面的测试可以解答相关的一系列问题。
SQL Server 2005是一个流行的关系数据库系统
程序只能使用2GB内存的这个限制是32位操作系统架构引起的。传统意义上的32bit操作系统使用32bit的内存地址，这样寻址范围就已经被限制为4GB——4G也就是2的32次方，然而通常操作系统的设计上为了安全性的考虑，应用程序和内核所处的内存地址空间是互相独立的，也就是说，应用程序和内核各自能访问2GB的内存空间。虽然不同的操作系统实现具有不同的值，不过多数现在的操作系统在这一点上都很一致。
为了让程序突破2GB寻址的限制，近代Windows NT核心提供了一个变通的方案：4GB内存调整优化技术，通过这个技术，可以将用户模式的寻址空间扩大至3GB，这样核心寻址空间便被限制为1GB了，需要超大内存容量的应用程序可以从这个特性中获得性能改善，如SQL Server数据库这种类型。要使用这个4GB内存优化技术，用户需要在Windows Server操作系统的启动参数中加入/3GB开关。这个特性同时需要操作系统打开DEP（数据执行保护，其实/3GB开关需要的是PAE的支持）。
AWE可以让32位操作系统下的进程提供64GB的地址空间
然而让用户模式程序能多寻址1GB毕竟还算是治标不治本，于是Microsoft还在自己的操作系统提供了一个比较重要的特性：AWE（Address Windowing Extension，地址窗口扩展） API集，这个API集的原理其实是基于这样的一个事实：所有的支持PAE的操作系统都有能让IA32处理器直接寻址64GB物理地址的API，回想前面的内容，物理地址是CPU处理的地址，而每个程序私有的2GB内存地址被称为虚地址范围。
每个支持PAE的操作系统都具有这种API，差别只是在于这些API能否提供如内存共享、进程间通讯、分页等等这些功能，微软在Windows上提供了一个简单明了的API组——也就是AWE地址窗口扩展API组，它仅仅由5个API调用组成，包括了核心级和用户级调用，使用AWE分配得到的内存是非分页、锁定的，其他程序无法访问，也无法交换到页面文件（虚拟内存）上去，对性能具有很大的提升。
通过使用AWE API，核心模式/用户模式可以轻易地突破2GB容量的限制，最高可以达到64GB，如SQL Server就使用了这个AWE API（可设定），从而提高对大容量内存的能力，大大提升了应用软件/系统的性能。
64bit系统中不存在这个问题，实际上，64bit系统不需要PAE的支持，也不支持AWE API，用户模式和核心模式的程序都可以直接访问非常大容量（8TB）的内存空间，可惜的是，32bit平台上遗留的大量资源，让64bit应用迄今尚未开始流行。
数据库技术是作为数据处理的一门技术而发展起来的，所研究的问题就是如何科学地组织和存储数据，如何高效地获取和处理数据。在数据库中用数据模型来抽象、表示和处理现实世界中的数据。数据库即是模拟现实世界中某应用环境（一个企业、单位或部门）所涉及的数据的集合，它不仅要反映数据本身的内容，而且要反映数据之间的联系。大部分的服务器应用都同数据库有着密切的联系。
我们采用了一组60台客户端的千兆网络环境进行了数据库测试，由于客户端所有的资源都用来产生数据库操作，因此可以给服务器施加相当大的测试压力。
Benchmark Factory 运行报告
Benchmarkfactory 4.6
我们选择了Benchmark Factory 4.6软件和Microsoft SQL2005 Enterprise来测试不同的硬件平台在数据库应用中的表现。
我们选择了BF内置的标准测试脚本AS3AP，这项测试可用于对于ANSI结构化查询语言（SQL）关系型数据库进行测试，它可用于测试DBMS（单用户微机数据库管理系统），也可用于测试高性能并行或者分布式数据库。关系性数据库就是用二维表格结构来表示实体及实体之间联系模型的数据库形式。
| DELL 2950测试平台 |
|
| 主板 | DELL |
| 处理器 | Xeon E5430 x 2 |
| 主频 | 2.66GHz |
| FSB | 1333MHz |
| L1容量 | 64K(Data容量为32K) |
| L2容量 | 12MB（共享） |
| 芯片组 | Intel 5000X |
| 内存 | 1GB FBD DDR2 667 SDRAM x 4 |
| 磁盘控制器 | LSI Logic MegaRAID SAS 8408ELP |
| 硬盘 | Seagate Cheetah 146GB 15K.5 SAS x 3 |
| 硬盘设置 | RAID 5，条带大小64KB，适应性预读，Cached IO |
| Windows硬盘设置 | 主系统分区30GB，次分区50GB，NTFS格式 |
| 操作系统 | VMware ESX Server 3.5.0 64607
Windows Server 2003 R2 EnterpriseEdition SP2 with IIS 6.0 Microsoft SQL2005 Enterprise Edition |
| 网卡 | Broadcom BCM5708C千兆网卡 X 1 |
我们采用了评测中心的一台DELL 2950服务器，配置了双路Intel 45nm Xeon E5430处理器，频率为2.66GHz，并能支持SSE4.1指令集。服务器还使用了Intel 5000X芯片组，提供24MB的Snoop Filter缓存，这可以提升高负荷时的内存/处理器性能。磁盘系统则是3块15000RPM的Cheetah 15K.5，并通过一块PCIe x8的LSI MegaRAID SAS 8708ELP来组建RAID 5阵列。
为了使用AWE，应用程序必须：
1. 使用Win32的AllocateUserPhisycalPages API函数分配扩展物理内存。该函数需要调用者具有将内存页锁定的权限。
2. 使用VirtualAlloc API函数在进程的地址空间中创建一个区域，作为与扩展物理内存进行映射的一个窗口。
3. 使用MapUserPhysicalPages或者MapUserPhysicalPagesScatter API函数，将扩展物理内存映射到这个虚拟内存窗口中。
在数据库使用AWE功能之前，必须对操作系统和SQL数据库分别进行设置。
内存锁定页面
首先应用程序要满足第一条要求，它必须能具备内存锁定页面功能，这需要在组策略中进行设置，如图所示启用SQL程序运行帐号的内存锁定页面功能。通常基于安全性的考虑会给数据库一个独立的运行帐号，这时就需要将其添加入内存锁定页面选项页。一些其他需要AWE功能的程序，也需要这样设置。
SQL2005的AWE设置很方便
随后要进入SQL2005的管理界面，将AWE选项打开。和SQL2000必须通过控制台命令打开不同，SQL2005可以在图形界面下设置，很方便。设置完毕需要重新启动SQL服务。
我们在被测服务器上安装了Microsoft SQL 2005，按照测试要求建立了数据库。BF在测试之前会在数据库中生成9个表，其中包括4个500万行的表格，每行包括100字节的数据，因此每个表格容量大约是476MB，整个数据库容量为1.86GB。我们用60个客户端模拟了总共1600个用户，在这个数据库中进行查询、添加、删除、修改等操作。在测试期间，数据的吞吐量很小，因此网络吞吐量不会成为瓶颈。
这里可以看出，我们的配置使用了AWE功能之后，数据库在中等用户数量下的性能得到了较大的提升，幅度可以达到25%左右，而在大量用户数量下，使用AWE功能会导致性能下降10~20%左右。
IT168评测中心观点:测试结果看上去有些奇怪，不过分析之下应该可以理解。我们的测试机器只具有4GB内存（和2~4GB虚拟内存），在中等用户数量条件下，AWE功能让数据库突破了2GB的限制，从而可以达到3GB左右，因此吞吐量得到了提升。而在重负荷的情况下，系统内存已经耗尽（操作系统、文件系统缓存本身也要占用一定的内存），因此AWE锁定内存页面反而降低了可以用于分页的内存，因此性能会有降低。从这点来看，3GB~4GB的重负荷数据库服务器使用AWE的必要性不是很大。
然而再往上就不同了，AWE可以让系统内存得到充分的利用，而现下内存价格已经不是特别贵了，大内存的服务器也变得较为常见，因此我们建议使用SQL数据库的时候尽量开启AWE功能。
| DELL 2950测试平台 |
|
| 主板 | DELL |
| 处理器 | Xeon E5430 x 2 |
| 主频 | 2.66GHz |
| FSB | 1333MHz |
| L1容量 | 64K(Data容量为32K) |
| L2容量 | 12MB（共享） |
| 芯片组 | Intel 5000X |
| 内存 | 1GB FBD DDR2 667 SDRAM x 4 |
| 磁盘控制器 | LSI Logic MegaRAID SAS 8408ELP |
| 硬盘 | Seagate Cheetah 146GB 15K.5 SAS x 3 |
| 硬盘设置 | RAID 5，条带大小64KB，适应性预读，Cached IO |
| Windows硬盘设置 | 主系统分区30GB，次分区50GB，NTFS格式 |
| 操作系统 | VMware ESX Server 3.5.0 64607
Windows Server 2003 R2 EnterpriseEdition SP2 with IIS 6.0 Microsoft SQL2005 Enterprise Edition |
| 网卡 | Broadcom BCM5708C千兆网卡 X 1 |
我们采用了评测中心的一台DELL 2950服务器，配置了双路Intel 45nm Xeon E5430处理器，频率为2.66GHz，并能支持SSE4.1指令集。服务器还使用了Intel 5000X芯片组，提供24MB的Snoop Filter缓存，这可以提升高负荷时的内存/处理器性能。磁盘系统则是3块15000RPM的Cheetah 15K.5，并通过一块PCIe x8的LSI MegaRAID SAS 8708ELP来组建RAID 5阵列。
为了使用AWE，应用程序必须：
1. 使用Win32的AllocateUserPhisycalPages API函数分配扩展物理内存。该函数需要调用者具有将内存页锁定的权限。
2. 使用VirtualAlloc API函数在进程的地址空间中创建一个区域，作为与扩展物理内存进行映射的一个窗口。
3. 使用MapUserPhysicalPages或者MapUserPhysicalPagesScatter API函数，将扩展物理内存映射到这个虚拟内存窗口中。
在数据库使用AWE功能之前，必须对操作系统和SQL数据库分别进行设置。
内存锁定页面
首先应用程序要满足第一条要求，它必须能具备内存锁定页面功能，这需要在组策略中进行设置，如图所示启用SQL程序运行帐号的内存锁定页面功能。通常基于安全性的考虑会给数据库一个独立的运行帐号，这时就需要将其添加入内存锁定页面选项页。一些其他需要AWE功能的程序，也需要这样设置。
SQL2005的AWE设置很方便
随后要进入SQL2005的管理界面，将AWE选项打开。和SQL2000必须通过控制台命令打开不同，SQL2005可以在图形界面下设置，很方便。设置完毕需要重新启动SQL服务。
我们在被测服务器上安装了Microsoft SQL 2005，按照测试要求建立了数据库。BF在测试之前会在数据库中生成9个表，其中包括4个500万行的表格，每行包括100字节的数据，因此每个表格容量大约是476MB，整个数据库容量为1.86GB。我们用60个客户端模拟了总共1600个用户，在这个数据库中进行查询、添加、删除、修改等操作。在测试期间，数据的吞吐量很小，因此网络吞吐量不会成为瓶颈。
这里可以看出，我们的配置使用了AWE功能之后，数据库在中等用户数量下的性能得到了较大的提升，幅度可以达到25%左右，而在大量用户数量下，使用AWE功能会导致性能下降10~20%左右。
IT168评测中心观点
测试结果看上去有些奇怪，不过分析之下应该可以理解。我们的测试机器只具有4GB内存（和2~4GB虚拟内存），在中等用户数量条件下，AWE功能让数据库突破了2GB的限制，从而可以达到3GB左右，因此吞吐量得到了提升。而在重负荷的情况下，系统内存已经耗尽（操作系统、文件系统缓存本身也要占用一定的内存），因此AWE锁定内存页面反而降低了可以用于分页的内存，因此性能会有降低。从这点来看，3GB~4GB的重负荷数据库服务器使用AWE的必要性不是很大。
然而再往上就不同了，AWE可以让系统内存得到充分的利用，而现下内存价格已经不是特别贵了，大内存的服务器也变得较为常见，因此我们建议使用SQL数据库的时候尽量开启AWE功能。