許多用戶已經開始從 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，有兩個選項：
