Guojian Cai, 软件开发人员, IBM
Terry Sych, 副主任工程师, Intel Corporation

2004 年 7 月

本文描述了，针对 TPC-H 基准测试公布，与在基于 Intel Itanium 2 处理器的平台上安装和配置 IBM DB2 Universal Database 相关的关键问题。

简介

注意：本文最初发表在 http://www.intel.com/cd/ids/developer/asmo-na/eng/76370.htm上。

TPC-H 是一个著名的决策支持数据库基准测试，强调的是数据库、平台和 I/O 性能。这一工作负载的最佳性能需要充分调整和优化硬件及软件系统。本文描述了针对领先的 100GB TPC-H 基准测试公布的数据库安装和配置。本文所包含的信息可用于优化本质上类似 TPC-H 基准测试的决策支持工作负载和数据仓库工作负载。

为本文提供基础的 TPC-H 基准测试使用布的环境是：安装有 IBM® DB2® Universal Database™（UDB）v8.1 数据库系统的 MAXDATA Platinum 9000-4R® 服务器，操作系统是 Microsoft Windows® Server 2003。该服务器是由四个带有 6MB 三级缓存，运行频率为 1.5GHz 的 Itanium® 2 处理器驱动的。

为这一工作负载而优化平台所面临的挑战存在于一系列系统和数据库配置决策及调优步骤之中。要对该工作负载进行划分，以便利用多个处理器和提高可伸缩性。还要通过仔细地将表空间映射到磁盘上来组织好磁盘子系统，从而获得最佳性能。

要将关键的数据库调优参数设置为最佳值，比如缓冲池页面大小、区段大小和 I/O 服务器数目。显示有磁盘带宽和处理器利用率的性能测量可证明取得了高水平的性能。

本文描述了整体系统配置，以及一些支持基准测试结果的技术。还描述了针对该工作负载的 DB2 配置，其中包括一些关键的数据库功能和调优建议。但是，本文既没有描述如何安装或运行 DB2，也没有介绍如何针对特定的工作负载进行一般的 DB2 调优。

基准测试结果

TPC-H 是一个由一套面向商业的即席（ad-hoc ）查询和并发数据修改组成的决策支持基准测试。该基准测试通过检查大量数据，执行复杂查询，以及回答商业问题来展示决策支持系统的性能。TPC-H 中的数据库查询要比典型的 OLTP 查询更加复杂。

TPC-H 性能测试包括两部分：能力（Power）测试和吞吐量（Throughput）测试。能力测试将以连续的次序执行一个数据库查询流。吞吐量测试将执行多条并发的数据库查询流，而每条查询流同样以连续的次序执行查询。

IBM、Intel 和 MAXDATA 进行了合作，在基于 Intel Itanium 2 处理器的平台上使用 IBM DB2 Universal Database，联合产生了 100GB TPC-H 基准测试结果。

下表给出了 TPC-H 基准测试结果的简要总结：

系统描述

系统平台是运行 Microsoft Windows Server 2003 企业版的 MAXDATA Platinum 9000-4R 服务器，并使用 IBM DB2 UDB V8.1。磁盘存储系统是 Eurologic SANbloc 光纤通道（Fiber Channel）网络存储系统，其特点是采用了先进的 2GB 光纤通道技术。

图 1 描述了该系统的物理配置。

图 1. 基准测试系统配置
系统配置" src="http://www-128.ibm.com/developerworks/cn/db2/library/techarticles/dm-0403cai/fig-1-526x400.jpg" width="526" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dw="http://www.ibm.com/developerworks/"/>

MAXDATA Platinum 9000-4R 企业服务器

MAXDATA Platinum 9000-4R 企业服务器是基准测试的平台。这个机架式系统具有四个运行频率为 1.5GHz 的 Intel Itanium 2 处理器，每个处理器都带有 6MB 的三级缓存，其芯片组为 Intel E8870 服务器芯片组。

此平台配置了 32GB 的内存，这是该服务器支持的最大内存容量（16 x 2GB DDR266 DIMM）。

Intel Itanium 2 处理器

基准测试平台中具有四个带有 6MB 三级缓存的 1.5GHz 的 Itanium 2 处理器。系统总线频率为 400 MHz，提供高达每秒 6.4GB 的总线带宽。该处理器基于 Intel® EPIC 架构，且非常适合像 DB2 这样的数据库应用程序。

Eurologic SANbloc 网络存储系统

