许多用户已经开始从 Red Hat Enterprise Linux 2.1 Advanced Server (RHAS2.1) 向 Red Hat Enterprise Linux 3 (RHEL3) 移植,或者正部署一些新的服务器到 RHEL3 上,并且有几个问题。一些大家熟知的特性要么行为发生了一些变化,要么命名或实施发生了变化。我将试着说明 RHAS2.1 的一些更常用的特性以及如何在 RHEL3 中使用它们。
在这篇技术说明中,我将重点讲述使用 Oracle VLM 选项来创建一个大的数据库 buffercache,以及如何使用 hugetlb。
新的内核命名
RHAS2.1 for ia32
2.4.9-e.25 — 单处理器内核
2.4.9-e.25-smp — 能够处理最高达 4GB 的物理内存的 SMP 内核
2.4.9-e.25 — 能够处理最高达 16GB 左右的物理内存的企业 SMP 内核
用户空间能够访问用户空间段的 3GB 左右;内核部分位于其余的 1GB 中(32 位系统上的 4GB 地址空间)。
默认的 SGA 最高可达 1.7GB (共享池和 buffercache)。通过使用 MAPPED_BASE 和将 Oracle 可执行程序与低位附加地址重新链接,有可能创建更大的、最高达 2.7GB 的 SGA。
RHEL3 for ia32
2.4.21-4.EL — 单处理器内核
2.4.21-4.ELsmp — 能够处理最高达 16 GB 的物理内存的 SMP 内核
2.4.21-4.ELhugemem — 能够处理超过 16 GB,最高达 64 GB 的 SMP 内核
与 hugemem 内核的另一个差异是内核和用户空间地址空间被分为 4GB/4GB,这意味着使用 hugemem 内核,用户空间程序可以访问其 4GB 的地址空间。
使用 smp 内核,默认的 SGA 大小与 RHAS2.1 中一样。不过,使用 hugemem 内核,可以创建一个最高达 3.6GB 的 SGA,且无需使用 VLM 选项。
bigpages 与 hugetlb
RHAS2.1 中一个典型的大型服务器部署将使用 bigpages 作为启动参数来预先分配一大块内存,以单独用于共享内存。这些页面拥有一个 2MB 或 4MB 的 TLB 入口,它减少了 TLB 丢失的数量,因此将性能提高了几个百分点。
在 RHAS2.1 中使用 bigpages 的另一个好处是它允许内核 VM 不用过多地担心这部分虚拟内存的记录。而且这些页面不是可分页或可交换的,因此可以保证 Oracle SGA 保留在主物理内存中。
Enterprise Linux 3 用一个称为 hugetlb 的特性取代了 bigpages,在 Linux kernel 2.6 中也有 hugetlb 的一个移植。hugetlb 的工作方式有一些不同。Hugetlb 的行为类似于 bigpages 的行为;页面由大的 TLB 入口支持,不可分页,并且是预先分配的,这意味着一旦您分配了 x 兆字节的 hugetlb 页面,就只能通过利用 SHM_HUGETLB 分配的 hugetlbfs 或 shm 来使用该数量的物理内存。
RHEL3 不再需要启动参数;它是可以动态调整的。在系统启动之后,您可以向 /proc/sys/vm/hugetlb_pool 回送一个值,或者您可以将您想要的值放在 /etc/sysctl.conf 中。这个值的单位是兆字节,它可以分配大约 2MB 的页面。您可以在 /proc/meminfo 中看到这些值:
Hugepages_Total:500
Hugepages_Free:500
Hugepagesize:2048k
不过注意,内核需要找到 2MB 的连续物理页面来分配 hugetlb 池。它尽力获取尽可能多的页面,但如果因存在二进制程序正在运行而使得存在大量的碎片,则池分配将可能失败。
想要分配共享内存的程序必须添加一个标记(SHM_HUGETLB)到 shmget() 标记。(Oracle Database 10g 将默认这么做;对于 Oracle9i Database,则需要一个补丁。)这种方式确保 Oracle 共享内存段将在这个池外分配。
VLM 选项
对于 RHEL3,要用 VLM 选项来创建一个非常大的 buffercache,有两个选项: