文/Sleepless

　　AMD凭借他们的64位Athlon 64/Opteron平台得到了微软的关照，微软保证为其x86-64体系推出新的操作系统。一段时间以前，AMD又获得了另一个胜利，Intel宣布采用AMD公司对x86体系的64位扩展。

　　未来的Xeon和Pentium 4处理器将搭载被激活的x86-64扩展，但是在结构上2款处理器将和现在可以买到的基于Pentium 4的Prescott处理器一样。Intel的IA-32e和IA-32(IA-3

51精彩无线大奖等你拿 张国荣风采依旧一周年 金犊奖玩创意最正点 AC-尼尔森互联网调查

2e是Intel用来对抗AMD64的产品)处理器在结构上的相似是一个值得注意的重要的一点。因为这意味着如果Opteron能够在32位模式战胜Xeon，也就能够在64位模式保持性能优势。我们假定Intel没有专门的硬件用来改进64位性能使其超过AMD提供的解决方案，因此我们为你们带来的32位下Xeon vs.Opteron的比较应该在今年晚些时候的64位环境下还是可靠的。

　　Intel已经开始走x86-64路线是一件非常好的事情，这就意味着不久我们就会看到软件支持，驱动，还有市场全面的接受。我们替AMD感谢Intel回归x86-64阵营，这是一件AMD值得骄傲的事情。但是，如果从商业角度考虑的话，就没有什么值得骄傲的了。Intel做出了正确的决定；如果他们不采用x86-64体系，就会失去市场份额，使那些需要64位x86解决方案的用户除了Opteron外没有别的选择。然而，Intel如果在自家的CPU中采用x86-64体系，AMD就不会得到什么好处了。

　　本次测试在最后的结论中更多地谈到即将出现的Intel的64位Xeon(Nocona和Potomac)处理器，但是让我们先开始现在的内容：AMD的Opteron和Intel的Xeon在真实环境中数据库服务能力的对比，Intel深深的管线架构能对付得了AMD为服务器专门设计的Opteron吗？

　　一个令人困惑的市场

　　IT经理们断言Xeon系列的路会很艰难；Intel的Xeon系列处理器的确没有太多的意义。事情一开始很简单，Intel仅仅是将双路处理器Xeons命名为Intel Xeon，将四路处理器Xeons命名为Xeon MP。常规的Xeon处理器只能用于2路系统，Xeon MP能够用于2路、4路和8路服务器。

　　我们将3种不同的Intel核心与AMD唯一的Opteron核心进行比较。让我们先来关注Intel的核心：Intel的Prestonia核心采用0.13微米制程，现在作为2路Xeon处理器的核心。最好、最新的基于Prestonia核心的Xeon运行在3.2GHz,拥有512KB的L2 Cache，还搭载了2MB的L3 Cache。这种Prestonia处理器听起来应该非常熟悉，因为它似乎基本上就是Xeon版本的Pentium 4 Extreme Edition(以下简称P4EE)。P4EE是Xeon MP的Pentium 4版本，运行在更高的时钟频率。实际上，Prestonia和P4EE唯一的不同(除了包装)是前者只支持533MHz的FSB。前端总线的带宽实际上是Intel遇到的一个非常严重的问题，这里我们只是先简短地提一下。

　　接下来，我们要说一下Intel基于采用0.13微米制程的Gallatin核心的Xeon MP处理器。P4EE是由Gallatin核心衍生出来的，Gallatin核心搭载了1MB,2MB(最新型有4MB)的L3 Cache。4MB和2MB版本的Galllatin核心都沿用了400MHz的FSB，这是Xeon MP唯一的致命弱点。4MB版本Gallatin的时钟频率可达3.0GHz。

　　AMD的Opteron则更加简单；Opteron的1xx，2xx，8xx系列分别可以用于1路，2路，4路+的配置。

　　FSB对性能的影响

　　我们已经婉转地提到FSB带宽是Intel多处理器体系结构最主要的局限性，现在我们在这里更深一步地专注于这个问题。Intel对外部北桥的依靠，最主要的不利因素有：一是，一旦增加超过2路以上的配置就需要解决复杂的技术问题；二是实现多重高速FSB界面是非常昂贵的。不幸的是，Intel的解决方案不是最好的；不管你是否运行1、2或者4路Xeon处理器，这些处理器都共享同一个与北桥相连的64位FSB。

　　下面的图表可以帮助说明这种瓶颈：

