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

zecaro發表於2011-01-15

最近看到手上有一臺資料庫(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系統配合記憶體檔案系統來配置了。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23650854/viewspace-683893/,如需轉載,請註明出處,否則將追究法律責任。

相關文章