32 位 HP-UX 中的 DB2 内存配置

　　在 32-位 HP-UX 平台上，默认 HP-UX 内存管理是基于象限（quadrant）的，其中每个进程都有其自己的空间。每个进程（包括 DB2 代理）可以寻址最多 4GB 的内存。4G 的可寻址内存被拆分成 4 个象限，每个象限大小为 1G，如 图 11所示。

　　

　　图 11 - HU-UX 中的 DB2 32 位内存地址空间

 

　　象限 1 (1GB) 被预留给程序文本（可执行代码）。

　　象限 2 (1GB) 被预留给全局程序数据。

　　象限 1 和象限 2（减去内核内存和其他进程的内存）可一起用于私有内存。象限 1 和 2 存在了 n 次（每个进程一次）

　　象限 3 (1GB) 被预留给全局共享内存。

　　象限 4 (0.75GB) 被预留给全局共享内存。最后 0.25GB 用于 I/O 映射。

　　系统范围共享内存的限制是 1.75GB。也就是说，所有共享对象（不仅仅是 DB2）都被映射到象限 3 和 4 上由所有进程共享的一个单独的空间内。这个共享内存空间分为象限 3 中的 1GB 和象限 4 中的 0.75GB。但是，共享内存段不能跨象限“拆分”，而应该保证是一个连续的地址空间。根据进程的不同，DB2 分配各种不同的段。每个段只能映射到象限 3 或象限 4 中的某一个象限，但是不能同时映射到这两个象限。因此，DB2 允许分配的最大共享内存段在象限 3 中的大小为 1GB，在象限 4 中的大小为 0.75GB。实际上，很可能不会分配这么大的内存段，因为之前可能已经分配了一些小的内存段（或者是由 DB2 分配的，或者是由其他进程分配的）。这意味着数据库共享内存集实际上被限制在大约 0.75 到 1GB。这比其他 UNIX 平台上可用的任何数据库共享内存集要少得多。

　　注意： 缺省的 HP-UX 内存架构使用 SHARE_MAGIC 内核可执行程序。随着 HP-UX 10.20 内核的更改，可以通过编译应用程序使之使用 SHMEM_MAGIC 内核可执行程序，可以将全局共享内存的限制从 1.75G 增加到 2.75GB。不过，目前还没有计划使用 SHMEM_MAGIC 可执行程序编译 DB2 代码。

　　对于 HP-UX 11.0 或更新的版本，有一种方法可以以内存窗（Memory Windows）的形式绕过 1.75GB 的共享内存限制。内存窗允许每个进程从共享内存中定义最多 1GB 的惟一的全局空间。放在这个惟一空间内的共享内存段只能被相同内存窗中的进程访问。但是不同的应用程序或同一应用程序的不同实例可以放在不同的内存窗中，并消耗系统上更多的可用物理内存。

　　内存窗使象限 3 能够作为 /etc/services.window 中定义的一个进程组的私有共享内存空间。在内存窗的 DB2 实现中，每个实例都被映射到一个单独的内存窗。换句话说，每个 DB2 实例都可以有自己的象限 3 内存空间。象限 4 仍然用作全局共享内存区，其中任何共享进程都可以分配段。注意，如果象限 4 有可用的空间，那么共享库总是首先被映射到象限 4。于是，每个实例的可用共享内存就变为 1GB 加上象限 4 中仍然可用的空间。不过，共享内存段依然不能跨越象限边界。根据段的类型和大小，DB2 可以指定在象限 4 中创建段。数据库共享内存集仍然有大约 1GB 的限制。因此，内存窗的好处是允许我们为一个 DB2 实例分配整个象限（象限 3，大约 1GB）。然而，如果没有内存窗，则所有实例都必须共享最多 1.75GB 的系统范围的共享«内存。

　　提示： 如果为每个实例都创建一个数据库，就可以有效地为所有数据库分配最多 1GB 的数据库共享内存。

　　注意： 内存窗只是为 32 位应用程序扩展了系统范围的虚拟容量。通过扩展虚拟容量，可以使用更多的底层 RAM。在不使用内存窗的情况下，不管 RAM 有多大，最多只能消耗 1.75GB 的物理内存。

　　要了解有关如何为 DB2 启用内存窗的更多信息，请参阅 。