Eurologic SANbloc FC2100 网络存储系统提供数据存储器。该系统具有八个光纤通道磁盘阵列，每个都带有 14 个 18.3GB 15,000 RPM 的光纤通道磁盘驱动器。该系统总共有 112 个磁盘驱动器可用于数据库。这八个磁盘阵列都封装在一个 Eurologic 19” 30U 的机架里。

磁盘存储系统通过四个 QLogic QLA2342 光纤通道适配器连接到主机系统上。每个适配器都有两个 FC 端口。而每个 FC 端口都分别连接八个 FC 磁盘阵列中的一个。

Microsoft Windows Server 2003 企业版（64 位）

因为 Microsoft Windows Server 2003 企业版是针对服务器工作负载而设计的，所以被选择作为该基准测试的操作系统。Microsoft Windows Server 2003 企业版具有 32 位和 64 位两个可用版本。本例中使用的是 64 位的版本。企业版最多支持八个处理器和 64GB 的 RAM。

DB2 UDB V8.1 企业服务器版（ESE）（64 位）

DB2 UDB 是一个对象-关系数据库服务器，为取得高性能和可伸缩性提供了坚实的基础。DB2 企业服务器版是使用 Windows 上的 Intel C ++ 编译器、针对 Intel Itanium 处理器而开发和优化的。该编译器帮助 DB2 在 Itanium 2 上取得了最佳性能。

Windows 上 64 位的 DB2 UDB V8.1 企业服务器版提供了与其 32 位同级产品相似的功能。64 位和 32 位版本之间的最大区别就是 64 位版本可以处理数量更多的数据。

在 32 位的 DB2 中，有两种基本方法可以克服 Windows 平台上 3GB 虚拟地址空间的硬限制。一种方法就是使用 Microsoft Windows Address Windowing Extension（AWE）。另一种方法就是通过将工作负载分割或划分成多个逻辑分区，然后在对称多处理机（SMP）机器的多个逻辑节点（MLN）上运行该数据库。在该场景下，每个逻辑节点被看作是一个单独的应用程序，而每个应用程序在理论上都可以获得达 3GB 的虚拟内存；因此，多个节点总共可以使用超过 4GB 的内存。

Itanium 体系结构提供的 64 位寻址去除了 32 位计算中内存寻址能力上的约束。利用 64 位的版本，DB2 自然也支持操作系统所支持的任何内存容量，而不需要使用前面所提到的 AWE 和 MLN 方法。但是，MLN 在 64 位的 DB2 计算模型中仍然是一个极其重要的概念，可用于解决其他的技术问题，本文稍后会对此加以讨论。

数据库配置

该小节将了解针对 TPC-H 工作负载的 DB2 的配置。TPC-H 基准测试性能最优化的第一步就是查看可伸缩性。

可伸缩性和逻辑节点

可伸缩性主要涉及计算资源和性能之间的关系。计算资源的有效组织和灵活性是在动态商业和科学环境中获得良好的可伸缩性的关键。在这些类型的环境中，数据量有较快的增长趋势，而计算资源也在频繁升级。数据库只有具有先进的功能，才能在这些极具挑战性的环境中取得可伸缩性。

DB2 实现了一个无共享（shared-nothing）的体系结构。无共享的体系结构允许将工作负载分为多个逻辑单元或分区，并给每个逻辑单元分配它自己的计算资源，如处理器、内存和磁盘。在操作数据库期间，这些逻辑单元都是为服务公共的操作目标同时、独立运行的。无共享的设计保证了不同逻辑单元之间的最少交互，且利用了并行计算。

无共享的体系结构不仅可以适用于多个物理节点或一个机器群集，还可以适用于带有多个处理器的单个机器或 SMP 机器。在此基准测试中，我们在四个 Itanium 2 处理器之间划分了 TPC-H 工作负载，以使每个处理器尽可能独立于系统中的其他处理器而独立工作。工作负载的划分涉及利用 DB2 的 MLN 功能给四个逻辑节点安装数据库实例。下列 DB2 命令为这个包含四个处理器的平台安装了一个包含四个 MLN 的数据库实例：

            db2icrt db2tpch /s:ese /u:<userid>,<password> /p:D:\db2inst
            db2ncrt /n:1 /u:<userid>,<password> /o:db2bench /i:db2tpch /p:1
            db2ncrt /n:2 /u:<userid>,<password>/o:db2bench /i:db2tpch /p:2
            db2ncrt /n:3 /u:<userid>,<password> /o:db2bench /i:db2tpch /p:3
            

在这些命令中， db2bench 是机器的主机名，而 db2tpch 是实例名。每个逻辑节点都分配了一个通信端口。节点 0 拥有默认的端口号 0；其他节点的端口则是用标志 /p 定义的。在创建了实例并且添加了其余的三个逻辑节点之后，通过下列命令行将四个物理处理器分别附属于或关联到特定的逻辑节点：

            db2set db2processors=0 -i db2tpch 0
            db2set db2processors=1 -i db2tpch 1
            db2set db2processors=2 -i db2tpch 2
            db2set db2processors=3 -i db2tpch 3
            

SMP 系统中处理器的数字 ID 通常是从 0 开始。本例中，处理器 0 将附属于逻辑节点 0，处理器 1 附属于节点 1，以此类推。

表空间设置

为获得最佳的数据库性能，正确定义表空间是至关重要的。

在该基准测试的设置中，有八个磁盘阵列，而每个都带有 14 个驱动器（或主轴），因而该系统中共有 112 个驱动器。磁盘将被均匀地分配给四个逻辑节点。因此，每个逻辑节点都会获得两个阵列或 28 个驱动器。逻辑节点及其专用磁盘将允许各个节点独立地操作。

在一个逻辑节点里，每个表空间的定义都跨越了两个阵列，使用了每个阵列中的 13 个驱动器，总共使用了 26 个 硬盘驱动器。每个阵列中剩下的一个驱动器被连接起来形成了一个镜像卷。该镜像卷是用 Windows 的磁盘管理工具定义的，并且专用于日志记录。

数据库中定义了五个常规的表空间和一个临时表空间。下表显示了所有表空间的详细信息：

除了 small_tables 之外，所有的表空间都是在同一组磁盘驱动器上定义的。这种方案是出于以下考虑而布置的：在 TPC-H 工作负载中，相当大一部分 I/O 操作都是连续的读取操作。当从一个表空间连续读取的任务比较重时，其他表空间的 I/O 操作却极其稀少，甚至是没有。

如果磁盘主轴在各个表空间之间进行了划分，那么当从一个表空间连续取数据时，就只有该表空间定义所在的那些驱动器会旋转；其他的只会偶尔旋转一下或保持闲置。这种磁盘方案有助于连续的读取。策略是将所有表空间的数据扩展到尽可能多的驱动器中，以最大化 IO 并行性。

除了 small_tables 之外，所有的表空间都被定义为 DMS（数据库管理的空间）表空间，而非 SMS（系统管理的空间）表空间。表空间的类型与 TPC-H 工作负载的连续 I/O 本质有关。通过 DMS 表空间，DB2 更加可以控制如何将数据页面物理映射到称作区段的磁盘空间分组中。

区段确定如何跨越多个容器进行数据分段，并确保一个容器里的数据页面是连续的。DMS 表空间通过连续的数据页面支持比 SMS 表空间要高效得多的操作，例如连续的表扫描。操作系统通过 SMS 决定一个页面所放置的物理位置，但不保证区段中的页面是连续的。

缓冲池的页面大小

另一个关键的性能调优措施就是控制缓冲池页面的大小。缓冲池是从磁盘读取或修改数据库页面时用于保存或缓存这些页面的内存区域。缓冲池通过允许从内存而非磁盘访问数据来提高数据库的性能。 DB2 支持 4KB、8KB、16KB 和 32KB 的缓冲池页面大小。在该基准测试中，为所有 DMS 表空间选择了一个 16KB 的中等页面大小。一般来说，较大的页面大小有益于连续的 I/O 活动，而较小的页面大小则更适合随机 I/O。

磁盘配置

磁盘上的数据组织是基准性能测试的一个重要因素。区段大小决定移到下一容器之前要写入容器的页面数。极其重要的是将数据水平分布在多个容器中，以便在进行大量连续的磁盘读取时，所有的磁盘主轴可以并行移动。为了取得这一磁盘并行性，选择合适的区段大小就十分关键。

实际上，I/O 性能受到多个因素的制约，例如硬盘驱动器的速度（以 RPM 单位进行测量）、外围总线（PCI 和 PCI-X）带宽、I/O 互连带宽，以及操作系统可以处理的单位 I/O 大小。PCI 总线吞吐量的能力决定了 I/O 的最大带宽。

单个硬盘驱动器的速度无论有多快，一旦通过控制器/接线盒附加到 PCI 总线上的驱动器数目达到某一点，该系统就无法再通过增加额外的驱动器来交付更大吞吐量。从所有 PCI 总线聚集的总带宽无论有多大，操作系统可以处理的数据量最终将决定一个应用程序可以完成多少 I/O。区段大小的计算反映了这些系统约束。

