图 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 启用内存窗的更多信息,请参阅 。
| 共12页: 上一页 [1] [2] [3] [4] [5] [6] [7] 8 [9] [10] [11] [12] 下一页 | ||
|