了解 IBM® DB2® 9 for Linux®、UNIX® 和 Windows® (DB2) 如何利用多页面大小（multiple page size）。随着 POWER5+™ 处理器架构的引入，IBM AIX 5L™ 操作系统增加了对新的 64 KB 页面的支持，这种页面与当前默认的 4 KB 页面具有类似的性质。此外，AIX 5L Version 5.3 TL04 还为这种硬件架构引入了一种新的 16 GB 巨型页面特性。DB2 9 自动利用 64 KB 页面为该平台上的数据库应用程序提供高性能。此外，DB2 还支持对 16 GB 巨型页面的使用。
简介
由于各种各样的原因，大多数现代操作系统都是在虚拟地址空间中运行程序的。虚拟地址有很多优点，包括灵活性、独立性、可移植性以及比物理内存更多的寻址空间，此外在一定程度上还允许底层硬件配置的独立性。
然而，在虚拟地址空间中运行程序也会带来相应的成本。程序（包括 DB2）引用的内存地址是虚拟地址。每次为程序指令或数据处理内存位置时，都需要将虚拟地址转换成物理（或实际）内存地址。这种转换是由一个页表来维护的，这个过程增加了程序的执行时间。页表的大小与页面大小成反比，这意味着页面大小越小，页表就越大，开销也就越大。
多年来，4 KB 一直都是大多数操作系统，包括 AIX 5L 操作环境的标准页面大小。最近，随着数据量和处理器可寻址内存的增加，4 KB 的页面大小的效率变得有些低下了。为了提高处理大量数据的应用程序的性能，基于 IBM POWER5+ 处理器且运行 AIX 5L V5.3 TL04（或更高版本）的系统引入了多页面大小支持。从 AIX 5L V5.1 开始，POWER™ 处理器和 AIX 5L 操作系统支持两种页面大小（4 KB 和 16 MB）。除了这两种页面大小外，最新可用的页面大小有 64 KB 和 16 GB。64 KB 的页面与 4 KB 在行为上是相同的。（也就是说，这些页面内存不是固定的，可以对它们进行分页。）
为了利用最新可用的页面大小，DB2 9 自动检测系统中可用的页面大小。如果 64KB 页面大小可用，那么 DB2 会将一些进程和所有共享内存区域的默认大小设置为 64 KB。从 IBM DB2 Universal Database ™ (UDB) V8.2.5 开始，DB2 还增加了对 16 GB 页面的支持。
背景知识
让我们看看进程运行时环境，了解清楚为什么大型页面对诸如 DB2 之类的企业应用程序有如此高的价值。
进程运行时环境
在运行任何程序之前，操作系统装载器必须将它装载到实际内存中。在 AIX 5L 环境中，用于运行进程的内存被分成各种不同的内存区域。用于进程的私有区域有：text、stack 和 data/heap，每个区域专用于某个特定的用途：
text 区域存储进程的指令。
data/heap 区域包含动态分配的内存和可全局访问的程序数据（例如 DB2 代理私有内存）。
stack 区域用于子程序返回地址，也用于存储自动数据。
另外还有一个非私有区域，称为共享内存，这是 DB2 和其他多进程应用程序广泛采用的进程间通信机制。DB2 使用共享的内存区域来有效地在相互协作的 DB2 进程（如 DB2 代理）之间处理和共享数据（主要用于缓冲池）。DB2 还将共享内存用于各种其他的堆。
如前所述，进程所引用的内存地址是虚拟地址，需要将其转换成物理地址。对于每个正在运行的进程，虚拟地址与物理地址之间的映射是在一个称作页表的数据结构中维护的。页表的数量与虚拟地址空间的大小成比例。因此，页表的大小就很重要。为了加快地址转换，架构中有一个 processor-on-a-chip (PoC) 缓存和相关的转换后备缓冲器 (TLB) 逻辑。TLB 是一个较小的缓存区域，用于存储最近的地址转换，以便再次使用。
大型页面的优点
除了处理器时钟速度外，另一个重要的处理器性能度量是每条指令的时钟周期（CPI）。实际上，CPI 是对运行一条指令需要多少时间的度量。通常意义下的 CPI 是指平均或规格化的 CPI。CPI 越低，则执行越快，性能也就越好。
TLB 缓存条目重用（缓存命中）意味着更快的地址转换，还意味着对物理内存的更快的访问。如果 TLB 没有命中，那么就需要访问存储在主存中的页表，而这样做需要消耗相当多的处理器周期。增加进程的地址空间（也就是说，从 32 位地址空间增大到 64 位地址空间）这种做法已经变得越来越普遍了，但是这样会增加页表的大小，从而降低地址转换的速度。
为解决这个问题，有两种选择。一种选择是增加 TLB 大小。然而，由于芯片空间的限制，TLB 的大小不能成比例地增加。另一种选择是通过减少页表中的条目来减少页表的大小。前面已经指出，页表的大小与页面大小是成反比的，这意味着增加页面大小可以使页表变得更小，而且，每个 TLB 条目可以满足更多的地址转换。（也就是说，页面越宽，每个页面存储的信息也就越多。）
POWER5+ 处理器架构（运行 AIX 5L 操作系统）通过引入多页面大小来解决页表问题。一个应用程序可以选择与其工作负载的大小和特性相符的页面大小。在本文的后面您将看到，这种思想可以产生相当大的性能优势。
AIX 5L 多页面大小支持
这一节对 AIX 5L 的多页面大小支持作一个简要的概述。在简介部分已提到，POWER5+ 处理器和 AIX 5L V5.3（具有 5300-04 建议的技术级别）引入了对两种新的虚拟内存页面大小的支持：64 KB 和 16 GB。16 GB 的页面仅用于性能非常高的环境，而 64 KB 的页面则是为通用目的而设计的。实际上，对于大多数工作负载，使用 64 KB 的页面比使用 4 KB 的页面更好。我们将在本文的后面讨论对 DB2 使用 64 KB 的页面所带来的性能优点。分配 16 GB 的页面则需要 IBM Hardware Management Console (HMC) Version 5 Release 2 机器代码。
当在基于 POWER5+ 处理器的系统上运行 5300-04 技术级别的 64 位 AIX 5L 内核时，对 64 KB 页面大小的支持是自动启用的，不需要进行系统配置或调优。
注意，64 KB 页面完全可以进行分页，并且 64 KB 页帧的池的大小是动态的。AIX 5L 操作系统管理池的大小，并根据不同页面大小的需要改变 4 KB 和 64 KB 页帧的数量。然而，16 MB 页面大小需要使用 vmo 命令对 AIX 5L 进行配置。请参阅本文 参考资料 部分，以获得关于 AIX 对多页面大小支持的更多信息。
可以使用 AIX 5L svmon 和 vmstat 命令来监视系统上 4 KB 和 64 KB 页帧的数量。例如，要显示关于每种页面大小的 DB2 进程统计信息，可以使用 -P 标志、 DB2 进程 ID (PID) 和 svmon 命令：
|
DB2 多页面大小支持的启用
从 DB2 9 开始，DB2 自动为选择的内存区域检测和使用 64 KB 页面大小。在此版本之前，DB2 默认情况下都是使用 4 KB 的页面大小，同时在支持 16 MB 页面的系统上提供了自定义配置 16 MB 页面的能力。POWER5+ 架构和 DB2 UDB V8.2.5 还引入了 16 GB 大型页面的自定义配置。
对于 DB2，系统主存的最大消耗者是它的缓冲池，这个缓冲池基本上是一个单独的、较大的共享内存区域。DB2 支持缓冲池共享内存区域使用底层系统上可用的所有页面大小（4 KB、64 KB、16 MB 和 16 GB）。DB2 9 自动检测 AIX 5L 操作系统和 POWER5 硬件是否支持 64 KB 页面，如果支持，则允许所有 DB2 共享内存区域（包括缓冲池、锁列表、日志缓冲区、实用程序堆、包缓存、监视器堆和共享排序堆）使用 64 KB 的页面大小。本文的 性能 一节将详细论述使用受支持的不同 AIX 页面大小为 DB2 事务性工作负载带来的性能提升。
除了共享内存外，DB2 还允许为代理私有内存自定义配置 16 MB 的页面。代理私有内存的常见消费者是排序堆内存，代理在查询执行期间使用这部分内存来对记录行进行排序。然而，DB2 目前不会自动为代理私有内存启用 64 KB 的页面大小，也不允许为代理私有内存自定义配置 16 GB 的页面大小。
虽然 AIX 5L 操作系统和 DB2 支持这些不同的页面大小，但是配置 16 MB 或 16 GB 页面时需要定制的硬件、AIX 5L 和 DB2 配置。要让 DB2 选择预先配置的 16 MB 或 16 GB 页面，可以使用 DB2_LARGE_PAGE_MEM=DB 或 DB2_LARGE_PAGE_MEM=DB:16GB 注册表变量。请参考当前的 DB2 和 AIX 5L 文档，了解关于通过配置硬件和 AIX 5L 操作系统来使之支持 16 MB 或 16 GB 页面的说明。
16 MB 和 16 GB 页面大小都要求小心地调整分配给这些不同页面大小的 AIX 内存池的内存大小。这时要特别小心，因为如果配置不当，则可能导致 4 KB 或 64 KB 页面大小的池过度分页。当分配 16 MB 和 16 GB 的页面时，它们就在内存中扎下根来，AIX 5L 操作系统不能动态地移动较大页面大小（16 MB 或 16 GB）的池与较小页面大小（4 KB 或 64 KB）的池之间的页面。然而，如果为 16 GB 或 16 MB 的池分配了足够的内存，那么工作负载就可以在性能方面受益。
随着 64 KB 页面的引入，运行在基于 POWER5+ 处理器硬件和 5300-04 技术级别上的 AIX 5L 操作系统上的 DB2 应用程序可以自动利用更大的页面大小所带来的性能优点，而不会导致任何用户或管理开销。这里完全没有必要将 64 KB 页面固定在内存中，AIX 5L 操作系统可以动态地移动 4 KB 和 64 KB 页面大小的池之间的页面。
除了所有 DB2 共享内存区域外，DB2 9 还为它的进程栈自动使用 64 KB 页面，从而进一步提高性能，同时又不带来任何资源开销。
性能
本文之前的几个小节主要讨论较大页面大小在性能方面的关键优点，以及它们在 DB2 中的使用。在这一节中，您将了解到使用内部在线事务处理（OLTP）工作负载时的性能结果（用 DB2 9 进行评测）。
我们所描述的性能结果是从两组系统上收集的：
一个是 IBM System p5? 570 Model 9117-570，使用频率为 2.2 GHz 的 16 POWER5+ 处理器和 512 GB RAM
其中创建了 8 TB 的数据库。
为 DB2 缓冲池分配了 473 GB 内存（从 512 GB 的 RAM 中分配）。
一个是 IBM System p5 520 Express Model 9131-52A，使用频率为 1.9 GHz 的两个 POWER5+ 处理器和 32 GB RAM
其中创建了一个 25 GB 的数据库。
为 DB2 缓冲池分配了 18 GB 内存（从 32 GB 的 RAM 中分配）。
图 1 展示了相对的性能提高，它们是在 4 KB 页面大小与 DB2 和 the AIX 5L 操作系统所支持的不同页面大小之间进行规格化之后得到的。这些度量是在一个 16 路 p5-570 上测得的。当使用 64 KB 页面大小时，与使用 4 KB 页面大小相比，在性能上提高了 13%。此外，当从 64 KB 变为 16 MB 的页面时，性能提高了 8%。最后，当从 16 MB 的页面变为 16 GB 的页面时，性能又提高了 3%。DB2 吞吐率性能是以每分钟的事务数量来度量的。
图 1. 4 KB 页面与其他受支持的页面大小之间的性能提升
图 2 将图 1 看到的性能提升与减少的 CPI 和相应减少的 TLB 失误率关联起来。CPI 值越高，则运行指令所需的周期就越多，这意味着程序的运行性能未达到最优。TLB 失误的开销是整个 CPI 度量中的一个重要部分。提高 TLB 命中率可以提高 CPI 度量，从而也提高程序的性能。
如图 2 所示，使用 64 KB 页面时，DB2 工作负载的 CPI 度量提高了 11%。与使用 4 KB 的页面相比，TLB 失误率减少了 13%，导致工作负载的整体性能提高 13%。当使用 16 MB 和 16 GB 页面时，TLB 命中率进一步提高，导致 CPI 成比例增长，从而取得了更高的总体吞吐率。
图 2. 4 KB 与其他受支持的页面大小之间的 CPI 与 TLB 性能比较
过图 1 和图 2 很容易推断，使用 64 KB 的页面大小可以明显提高 DB2 应用程序的性能。然而用户需要认识到，工作负载在性能上的提高是不确定的，它取决于数据库的大小、可用的系统 RAM 以及为 DB2 缓冲池分配的内存。为了演示使用 64 kB 页面大小在性能上提高的百分比，我们在采用 32 GB RAM 的 p5-520 上为相同的工作负载执行另外一组测试。在这组测试中，在可用的 32 GB RAM 中，只有 18 GB 被分配给 DB2 缓冲池。
图 3 展示了与在 p5-570（为 DB2 缓冲池使用 473 GB 内存）上的测试相比，在 p5-520 上获得的吞吐率所增加的百分比。与使用 4 KB 的页面相比，使用 64 KB 的页面可以使性能提高 5%。
图 3. 使用 32 GB RAM 与使用 512 GB RAM 的系统上在采用 64 KB 页面时在性能方面的提高
这两组测试得到的性能结果的不同是可以预测的，因为随着数据库和分配给 DB2 缓冲池的内存的增加，TLB 缓存上的压力也随之增加。
结束语
当在支持 64 KB 页面大小且采用最新的 AIX 5L V5.3 TL04 操作系统的系统上运行时，DB2 9 会自动检测和使用 64 KB 页面大小。这种较大的页面大小可以立杆见影地提高性能。但是性能上的提高量却是变化不定的（取决于工作负载，范围在 5% 与 13% 之间）。现在，在采用较大内存的系统上，通过有效地利用 TLB 缓存限制将虚拟地址转换为物理地址时所带来的开销，可以从硬件投资中获得更高的收益。此外，DB2 还允许自定义配置 16 MB 大型页面和 16 GB 巨型页面，如果需要更高的性能，还可以利用这一点。
Sunil Kamath 是 DB2 在线事务处理（OLTP）基准和解决方案开发部的技术经理。他从事 DB2 性能方面的工作已经有六年多的时间了，曾领导过很多成功的拥有世界记录的 TPC-C 和 SAP 基准。他的兴趣和职责还包括探索和利用有助于提高 DB2 性能的关键硬件、操作系统和编译器技术。您可以通过 sunil.kamath@ca.ibm.com 与他联系。
Punit Shah 的主要职责是使 IBM 中间件软件能够使用最新的 System p 技术。他一直从事企业应用开发和性能方面的工作，编写或者与他人合作编写了关于这个领域的一些文章。您可以通过 punit@us.ibm.com 与他联系。