　　在使用400MHz FSB的4路Xeon MP系统的情况下，每一个处理器能够得到由北桥提供的最大为800 MB/s的带宽。如果你在400MHz FSB情况下试着运行一颗单独的Pentium 4 3.0GHz处理器，尽管处理器拥有全部3.2GB/s的FSB带宽的，但你会注意到明显的性能下降；现在如果把FSB带宽降到800MB/s，处理器性能会有非常大的损失。

　　正是由于这种限制，Intel必须依靠搭载更大的L3 Caches来掩盖FSB瓶颈；更多的信息可以储存在Xeon搭载的cache中，Xeon不必频繁地请求通过严重堵塞的FSB来发送数据。

　　更糟的是共享FSB问题随着CPU数量和时钟频率的增加越来越严重。一个2路Xeon系统不会受到像4路Xeon MP系统那样严重的FSB瓶颈的影响；并且运行在3.0GHz的4路Xeon MP系统比运行在2.0GHz的4路Xeon MP会受到更大的影响。这不是一个很好的状况，却没有什么方法能够绕开这个问题。但是，AMD的解决方案展现出更多吸引人的地方：

　　首先，请记住每个Opteron都搭载了自己的北桥和内存控制器，因此不需要与外部芯片组打交道。每一个Opteron CPU都有3个点对点的Hyper Transport链接，在每个方向传送数据的带宽是3.2GB/s(完整的双向带宽是6.4GB/s)。这种优势非常明显：在你按比例曾加Opteron服务器CPU的数量时，不必担心FSB瓶颈。

　　Intel可能能够为他们的Xeon MP处理器增加64位扩展，但是现在存在的性能瓶颈将会继续困扰Xeon系列产品，除非体系结构有重大变化。

　　超线程

　　Intel的超线程技术已经被桌面和企业市场广泛接受。我们以前的测试表明，超线程技术平均提升了3-5%的性能，因此我们在所有测试中都将打开它。

　　测试

　　我们为这次的比较准备了2套测试设备：一个我们网站论坛数据库的升级版本，还有另一个需要投入大量精力的测试——有代表性的企业级交互式数据库服务应用程序。我们在下面的文章中将会深入地讨论2种测试的细节，首先介绍一下我们测试的基本硬件配置：

　　AMD Opteron 848/248 and Intel Xeon/Xeon MP (Prestonia/Gallatin)，4GB DDR333 (NUMA was enabled for the Opteron)，8 x 36GB 15,000RPM Ultra320 SCSI drives in RAID-0，Windows Server 2003 Enterprise

　　我们测试和研究了各种参照方法，为的是能够得到公正，可重复的，最最真实情况下的数据库性能基准点。过去，我们使用过跟踪回溯的方法对数据库施加压力。虽然这种方法能够满足测试硬件这一目的，但也到了改变的时候了。这段时间以来，我们想要进行2种不同的测试：一种代表普通的数据库负载，像我们网站论坛的数据库；另一种代表了企业级的负载量。

　　构建一个数据库测试基准(普通负载)

　　我们的第一个测试基准是专门用.NET编写的，使用ADO.NET连接数据库。我们网站论坛的数据库被当作源数据库，在测试时的大小超过了14GB。我们为了方便讨论这种测试工具的功能，给它起了一个名字叫“SQL Loader”。

　　SQL Loader允许我们指定如下内容：为测试创建一个基于XML的工作负载文件，测试应该进行多长时间，允许使用多少线程来加重数据库的负担。XML工作负载文件包含了我们对数据库执行的查询和一些随机的ID生成器查询；使用ID来与我们的工作负载文件共同增加常驻内存中的数组。使用随机ID的目的是通过选取随机数据来尽量保持测试的客观性。这种测试给了我们很大的发展空间，因为这种工作负载能够用于我们将来想做的任何测试中。

　　工作负载范例：

　　测试情况：

　　测试使用的工作负载是基于论坛每天使用情况的，运行的是FuseTalk论坛。我们使用最常见的查询并把它们放入工作负载中。一些功能，比如阅读帖子和消息，获取用户的信息，发布帖子和消息，还有读取私人信息等，都是值得注意的。每一次重复的测试都要进行10分钟，而且每次都从冷启动开始。SQL在每次测试的间隔重启。

　　这个测试的重要意义在于它是一个你能遇到的真实环境；对于我们来说，测试中的表现直接影响了我们做出对现有IT基本设施进行升级的决定。