【IT168评测中心】在上一篇数据库文章中我们已经知道了AWE对使用32bit操作系统的大内存服务器来说是很有必要，它可以让32bit进程突破2GB可用寻址空间的限制，如SQL 2005这样的数据库应用可以轻易地从中获益。然而使用AWE需要程序在编程的时候就是用AWE API，这需要程序开发的时候就要考虑到AWE，除了AWE以外有没有方便的办法提升应用程序可用的内存量呢？答案是当然的，这就是使用64bit操作系统，我们下面的测试解答了相关的一系列问题，并给出了实际操作应该是什么样子的。

SQL Server 2005具有x86和x64两个版本

　　我们知道程序只能使用2GB内存的这个限制是32位操作系统架构引起的。传统意义上的32bit操作系统使用32bit的内存地址，这样寻址范围就已经被限制为4GB——4G也就是2的32次方，然而通常操作系统的设计上为了安全性的考虑，应用程序和内核所处的内存地址空间是互相独立的，也就是说，应用程序和内核各自能访问2GB的内存空间。虽然不同的操作系统实现具有不同的值，不过多数现在的操作系统在这一点上都很一致。

 
AWE可以让32位操作系统下的进程提供64GB的地址空间

　　要让应用程序突破2GB的限制，具有很多种方法，一种是使用近代Windows NT核心提供的一个变通的方案：4GB内存调整优化技术，可以让应用程序应用到3GB的内存，然而这对现下的高端数据库应用来说仍然是被水车薪，于是Microsoft还在自己的操作系统提供了一个比较重要的特性：AWE（Address Windowing Extension，地址窗口扩展） API集，这个API集的原理其实是基于这样的一个事实：所有的支持PAE的操作系统都有能让IA32处理器直接寻址64GB物理地址的API，回想前面的内容，物理地址是CPU处理的地址，而每个程序私有的2GB内存地址被称为虚地址范围。

　　然而使用AWE方式必须让应用程序使用AWE API进行编程，对于应用程序来说布局有普遍性，而且应用AWE需要运行操作系统的组策略管理器进行特别的设置，需要一定的技术知识。

　　有没有方便实用的方法呢？，有的，32位应用程序还具有一种方法可以突破2GB的限制，这就是运行于64bit操作系统下面，虽然这种方法最终可以访问到的内存并不多，只有4GB，然而在多数情况下也都够用了，而且它不需要操作系统和应用程序做任何改变，这是一个比4GB内存调整优化技术更方便的技术，唯一的麻烦只是重新安装操作系统。

　　数据库技术是作为数据处理的一门技术而发展起来的，所研究的问题就是如何科学地组织和存储数据，如何高效地获取和处理数据。在数据库中用数据模型来抽象、表示和处理现实世界中的数据。数据库即是模拟现实世界中某应用环境（一个企业、单位或部门）所涉及的数据的集合，它不仅要反映数据本身的内容，而且要反映数据之间的联系。大部分的服务器应用都同数据库有着密切的联系。

　　我们采用了一组60台客户端的千兆网络环境进行了数据库测试，由于客户端所有的资源都用来产生数据库操作，因此可以给服务器施加相当大的测试压力。

Benchmark Factory 运行报告

• Benchmarkfactory 4.6

　　我们选择了Benchmark Factory 4.6软件和Microsoft SQL2005 Enterprise来测试不同的硬件平台在数据库应用中的表现。

　　我们选择了BF内置的标准测试脚本AS3AP，这项测试可用于对于ANSI结构化查询语言（SQL）关系型数据库进行测试，它可用于测试DBMS（单用户微机数据库管理系统），也可用于测试高性能并行或者分布式数据库。关系性数据库就是用二维表格结构来表示实体及实体之间联系模型的数据库形式。

　　我们采用了评测中心的一台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阵列。

　　操作系统则选择了64bit的Windows Server 2003，并在其上安装了32bit的SQL 2005，起先我们认为64bit操作系统需要64bit的SQL，结果表明并不是这样。

　　我们在被测服务器上安装了Microsoft SQL 2005，按照测试要求建立了数据库。BF在测试之前会在数据库中生成9个表，其中包括4个500万行的表格，每行包括100字节的数据，因此每个表格容量大约是476MB，整个数据库容量为1.86GB。我们用60个客户端模拟了总共1600个用户，在这个数据库中进行查询、添加、删除、修改等操作。在测试期间，数据的吞吐量很小，因此网络吞吐量不会成为瓶颈。

Win32无AWE VS Win64

　　这里可以看出，我们的配置下，数据库在少用户数量下也具有一些提升，而中等用户数量下的性能得到了较大的提升，幅度可以达到25%左右，而在大量用户数量下，会导致性能下降10~20%左右。可以发现，这个结果和使用AWE测试的结果是很相似的。

Win32 AWE VS Win64

　　和AWE相比具有什么不同呢？同样的SQL版本和测试，使用64位操作系统让低用户数量下的性能得到了一点提升，而在中等用户数量的情况下具有的提升从坐标上看比32位操作系统+AWE的情况要“右”移一些，峰值TPS也高一些，数值上为3%（33000TPS vs 32000TPS）。

IT168评测中心观点

　　测试结果和使用AWE的曲线很想象，只是峰值TPS对应的用户数量比AWE情况要多一些，峰值处理能力也要高3%，不过在400~500用户数量下反而有所不及，这可能是64位系统下的32位应用经过了WOW64（Windows 32 on Windows 64）子系统的转换而导致的一些损失。

　　在64位操作系统上运行32位应用确实是一个可行的方案，特别是用户购买的微软Windows可以互相更换（32bit <->64bit）的情况下，虽然在SQL 2005上看不到这样做的必要性，然而在一些其他的应用上我们可以考虑这个简单、方便的策略。

64位Windows也可以让32位应用程序突破2GB进程内存限制