[轉]32位Linux設定超大Oracle SGA的分析

最近看到手上有一臺資料庫（rac中的一個節點），是32位RHEL，但是記憶體有8G，然後研究了一下，發現用了hugemem核心，故搜尋了一些資料，轉載之~

其他轉載的：Hugemem Kernel Explained

有不少使用者認為在32位Linux，只能設定約1.7GB的Oracle SGA。也有不少使用者在不同的Linux發行版中使用相同的配置過程，獲得了不同的SGA最大值，便認為某些Linux發行版存在問題。這些想法都比較片面。實際上 32位Linux上Oracle SGA 的容量取決於三個指標，即：Linux kernel 版本、Oracle Database 版本、Linux 核心引數shmmax。這裡跟據一些網上文章做了些查正，做一些分析吧。

一、核心版本的影響

在32位Linux平臺，至少都有兩套核心供使用者使用。一個是smp核心，一個是hugemem核心。兩個核心的區別在於直接對映的核心資料程式碼地址空間的區別：

SMP 核心：

在x86架構下，虛擬地址空間的大小為4G。在這4G空間中，使用者空間佔3G (0×00000000到0xbfffffff)，核心空間佔1G(0xc0000000到0xffffffff)。這樣的分配策略稱為3G/1G分配。

具體的分配方式如下：

1. 0GB-1GB User space - Used for text/code and brk/sbrk allocations (malloc uses brk for small chunks)

2. 1GB-3GB User space - Used for shared libraries, shared memory, and stack; shared memory and malloc use mmap (malloc uses mmap for large chunks)

3. 3GB-4GB Kernel Space - Used for the kernel itself

這種分配方式對於擁有1G實體記憶體以下的系統是沒有任何問題的，即使超過1G實體記憶體，3G/1G分配策略也沒有什麼問題，因為核心可以在高階記憶體區域 (實體地址1G以上的記憶體)中存放一些核心資料結構(比如頁緩衝等)。

然而，隨著實體記憶體的增多，3G/1G分配策略的問題也逐漸會暴露出來。這是因為一些關鍵的核心資料結構 (比如用於管理實體記憶體的mem_map[]) 是存放在1G核心空間之內的。對於32G記憶體的系統，mem_map[]會佔用近 0.5G的低端記憶體(實體地址896M以下的記憶體)，這樣留給核心其他部分的記憶體就不到所有記憶體的1.5%;而對於64G記憶體的系統，mem_map[] 本身就會耗盡所有的低端記憶體，造成系統無法啟動。但是把mem_map[]放到高階記憶體的做法也不太實際，因為mem_map[]和記憶體管理，體系結構相關底層實現，檔案系統以及驅動等幾乎所有的核心的關鍵部分均有聯絡，這時候就需要使用hugemem核心了。

hugemem 核心：

與SMP的3G/1G策略不同，hugemem 使用4G/4G分配方式。可以使核心空間由1G增加到4G，而使用者空間也由3G增加到4G。

相比3G/1G分配策略，對於4G實體記憶體系統，使用4G/4G分配可以增加低端記憶體達3倍以上，而對於32G實體記憶體系統，則會有更多的提升，達到原來的6倍。 理論上，4G/4G策略可以支援實體記憶體達200G的x86系統(如果硬體沒有限制的話)，即使對於這樣的系統，4G/4G策略也能保證留有1G可用的低端記憶體。

不論能否理解上面的解釋，只須要記住 smp 和 hugemem 兩個核心，一個是 3G/1G策略，一個是4G/4G策略即可。

二、Oracle Database 版本：

Oracle SGA 是掛載在記憶體使用者空間中，不同版本的 Oracle Database ，掛載SGA起始地址是不同的：

Oracle 10g Release 1:掛載SGA的起始地址為0×50000000(1.25GB)

Oracle 10g Release 2:掛載SGA的起始地址為0×20000000(0.5GB)

(其它版本未查正，有興趣可以自已看看Oracle手冊)

從這個結果可以看出，理論上若使用3G/1G的smp核心，Oracle 10g Release 1 的SGA可設定到 3GB - 1.25 = 1.75GB 。正是因此，也有人認為Oracle SGA 只能設定到 1.75GB。而升級至 R2 版本，則可以設定到 3GB - 0.5GB = 2.5GB 。相同的，使用 4G/4G 的hugemem 核心能夠獲得多大的SGA 就很清楚了。

三、kernel shmmax 引數：

shmmax定義單個共享記憶體段的最大值，它的取值範圍區間是[0,4294967295], 單位為byte，4294967295 bytes即4294967296 bytes(4GB)減去1。一般來說，它應該足夠大以容下整個SGA，避免SGA使用多個共享記憶體段造成Oracle效能下降。

那麼，將shmmax設定為最大值4294967295，使用 hugmemem 核心，Oracle 10g R2 版本，則理論上的SGA最大值為 3.5GB。

儘管使用者程式可用的虛擬地址空間為4GB以及shmmax的最大值為4294967295，仍然可以透過使用記憶體檔案系統(in-memory filesystem，比如tmpfs、ramfs以及hugetlbfs)開啟Oracle的Very Large Memory (VLM)特性來擴充套件SGA超過4GB，比如6GB。但是這種方法有個不方便的地方是，使用者不能夠再使用Oracle 10g中的Automatic Shared Memory Management了。

總結一下：

SMP核心和hugemem核心的影響：

SMP核心：1GB+3GB，SGA最大值為1.75GB(3GB-1.25GB)

Hugemem核心：4GB+4GB ， SGA最大值為2.75GB(4GB-1.25GB)

Oracle 不同版本的影響：

Oracle 10g Release 1:掛載SGA的起始地址為0×50000000(1.25GB)

Oracle 10g Release 2:掛載SGA的起始地址為0×20000000(0.5GB)

那麼：

Hugemem 核心 + Oracle 10g Release 2 ，SGA最大值為3.5GB(4GB-0.5GB)

BTW：由於64位系統對應16EB定址範圍，而不是32位系統的4GB，所以想要獲得更大SGA，效能更好的效果，應該優先使用 64 位系統，而不是透過32系統配合記憶體檔案系統來配置了。