　　需要从这种结构中了解到的最重要的事情是：

• HP-UX 默认内存体系结构只允许所有进程（不仅仅是 DB2）共享最多 1.75GB 的共享内存。只有启用了内存窗，HP-UX 才能为每个实例分配共享内存。
• 共享内存段要求是连续的，因此不能跨越象限边界。这有效地将数据库共享内存集限制为 1GB。
• 内存窗可以用来为每个 DB2 实例提供一个有效的 1GB 私有数据库共享内存空间，再加上全局共享内存象限（象限 4）中的所有可用空间。
• 如果为每个实例都创建一个数据库，那么就可以为一个数据库分配最多 1GB 的空间作为共享内存。

　　32 位 HP-UX 上与分配数据库共享内存有关的常见问题

　　没有充分配置内核参数或者初始化数据库共享内存失败可能导致以下失败：

• 在数据库管理器启动时 - SQL1220N
• 在数据库启动时（激活数据库或第一次连接到数据库） - SQL1478W, SQL1084C, SQL3605C, hang condition
• 在运行时 - SQL2043N, hang condition

　　最常见的未能正确设置的内核参数是 shmmax。请参考 Quick Beginnings，以了解如何根据物理 RAM 设置适当的值。SHMMAX 按字节指定系统上可以分配的最大共享内存段。如果将 UDB 配置为创建一个大于该值的数据库共享内存集，则请求将遭到失败。

　　下面的例子展示了会导致问题的不正确的配置。

　　例 1

　　考虑如下配置： （所有页的大小都为 4K）

　　服务器：

• 服务器上的物理 RAM 1GB
• shmmax = 966 367 641 (1GB)
• shmseg = 32

　　数据库：

• IBMDEFAULTBP 100,000 页
• UTILHEAP 5000 页
• DBHEAP 10,000
• LOCKLIST 17,500 页
• PCKCACHE 5000 页
• CATALOGCACHE 2500 页

　　计算：
　　数据库共享内存 = (140,000 页 x 4KB/页) x 1.1% = ~616MB

　　问题： 可能仍然可以激活数据库或连接到数据库。但是，当尝试连接到数据库时，在 db2diag.log 中可能间歇地出现如下错误消息。
DIA3605C Memory allocation failure occurred.

　　注意，对数据库共享内存的计算表明，我们仍然没有超出 1GB 可用共享内存的限制。接下来我们看一看内核参数的设置。查看 "Quick Beginnings for DB2 Servers" 以获得对 32 位 HP-UX 平台上调优内核参数的建议。在查看这本书时，实际上您会发现其中没有写到 shmseg 参数。这意味着您应该使用默认设置。shmseg 的默认设置是 120。（由于 SHMSEG 内核参数被设得太低，有些共享内存段不能适当地分配。）

　　要解决这个问题，需适当地配置内核参数。

• 在这种情况下，设置 shmseg = 120

　　例 2

　　考虑如下配置： （所有页的大小都为 4K）

　　服务器：