一般要考虑两种类型的磁盘子系统：RAID 和非 RAID。一般将非 RAID 的存储系统描述为 JBOD（简单磁盘捆绑）。

除了 RAID 级别 1 之外，所有的 RAID 级别都使用磁盘分段（disk striping）。在带有分段的 RAID 存储中，在计算区段大小之前，您必须在配置 RAID 阵列时决定分段大小。分段大小指的是在移到该阵列里的下一驱动器之前写入一个驱动器的数据总量。

通常将分段大小设置为 OS 可以处理的最大 I/O 单元的大小。如果大于该尺寸，一个分段单元就需要不止一次地发出 I/O，以便它可以在大型磁盘阵列中近似地并行化磁盘 I/O。如果分段大小小于最大 I/O 单元的大小，就可能浪费部分 I/O 能力，导致要花费更多时间来完成给定数目的 I/O。

一旦决定了分段大小，就可以通过以下公式计算相应的区段大小，这里假设其上定义了表空间的所有阵列都是以对称的方式来配置的：

区段大小 =数据驱动器数目 x 分段大小（KB）/缓冲池页面大小（KB）

每个 RAID 阵列的数据驱动器数目的确定可能相当复杂，因为一个阵列中的驱动器数目并不一定等于进行数据填充的驱动器数目。下表总结了最流行的 RAID 级别上数据驱动器的数目：

对于非 RAID（JBOD）的存储，您在设置区段大小之前必须确定的关键因素就是操作系统可以处理的最大的 I/O 大小。在该基准测试中，我们在 42 分钟的执行时间里，每 5 秒钟进行一次取样，测得每个 I/O 最大为 256KB。下表展示了关于 I/O 单元大小测量的更多细节：

可以使用以下公式计算 JBOD 存储的区段大小：

区段大小 =最大的 I/O 单元大小/缓冲池页面大小（KB）

使用该公式，可以在一个驱动器的一个 I/O 单元里读写一个区段。否则，可能存在某种低效性。

在该基准测试中，将存储器配置为 JBOD，将区段大小设置为 16 页（16 = 256K / 每页 16K）。

数据库 I/O 服务器

因为 TPC-H 工作负载中表扫描和表排序的数量较多，所以为获得最佳性能将数据从磁盘预取到内存是很重要的。在适合进行连续 I/O 以及确定预取可以提高性能时，DB2 将使用预取。

在 DB2 中，I/O 服务器是代表数据库工作线程执行预取 I/O 和异步 I/O 的线程或代理。可以将 I/O 服务器的数目配置为 DB2 中的参数。在该基准测试中，已经将每个节点 I/O 服务器的数目（NUM_IOSERVERS）设置为 14。四个节点一共具有 56 个 I/O 服务器。

预取大小

在进行预取时，预取大小是一个极其重要的可调参数。预取大小决定在发出预取请求时，从磁盘读取的页面数目，通常将之设置为多个区段大小。

由于它是可调的，所以您可以先将之设置为区段大小与一个逻辑节点上分配的容器数目的乘积，然后进行调整，直到获得最佳的连续 I/O。在该基准测试中，调优了预取大小，且最后被设置为 2,240（16 x 140）。

内存使用

DB2 主要在逻辑节点层次上针对缓冲池、排序堆以及其他使用来分配内存。缓冲池和排序堆应该使用大部分可用的物理内存（>90%）。在该基准测试中，给缓冲池和排序堆分别分配了 375,000 和 75,000 个页面。下表总结了进行能力（Power）运行时的内存使用：

在能力运行中，提交内存的最大值为 29,182,062,720 字节，约为 27.18GB，DB2 使用了其中的 27GB，或者说每个逻辑节点使用 6.8GB。这个数字证明了 64 位环境的优点。在 32 位系统中，每个逻辑节点只能使用 3GB。

性能测量

本小节展示了基准测试系统的不同的系统性能测量。

从能力运行到吞吐量运行的可伸缩性

查看数据库可伸缩性的一种方法就是让资源相对保持不变，增加该系统的工作负载，然后观察结果。

在该基准测试中，可以通过查看能力测试和吞吐量测试的执行时间来实现该方法。基准测试审计需要由五个查询流构成的吞吐量运行。还需要由单个查询流构成的能力运行。下表展示了从单条流的能力运行到五条流的吞吐量运行的可伸缩性。