• 服务器上的物理 RAM 1GB
• shmmax = 966 367 641 (1GB）
• shmseg = 120
• 服务器上的交换空间 500MB

　　数据库 A：

• IBMDEFAULTBP 100,000 页
• UTILHEAP 2500 页
• DBHEAP 10,000
• LOCKLIST 20,000 页
• PCKCACHE 5000 页
• CATALOGCACHE 2500 页

　　数据库 B：

• IBMDEFAULTBP 160,000 页
• UTILHEAP 7,500 页
• DBHEAP 20,000 页
• LOCKLIST 10,000 页
• PCKCACHE 5000 页
• CATALOGCACHE 2500 页

　　限制： 由于物理 RAM 只有 1GB，数据库共享内存集只能映射到它在物理上可以使用的空间，即 1GB + 交换空间。

　　计算：

• 数据库 A 共享内存 = (140,000 页 x 4KB/页) x 1.1% = ~616MB
• 数据库 B 共享内存 = (205,000 页 x 4KB/页) x 1.1% = ~902MB

　　问题： 分别激活或连接到数据库 A 或数据库 B 是可行的，但是不能并发进行。尝试同时激活这两个数据库将产生如下错误消息：
SQL1478W The defined buffer pools could not be started. Instead, one small buffer pool for each page size supported by DB2 has been started. SQLSTATE=01626

　　如果同时启动数据库 A 和数据库 B，需要至少 1.52GB (616MB + 902MB) 的共享内存。将数据库 A 映射到象限 4 （~0.75GB 可用共享内存）和将数据库 B 映射到象限 3 （~1GB）应该没有问题。但是，这一次，我们会受到物理内存的限制。显然，1GB 的 RAM 不足以处理 1.52GB 的共享内存映射。此外，SWAP 空间也被设置得太低。要解决这一问题：

• 尝试减少这两个数据库的缓冲池大小。或者
• 尝试将交换空间增加到物理 RAM 的两倍。或者
• 最好的解决方案是，增加更多的物理 RAM。在这种情况下，您将需要至少 2GB 的物理 RAM，才能同时启动这两个数据库。

　　例 3

　　考虑如下配置： （所有页的大小都为 4K）

　　服务器：

• 服务器上的物理 RAM 6GB
• Instance 1 （3 个数据库）

　　数据库 A：

• IBMDEFAULTBP 140,000 页
• UTILHEAP 7,500 页
• DBHEAP 20,000 页
• LOCKLIST 10,000 页
• PCKCACHE 5000 页
• CATALOGCACHE 2500 页
• APPGROUP_MEM_SZ 20,000 页

　　数据库 B：

• IBMDEFAULTBP 80,000 页
• UTILHEAP 2500 页
• DBHEAP 10,000 页
• LOCKLIST 20,000 页
• PCKCACHE 5000 页
• CATALOGCACHE 2500 页
• APPGROUP_MEM_SZ 20,000 页

　　数据库 C：

• IBMDEFAULTBP 130,000 页
• UTILHEAP 7,500 页
• DBHEAP 20,000 页
• LOCKLIST 10,000 页
• PCKCACHE 5000 页
• CATALOGCACHE 2500 页
• APPGROUP_MEM_SZ 20,000 页

　　限制： 由于物理 RAM 只有 1GB，数据库共享内存集只能映射到它在物理上可以使用的那些空间，即 1GB + 交换空间。

　　计算：

• 数据库 A 共享内存 = (185,000 页 x 4KB/页) x 1.1% = ~814MB
• 数据库 A 应用程序组内存 = 20,000 页 x 4KB/页 = 80MB
• 数据库 B 共享内存 = (120,000 页 x 4KB/页) x 1.1% = ~528MB
• 数据库 B 应用程序组内存 = 20,000 页 x 4KB/页 = 80MB
• 数据库 C 共享内存 = (175,000 页 x 4KB/页) x 1.1% = ~770MB
• 数据库 C 应用程序组内存 = 20,000 页 x 4KB/页 = 80MB
• 要启动数据库 A，要求： 816MB + 80MB = ~894MB
• 要启动数据库 B，要求： 530MB + 80MB = ~608MB
• 要启动数据库 C，要求： 772MB + 80MB = ~850MB

　　问题： 启动数据库 A 和数据库 B 成功。但是启动数据库 C 时失败，并返回如下错误：
SQL1478W The defined buffer pools could not be started. Instead, one small buffer pool for each page size supported by DB2 has been started. SQLSTATE=01626

　　在这里，物理内存不是问题，因为我们有足够多的 RAM（6GB）。进一步的测试得处了以下启动组合：

• 启动 A + B ->成功
• 启动 B + C ->成功
• 启动 A + C ->不成功
• 启动 (A + B) + C ->不成功
• 启动 (B + C) + A ->不成功

　　组合 (A + B) 和组合 (B + C) 获得成功，因为它们初始化数据库所需的共享内存总量分别是 1.5GB (894 + 608) 和 1.46GB (608+850)。这低于 1.75GB 的共享内存限制，并且每个数据库共享内存段可以安全地连续映射到一个象限。而其他组合将失败于 SQL1478W，因为它们要么超出了 1.75GB 共享内存限制，要么不能在一个象限内为一个数据库分配连续的共享内存段。

　　要解决这一问题：

• 实现内存窗。最好的解决方案是定义 3 个 DB2 实例。将一个数据库恢复到每个实例。并为每个实例创建一个内存窗。这样一来，每个实例都可以完全访问它自己的 1GB 内存窗共享内存空间。注意： max_mem_windows 内核参数必须设为 2 （实例数 -1）。

　　32-位 Linux/Intel 中的 DB2 内存配置

　　图 12中展示了 32 位 Linux/Intel 上的 4GB 可寻址内存。

　　图 12 - Linux/Intel 中的 DB2 32 位内存地址空间

 

　　从 0x08048000 到 0x0FFFFFFF 的段是预留给 db2sysc 可执行程序的。

　　从 0x10000000 到 0x3FFFFFFF 的段是实例共享内存，总共是 0.75GB。

　　在默认情况下，DB2 共享库始于 0x40000000。

　　在低地址装载共享库，而将更多的空间留给数据库共享内存，这是可行的。（这也意味着用于实例共享内存的空间将更少。但是由于实例内存与数据库内存相比通常比较小，因此这样可以获得好处。）例如，如果在低于 0x40000000 的地址装载共享库，那么就可以在 0x38000000 装载数据库共享内存。如果在低于 0x2a000000 的地址装载共享库，那么就可以在 0x30000000 装载数据库共享内存，这样就有超过 2GB 的空间留给数据库共享内存。这些更改要求重新编译内核，我们在本文中不会对此加以讨论。请参考 Linux 手册中内核重编译那一节，以了解更多信息。

　　不过，对于 Redhat Advanced Server 和 SuSE SLES 8 上的 v8.1 FP2，DB2 将尝试自动将共享库重新分配到一个较低的地址，这样就不需要重新编译内核。在这些企业发行版中，有一个叫做 /proc/ pid/mapped_base 的文件包含了一个地址，共享库将从该地址装载到内存。在默认情况下，该地址是 0x40000000，但是我们可以把它降低一些（降到 0x20000000）。当 db2sysc 启动时，我们检查 mapped_base 文件是否存在。如果存在，则使用新的值并重新执行。然后，mapped_base 值发生了改变的进程中产生的每个进程都使用这个新值。

　　数据库共享内存（包括缓冲池）始于 0x50000000 （默认值）。它从 0x50000000 开始朝着堆栈方向向下增长。堆栈包含要执行的指令。堆栈从 0xC0000000 开始向上增长。

　　使数据库共享内存和堆栈不发生冲突，这一点很重要。我建议为堆栈使用 16MB 这么大的空间。在这样的情况下，我们有 ~1.73GB 用于数据库共享内存（从 0x50000000 到 0xC0000000，减去 16MB 的堆栈）。

　　在使用 "ulimit -a" 或 "ulimit -s" 显示限制时，这些值是以 1K 字节为单位显示的。
Stack = 16384

　　设置这个限制，使堆栈和共享内存地址空间不会相互冲突，这一点很重要。如果它们之间有冲突，那么实例就会崩溃，并发出信号 4 或信号 11。

　　最后 1GB 的内存 被预留给 Linux 内核。

　　您可能已经注意到，没有用于代理私有内存的段。这就对了，在 32 位的 Linux/Intel 中，没有预留特定的段给私有内存。代理私有内存是从共享库之间的任意空闲空间中分配的。

　　为了看一看这里是如何使用内存的，请参阅叫作 /proc/ PID/maps 的文件，其中 PID 是 db2agent 进程的进程 ID。 图 12展示了 maps 文件的示例输出。

　　图 13 - db2sysc 进程的 maps 文件

 

　　从 图 13 中可以观察到下面一些情况：

• 从 0x10000000 开始的绿色的段是实例共享内存。
• 共享库从 0x40000000 开始装载。在共享库之间，橙色的段是代理私有内存。
• 绿色是数据库共享内存，始于 0x50000000。
• 最后一个紫色的段是堆栈。

　　需要从这种结构中了解到的最重要的事情是：

• 在默认情况下，数据库共享内存的大小是 1.75GB 减去堆栈大小。
• 将共享库装载到一个较低的地址，从而使留给实例共享内存的空间更少，留给数据库共享内存的空间更多。

　　32 位 Linux 中与分配数据库共享内存有关的常见问题

没有充分配置内核参数或者初始化数据库共享内存失败可能导致以下失败：

• 在数据库管理器启动时 - SQL1220N
• 在数据库启动时（激活数据库或第一次连接到数据库） - SQL1478W, SQL1084C, hang condition
• 在运行时 - SQL2043N, hang condition

　　最常见的未能正确设置的内核参数是 shmmax。请参考 Quick Beginnings ，了解如何根据物理 RAM 设置适当的值。 shmmax按字节指定了系统中可以分配的最大共享内存段。如果将 UDB 配置成创建大于这个值的数据库共享内存集，那么该请求将遭到失败。其他要指定的内核参数是 shmmni。下面的例子展示了会导致问题的不恰当配置。

　　例 1

　　服务器：

• 服务器上的物理 RAM 2GB
• kernel.shmmax = 32768(32KB)

　　数据库：

• IBMDEFAULTBP 200,000 页
• INTRA_PARALLEL ON
• UTILHEAP 17,500 页
• DBHEAP 10,000 页
• SHEAPTHRES_SHR 50,000 页
• LOCKLIST 1000 页
• PCKCACHE 5000 页
• CATALOGCACHE 2500 页
• APPGROUP_MEM_SZ 20,000 页（v8 中的默认值）

　　限制： SHMMAX 被设为 32KB。DB2START 可以分配足够多的共享内存来成功地启动实例。

　　计算：

• 数据库共享内存 = (286,000 页 x 4KB/页) x 1.1 = ~1.26GB
• 数据库应用程序组内存 = 20,000 页 x 4KB/页 = 80MB

　　问题： 在 db2start 期间，将碰到以下错误：
SQL1220N The database manager shared memory set cannot be allocated.

　　要解决这个问题，可以将 SHMMAX 参数增加到一个更合理的大小，例如 2GB。

　　例 2

　　服务器：

• DB2 v8.1.0.0
• OS: Linux SuSE SLES-8
• glibc version : 2.2.5
• Kernel: 2.4.19

　　问题： 如 SHMMAX 被设为 2GB，即 2147483648，那么一次 db2start 就会使其降至 268435456。如果将这个值减少 1 个字节，那么 db2start 不会作出任何变化。该问题在 v8 FP2, APAR LI70159中已得到修复。

　　对 SuSe 8.0 不会发生问题。

　　32 位 Windows 中的 DB2 内存配置

　　在 Windows 上，DB2 UDB 有着根本不同的体系结构。所有 DB2 操作都是以进程（db2sysc.exe）内的线程的形式实现的。Windows 进程模型最多可寻址 4GB 的内存，如 图 14中所示。

　　图 14 - Windows 中的 DB2 32-位内存地址空间

 

　　在 Windows 中没有真正的共享内存集的概念。在 UNIX 中，所有共享内存池通常都是某个内存集（例如缓冲池，dbheap，等等）的一部分，而在 Windows 中，这些共享内存池都是根据需要从 db2sysc 的私有内存集中分配的。

　　在非 Advanced Server Windows 环境（NT，2000 Pro/Standard）中，4GB 地址空间被分成 2GB 的用户空间和 2GB 的内核空间。这样可以有效地将 db2sysc 进程可访问的内存总数限制到 2GB。

　　在 Advanced Server 环境中，将 2GB/2GB 的内存拆分重新配置为 3GB 的用户空间和 1GB 的内核空间是可行的，如 图 14中所示。

　　为了允许内存使用量超出这些限制，必须在 boot.ini 文件中使用 /3GB switch。这里要警告的是，/3GB switch 只在 Windows 2000 Advanced Server、Windows 2000 DataCenter、Windows2003 Enterprise Edition 和 Windows 2003 DataCenter 中受支持。您可以在 Windows2000 Pro/Standard 中设置这个 switch，但是用户空间最多只能有 2GB，而内核空间缩小到 1GB，这会导致 1GB 的内存丢失。

　　注意： 为了有效地使用 /3GB switch，必须在 Windows 32 位环境中安装了最少 4GB 的物理 RAM。

　　为了克服 2GB （或 3GB）的用户空间限制，Windows 2000 Advanced Server 和 Windows 2003 Advanced Server 提供了对更大内存的支持。它们是 Address Windowing Extensions (AWE) 和 Physical Address Extension (PAE)。

　　AWE 是一种机制，用于通过一个可能更小的窗口访问内存中一个很大的部分。按照这种方法，如果某个大的内存池是线性的，那么它就可以被寻址。实际上，AWE 允许创建超过 2GB 限制的缓冲池。AWE 功能是通过使用 boot.ini 文件中的 /PAE switch 来实现的。/PAE 在 Windows2000 Pro/Standard 中有效，但如果不是使用 Windows 2000 Advanced Server、Windows 2000 DataCenter、Windows2003 Enterprise Edition 和 Windows 2003 DataCenter，则 Microsoft 不会允许你的操作系统与这样的 switch 一起运行。

　　需要从这种结构中了解到的最重要的事情是：

• 在 Windows 体系结构中没有真正的内存集概念。DB2 使用的所有内存（共享的或私有的）池都是从相同的内存段中分配的 - 这个内存段就是用户空间，在非 Advanced Servers 环境中限于 2GB。
• 在 Advanced Servers 中使用文件中的 /3GB switch 将这一限制增加到 3GB 是可行的。
• 通过使用 AWE 可以将缓冲池增加到超过 2GB 的限制。实际上，可以定义最大 64GB 的缓冲池。

　　结束语

　　DB2 的内存结构由 4 个内存集组成：实例共享内存、数据库共享内存、应用程序组共享内存（只有在数据库启用了 intra-parallel，或者启用了集中器，或者多分区的时候才适用）以及代理私有内存。每种内存集由各个内存池组成。例如，缓冲池和数据库堆是数据库内存集内的两个不同的内存池。

　　每个实例有一个实例共享内存集，由这个实例中的所有数据库共享。每个数据库有一个数据库共享内存集，由连接到该数据库的所有代理共享。每个应用程序组有一个应用程序组共享内存集，由属于该应用程序组的所有代理共享。每个代理（或进程）都有一个代理私有内存集。该内存集是由代理独占使用的。

　　对于 32 位内存结构，不管系统有多少物理 RAM，在任何平台上任何进程的可寻址内存都是 4GB。而且，这 4GB 中有一部分要预留给操作系统。剩下的所有内存（亦称用户空间）是由应用程序（包括 DB2）使用的。

　　在配置 DB2 内存的使用时应记住，所有内存池应该能够纳入可寻址用户空间。这个空间的大小随平台的不同而不同。表 1 列出了每种 DB2 内存集的限制。应用程序组共享内存集没有列出，因为它是从数据库共享内存集中分配的。

　　表 1 - 基于 32 位内存结构的 DB2 内存集限制

注意：
(0) 在多分区环境中，这些限制适用于每个分区。
(1) 当 DB2_MMAP_READ=NO 并且 DB2_MMAP_WRITE=NO 时，限制的最大值为 2GB。以下每种情况都会占用一个 256MB 的段，致使 1.25GB 的最小值出现：fenced 函数和过程；DB2_FORCE_FCM_BP=YES；启用了 intra-parallel/启用了集中器/多分区。
(2) Data （代理私有内存）和 Stack 之间共享 256MB 的段。在 ulimit 中将堆栈设为 16MB，便可以将 240MB 留给代理私有内存。
(3) 在 Solaris 中，实例共享内存可能非常大，因为共享内存段没有固定的地址。实例共享内存和数据库共享内存合起来大约是 3.7GB。
(4) 在 Solaris 中，代理私有内存与 db2sysc 可执行程序共享同一个 256MB 的段。这个可执行程序大约占 36MB。
(5) 在 HP-UX 中，所有共享内存都位于象限 3 （1GB）和象限 4 （0.75 GB）中。
(6) 象限 1 和 2（减去内核内存和其他进程内存）可以一起用作私有内存。
(7) 所有实例共享内存、数据库共享内存和代理私有内存都必须能纳入 2GB 的用户空间限制，或者在 Advanced Server 上使用了 boot.ini 文件中的 /3GB switch 之后 3GB 的限制。如果支持 AWE 则是 64GB。

　　对于 32 位内存结构，不管物理 RAM 有多大，实例、数据库配置都受到 4GB 可寻址空间的限制。不过，如果有足够的 RAM，只需每个实例或数据库都符合以上限制，就可以在系统中并发地运行多个实例或数据库。为了克服这一限制，应该考虑转换到 64 位的 DB2。