能力运行的总时间为 2,738 秒，而吞吐量运行的时间为 13,068 秒。吞吐量运行的工作负载是能力运行的五倍，但它所花的时间仅仅是能力运行的 4.77 倍。该结果证明整个系统是可以伸缩的。

磁盘读取带宽

正如前面所提到的，磁盘读取性能是 TPC-H 基准性能测试中的关键因素。一种查看磁盘性能的方法是测量磁盘带宽或吞吐量。我们关注的是磁盘读取，而不是磁盘写，因为大部分磁盘访问都是为了进行读取操作，且大部分磁盘带宽也用于读取操作。

为了测量磁盘读取带宽，Microsoft System Monitor（PerfMon）* 用于每五秒钟进行一次取样，以获得磁盘每秒读取的字节数。图 2 展示了用于吞吐量测试的磁盘读取总带宽，以 MB/秒为单位：

图 2. 磁盘读取带宽

在整个吞吐量测试中，磁盘读取的平均总带宽为每秒 344MB。在吞吐量测试的几个点上，磁盘子系统的性能已经超过了每秒 1GB。从吞吐量测试的开始到 t=2,000 秒左右，磁盘读取的平均带宽明显超过了每秒 400MB。这一相当大的数据带宽需要高度调优数据库和平台。

磁盘读取 IOPS

为了检查每秒磁盘读取 I/O 操作（IOPS），Microsoft System Monitor（PerfMon）用于每五秒钟一次取样，以获得每秒的磁盘读取数。图 3 中显示了吞吐量测试中每秒总的磁盘读取数目：

图 3. 每秒磁盘读取数

磁盘每秒的平均读取数目约为 1,800。峰值约为每秒 8,600 次磁盘读取。磁盘每秒读取的数目正是预期数目，因为一次磁盘读取的平均大小约为 256KB。

处理器利用率

接下来，我们要将焦点从磁盘子系统转移到处理器上。这里，我们查看处理器的总体利用率。下面的图表展示了整个吞吐量测试中用户和内核时间的处理器利用率。我们可以从该图表清晰地看到，处理器以接近 100% 的利用率全力运转。处理器的高利用率表明该系统是完全平衡的，以及处理器在系统中是决定速度的因素，这是性能调整和优化的期望目标。此外，它还显示 I/O 子系统不是性能瓶颈。

图 4. 处理器利用率

结束语

本文描述了针对 TPC-H 基准测试公布，与在基于 Intel Itanium 2 处理器的平台上安装和配置 IBM DB2 Universal Database 相关的关键问题。为了提高可伸缩性，可以将工作负载分为多个逻辑分区，每个分区对应一个处理器。为确保优秀的磁盘性能，还需要慎重定义表空间。此外，还要考虑设置重要的数据库参数，比如缓冲池的页面大小、区段大小和预取大小来调节性能。

高性能、前沿产品以及简单调优意见和建议的正确结合可以带来优秀的数据库性能和可伸缩性。

参考资料

下列参考资料为本文中的材料提供了补充：

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• TPC-H 基准测试
  
  
• MAXDATA Platinum 9000-4R 企业服务器的 TPC-H 基准测试结果
  
  
• Intel Itanium 2 处理器
  
  
• IBM DB2 Universal Database
  
  
• 关于 DB2 UDB V8.1 ESE 与 Windows Server 2003 的更多信息，请查阅 IBM 红皮书 Scaling DB2 UDB on Windows Server 2003
  
  
• Microsoft Windows Server 2003 企业版
  
  
• MAXDATA Platinum 9000-4R
  
  
• Eurologic SANbloc FC2100 网络存储系统
  
  
• QLogic QLA2342 适配器
  

Intel 这个全球最大的芯片制造商还提供了一系列的增值产品，并为软件开发人员提供了信息：

• The Early Access Program 给软件供应商提供了 Intel 的最新技术，以帮助成员公司提高产品线和增加市场份额。
  
  
• Intel Developer Services 提供了免费的文章和培训，帮助软件开发人员最大化代码性能和最小化时间和工作。
  
  
• 在基于 Intel Itanium 2 的服务器上测试驱动器 IBM DB2 8.1： http://www.intel.com/cd/ids/developer/asmo-na/eng/strategy/affiliate/ibm/57296.htm。将您现在的 DB2 应用程序移到一个运行 Red Hat Enterprise Linux AS 2.1 的基于 Itanium 2 的平台不需要设置一台服务器。
  
  
• Intel Software Development Products 包括编译器、性能分析器、性能库和线程工具。