前言

PC Server發展到今天，在效能方面有著長足的進步。64位的CPU在數年前都已經進入到尋常的家用PC之中，更別說是更高階的PC Server；在Intel和AMD兩大處理器巨頭的努力下，x86 CPU在處理能力上不斷提升；同時隨著製造工藝的發展，在PC Server上能夠安裝的記憶體容量也越來越大，現在隨處可見數十G記憶體的PC Server。正是硬體的發展，使得PC Server的處理能力越來越強大，效能越來越高。而在穩定性方面，搭配PCServer和Linux作業系統，同樣能夠滿重要業務系統所需要的穩定性和可靠性。當然在成本方面，引用一位在行業軟體廠商的網友的話來說，“如果不用PC Server改用小型機，那我們賺什麼錢啊？”。不管從初期的購買，執行期的能耗和維護成本，PC Server都比相同處理能力的小型機便宜很多。正是在效能和成本這兩個重要因素的影響下，執行在PC Server上的資料庫越來越多。筆者所服務的一些客戶，甚至把高階的PCServer虛擬化成多臺機器，在每臺虛擬機器上跑一套Oracle資料庫，這些資料庫不乏承載著重要的生產系統。

毫無疑問，在PC Server上執行Oracle資料庫，最適合的作業系統無疑是Linux。作為與UNIX極為類似的作業系統，在穩定性、可靠性和效能方面有著與UNIX同樣優異的表現。但是Linux在記憶體分頁處理機制上與AIX、HP-UX等作業系統相比有一個明顯的缺陷，而這個缺陷在使用較大SGA的Oracle資料庫上體現尤為明顯，嚴重時對資料庫效能有著顯著的負面影響，甚至會導致資料庫完全停止響應。而本文就將從一個案例來詳述這種缺陷，並使用Linux下的大記憶體頁來解決這一問題。

一、案例的引入

客戶的一套系統，出現了嚴重的效能問題。在問題出現時，系統基本不可使用，應用上所有的業務操作完全失去響應。系統的資料庫是執行在RHEL 5.2 (Red Hat Enterprise Linux Server release 5 (Tikanga))下的Oracle 10.2.0.4 Oracle Database，CPU為4顆4核至強處理器（Intel(R)Xeon(R) CPU E7430 @ 2.13GHz），也就是邏輯CPU為16，記憶體32GB。故障期間，資料庫伺服器的CPU長期保持在100%。甚至將應用的所有Weblogic Server都關閉之後，資料庫伺服器的CPU利用率在數分鐘之內都一直是100%，然後逐漸下降，大約需要經過20分鐘才會下降到正常的空閒狀態，因為這個時候所有的應用都已經關閉，只有非常低的CPU利用率才是正常的狀態。據這套系統的資料庫維護人員反映，這種情況已經出現多次，就算是重啟資料庫之後，過不了一兩天，這樣的故障同樣會出現。同時這套系統最近也沒做過大的變動。

筆者在接到接到故障報告後，通過SSH連線到資料庫資料庫都非常慢，需要差不多1分鐘才能連線上去。先簡單的看一下伺服器的效能狀況，發展IO極低、記憶體剩餘還比較多，至少還有1GB以上，也沒有page in / page out。而最顯著的現象就是CPU利用率相當地高，一直保持在100%，同時CPU利用率的SYS部分，均在95%以上。而作業系統執行佇列也一直在200以上。伺服器記憶體的使用情況如下：

$cat/proc/meminfo

MemTotal: 32999792 kB

MemFree: 1438672 kB

Buffers: 112304 kB

Cached: 23471680 kB

SwapCached: 1296 kB

Active: 19571024 kB

Inactive: 6085396 kB

HighTotal: 0 kB

HighFree: 0 kB

LowTotal: 32999792 kB

LowFree: 1438672 kB

SwapTotal: 38371320 kB

SwapFree: 38260796 kB

Dirty: 280 kB

Writeback: 0kB

AnonPages: 2071192 kB

Mapped: 12455324 kB

Slab: 340140 kB

PageTables: 4749076 kB

NFS_Unstable: 0 kB

Bounce: 0 kB

CommitLimit: 54871216kB

Committed_AS: 17226744 kB

VmallocTotal:34359738367 kB

VmallocUsed: 22016 kB

VmallocChunk:34359716303 kB

從現象上看，SYS CPU高是分析問題的一個重要線索。

在以最快的速度瞭解了一下作業系統層面的效能情況之後，立即通過Sqlplus連線到資料庫，檢視資料庫內部的效能資訊：

(注：以下資料關於SQL、伺服器名稱、資料庫名稱等相關資訊經過處理。）

SQL> select sid,serial#,program,machine,sql_id,eventfrom v$session where type='USER' and status='ACTIVE';

SID SERIAL# PROGRAM MACHINE SQL_ID EVENT

-------------------- ------------------------------ ---------- -------------

519 4304 xxx_app1 0gc4uvt2pqvpu latch: cache buffers chains

459 12806 xxx_app1 0gc4uvt2pqvpu latch: cache buffers chains

454 5518 xxx_app1 15hq76k17h4ta latch: cache buffers chains

529 7708 xxx_app1 0gc4uvt2pqvpu latch: cache buffers chains

420 40948 xxx_app1 0gc4uvt2pqvpu latch: cache buffers chains

353 56222 xxx_app1 f7fxxczffp5rx latch: cache buffers chains

243 42611 xxx_app1 2zqg4sbrq7zay latch: cache buffers chains

458 63221 xxxTimer.exe APPSERVER 9t1ujakwt6fnf local write wait

...為節省篇幅，省略部分內容...

409 4951 xxx_app1 7d4c6m3ytcx87 read by other session

239 51959 xxx_app1 7d4c6m3ytcx87 read by other session

525 3815 xxxTimer.exe APPSERVER 0ftnnr7pfw7r6 enq: RO -fast object reu

518 7845 xxx_app1 log file sync

473 1972 xxxTimer.exe APPSERVER 5017jsr7kdk3b log file sync

197 37462 xxx_app1 cbvbzbfdxn2w7 db file sequential read

319 4939 xxxTimer.exe APPSERVER 6vmk5uzu1p45m db file sequentialread

434 2939 xxx_app1 gw921z764rmkc latch: shared pool

220 50017 xxx_app1 2zqg4sbrq7zay latch: library cache

301 36418 xxx_app1 02dw161xqmrgf latch: library cache

193 25003 oracle@xxx_db1 (J001) xxx_db1 jobq slave wait

368 64846 oracle@xxx_db1 (J000) xxx_db1 jobq slave wait

218 13307 sqlplus@xxx_db1 (TNS V1-V3) xxx_db1 5rby2rfcgs6b7 SQL*Net message to client

435 1883 xxx_app1 fd7369jwkuvty SQL*Net message from client

448 3001 xxxTimer.exe APPSERVER bsk0kpawwztnwSQL*Net message from dblink


SQL>@waitevent

SID EVENT SECONDS_IN_WAIT STATE

----------------------------------- --------------- -------------------

556 latch: cache buffers chains 35 WAITED KNOWN TIME

464 latch:cache buffers chai ns 2 WAITING

427 latch:cache buffers chai ns 34 WAITED SHORT TIME

458 localwrite wait 63 WAITING

403 writecomplete waits 40 WAITING

502 writecomplete waits 41 WAITING

525 enq:RO - fast object reuse 40 WAITING

368 enq:RO - fast object reu se 23 WAITING

282 db file sequential read 0 WAITING

501 dbfile sequential read 2 WAITED SHORT TIME

478 db file sequential read 0 WAITING

281 db file sequential read 6 WAITED KNOWN TIME

195 db file sequential read 4 WAITED KNOWN TIME

450 db file sequential read 2 WAITED KNOWN TIME

529 db file sequential read 1 WAITING

310 dbfile sequential read 0 WAITED KNOWN TIME

316 db filesequential read 89 WAITED SHORT TIME

370 db file sequential read 1 WAITING

380 db file sequential read 1 WAITED SHORT TIME

326 jobq slave wait 122 WAITING

378 jobq slave wait 2 WAITING

425 jobq slave wait 108 WAITING

208 SQL*Net more data from db 11 WAITED SHORT TIME link

537 Streams AQ: waiting for t 7042 WAITING ime management or cleanup tasks

549 Streams AQ: qmn coordinat 1585854 WAITING or idle wait

507 Streams AQ: qmn slave idl 1585854 WAITING e wait

430 latch free 2 WAITED KNOWN TIME

565 latch:cache buffers lru 136 WAITED SHORT TIME chain

從資料庫中的活動以及等待事件來看，並沒有太大的異常。值得注意的是，在資料庫伺服器CPU利用率長期在100%，或實體記憶體耗盡並伴有大量的交換記憶體換入換出時，需要仔細地診斷資料庫中的效能現象，比如某類較多的等待事件，是由CPU或記憶體不足導致的結果還是因為這些資料庫中的特定的活動才是Root Cause引起CPU過高或記憶體耗盡。

從上面的資料來看，活動會話並不是特別多，不到50個，加上後臺程序的數量，與作業系統中高達200的執行相比，存在不小的差異。資料庫中主要有三類的非空閒等待事件，IO相關的等待如db file sequential read，database link相關的SQL*Net more data from dblink以及latch 相關的等待事件。在這三類種，通常只有latch這類等待事件才會引起CPU的利用率增加。

通過分析對比AWR報告，在故障期間和正常期間，從資料庫活動來說，沒有特別明顯的差異。但是在系統統計上，差異較大：

StatisticName 1st 2nd Value

----------------------------------- -------------- -------------- ------------------------

BUSY_TIME 3,475,776 1,611,753

IDLE_TIME 2,266,224 4,065,506

IOWAIT_TIME 520,453 886,345

LOAD -67 -3

NICE_TIME 0 0

NUM_CPU_SOCKETS 0 0

PHYSICAL_MEMORY_BYTES 0 0

RSRC_MGR_CPU_WAIT_TIME 0 0

SYS_TIME 1,802,025 205,644

USER_TIME 1,645,837 1,381,719

上面的資料中，是來自於包含故障時間段的1小時(1st)和正常時間段1小時(2nd)的AWR的對比資料。對於故障分析來說，特別是故障時間比較短的情況下，1小時的AWR報告會不夠準確地反映故障期間的效能情況。但是我們在Trouble Shooting之時，首要的是需要從各種資料中，確定方向。正如前面提到，SYS部分的CPU利用率過高是一個很重要的線索，而資料庫內部的其他效能資料相差不大的情況下，可以先從CPU這一點著手。

二、作業系統中CPU使用分析

那麼，在作業系統中，SYS和USER這兩個不同的利用率代表著什麼？或者說二者有什麼區別？

簡單來說，CPU利用率中的SYS部分，指的是作業系統核心(Kernel）使用的CPU部分，也就是執行在核心態的程式碼所消耗的CPU，最常見的就是系統呼叫(SYS CALL)時消耗的CPU。而USER部分則是應用軟體自己的程式碼使用的CPU部分，也就是執行在使用者態的程式碼所消耗的CPU。比如Oracle在執行SQL時，從磁碟讀資料到db buffer cache，需要發起read呼叫，這個read呼叫主要是由作業系統核心包括裝置驅動程式的程式碼在執行，因此消耗的CPU計算到SYS部分；而Oracle在解析從磁碟中讀到的資料時，則只是Oracle自己的程式碼在執行，因此消耗的CPU計算到USER部分。

那麼SYS部分的CPU主要會由哪些操作或是系統呼叫產生呢：

1. I/O操作，比如讀寫檔案、訪問外設、通過網路傳輸資料等。這部分操作一般不會消耗太多的CPU，因為主要的時間消耗會在IO操作的裝置上。比如從磁碟讀檔案時，主要的時間在磁碟內部的操作上，而消耗的CPU時間只佔I/O操作響應時間的少部分。只有在過高的併發I/O時才可能會使SYS CPU有所增加。

2. 記憶體管理，比如應用程序向作業系統申請記憶體，作業系統維護系統可用記憶體，交換空間換頁等。其實與Oracle類似，越大的記憶體，越頻繁的記憶體管理操作，CPU的消耗會越高。

3. 程序排程。這部分CPU的使用，在於作業系統中執行佇列的長短，越長的執行佇列，表明越多的程序需要排程，那麼核心的負擔也就越高。

4. 其他，包括程序間通訊、訊號量處理、裝置驅動程式內部一些活動等等。

從系統故障時的效能資料來看，記憶體管理和程序排程這兩項可能是引起SYS CPU很高的原因。但是執行佇列高達200以上，很可能是由於CPU利用率高導致的結果，而不是因為執行佇列高導致了CPU利用率高。從資料庫裡面來看活動會話數不是特別高。那麼接下來，需要關注是否是由於系統記憶體管理方面的問題導致了CPU利用率過高？

回顧本文開始部分收集的/proc/meminfo中系統記憶體方面資料，可以發現一項重要的資料：

PageTables: 4749076 kB

從資料可以看到，PageTables記憶體達到了4637MB。PageTables在字面意思上是指“頁面表”。簡單地說，就是作業系統核心用於維護程序線性虛擬地址和實際實體記憶體地址對應關係的表格。

現代計算機對於實體記憶體，通常是將其以頁(Page Frame)為單位進行管理和分配，在 x86處理器架構上，頁面大小為4K。執行在作業系統上的程序，可訪問的地址空間稱為虛地址空間，跟處理器位數有關。對於32位的x86處理器，程序的可訪問地址空間為4GB。在作業系統中執行的每一個程序，都有其獨立的虛地址空間或線性地址空間，而這個地址空間同樣也是按頁(Page)進行管理，在Linux中，頁大小通常為4KB。程序在訪問記憶體時，由作業系統和硬體配合，負責將程序的虛擬地址轉換成為實體地址。兩個不同的程序，其相同的虛擬線性地址，指向的實體記憶體，可能相同，比如共享記憶體；也可能不同，比如程序的私有記憶體。

下圖是關於虛擬地址和實體記憶體對應關係的示意圖：

假設有兩個程序A、B，分別有一個記憶體指標指向的地址為0x12345（0x表示16進位制數），比如一個程序fork或clone出另一個程序，那麼這2個程序就會存在指向相同記憶體地址的指標的情況。程序在訪問0x12345這個地址指向的記憶體時，作業系統將這個地址轉換為實體地址，比如A程序為0x23456，B程序為0x34567，二者互不影響。那麼這個實體地址是什麼時候得來？對於程序私有記憶體（大部分情況均是如此）來說，是程序在向作業系統請求分配記憶體時得來。程序向作業系統請求分配記憶體時，作業系統將空閒的實體記憶體以Page為單位分配給程序，同時給程序產生一個虛擬執行緒地址，在虛擬地址和實體記憶體地址之間建立 對映關係，這個虛擬地址作為結果返回給程序。

Page Table（頁表）就是用於作業系統維護程序虛擬地址和實體記憶體對應關係的資料結構。下圖是一個比較簡單情況下的Page Table示意圖：

下面簡單地描述在32位系統下，頁大小為4K時，作業系統是如何為程序的虛擬地址和實際實體地址之間進行轉換的。

1. 目錄表是用於索引頁表的資料結構，每個目錄項佔32位，即4位元組，儲存一個頁表的位置。目錄表剛好佔用1頁記憶體，即4KB，可以儲存1024個目錄項，也就是可以儲存1024個頁表的位置。

2. 頁表項(Page Table Entry）大小為4位元組，儲存一個實體記憶體頁起始地址。每個頁表同樣佔用4K記憶體，可以儲存1024個實體記憶體頁起始地址。由於實體記憶體頁起始地址以4KB為單位對齊，所以32位中，只需要20位來表示地址，其他12位用於其他用途，比如表示這1記憶體頁是隻讀還是可寫等等。

3. 1024個頁表，每個頁表1024個實體記憶體頁起始地址，合計就是1M個地址，每個地址指向的實體記憶體頁大小為4KB，合計為4GB。

4. 作業系統及硬體將虛擬地址對映為實體地址時，將虛擬地址的31-22這10位用於從目錄項中索引到1024個頁表中的一個；將虛擬地址的12-21這10位用於從頁表中索引到1024個頁表項中的一個。從這個索引到的頁表項中得到實體記憶體頁的起始地址，然後將虛擬地址的0-11這12位用作4KB記憶體頁中的偏移量。那麼實體記憶體頁起始地址加上偏移量就是程序所需要訪問的實體記憶體的地址。

再看看目錄表和頁表這2種資料結構佔用的空間會有多少。目錄表固定只有4KB。而頁表呢？由於最多有1024個頁表，每個頁表佔用4KB，因此頁表最多佔用4MB記憶體。

實際上32位Linux中的程序通常不會那麼大的頁表。程序不可能用完所有的4GB大小地址空間，甚至有1GB虛擬地址空間分給了核心。同時Linux不會為程序一次性建立那麼大的頁表，只有程序在分配和訪問記憶體時，作業系統才會為程序建立相應地址的對映。

這裡只描述了最簡單情況下的分頁對映。實際上頁表目錄連同頁表一共有四級。同時在32位下啟用PAE或64位系統，其頁表結構比上面的示意圖更復雜。但無論怎麼樣，最後一級即頁表的結構是一致的。

在64位系統中，Page Table（頁表）中的頁表項，與32位相比，大小從32位變為64位。那麼這會有多大的影響？假如一個程序，訪問的實體記憶體有1GB，即262144個記憶體頁，在32位系統中，頁表需要262144*4/1024/1024=1MB，而在64位系統下，頁表佔用的空間增加1倍，即為2MB。

那再看看對於Linux系統中執行的Oracle資料庫，又是怎麼樣一番情景。本文案例中資料庫的SGA大小12GB，如果一個OracleProcess訪問到了所有的SGA記憶體，那麼其頁表大小會是24MB，這是一個驚人的數字。這裡忽略掉PGA，因為平均下來每個程序的PGA不超過2M，與SGA相比實在太小。從AWR報告來看，有300個左右的會話，那麼這300個連線的頁表會達到7200MB，只不過並不是每個程序都會訪問到SGA中所有的記憶體。而從meminfo檢視到的Page Tables大小達到4637MB，這麼大的Page Table空間，正是300個會話，SGA大小達到12GB的結果。

系統中顯然不會只有Page Table這唯一的記憶體管理資料結構，還有其他一些資料結構用於管理記憶體。這些過大的記憶體管理結構，無疑會大大增加作業系統核心的負擔和對CPU的消耗。而在負載變化或其他原因導致記憶體需求大幅變化，比如多程序同時申請大量的記憶體，可能引起CPU在短時間內達到高峰，從而引起問題。

三、使用大記憶體頁來解決問題

雖然沒有確實的證據，也沒有足夠長的時間來收集足夠的證據來證明是過大的Page Table導致了問題，那需要面臨多次半小時以上的系統不可用故障。但是從目前來看，這是最大的可疑點。因此，決定先使用大記憶體頁來調優系統的記憶體使用。

大記憶體頁是一種統稱，在低版本的Linux中為Large Page，而當前主流的Linux版本中為Huge Page。下面以Huge Page為例來說明Huge Page的優點及如何使用。

使用大記憶體頁有哪些好處：

1. 減少頁表(Page Table）大小。每一個Huge Page，對應的是連續的2MB實體記憶體，這樣12GB的實體記憶體只需要48KB的Page Table，與原來的24MB相比減少很多。

2. Huge Page記憶體只能鎖定在實體記憶體中，不能被交換到交換區。這樣避免了交換引起的效能影響。

3. 由於頁表數量的減少，使得CPU中的TLB（可理解為CPU對頁表的CACHE）的命中率大大提高。

4. 針對Huge Page的頁表，在各程序之間可以共享，也降低了Page Table的大小。實際上這裡可以反映出Linux在分頁處理機制上的缺陷。而其他作業系統，比如AIX，對於共享記憶體段這樣的記憶體，程序共享相同的頁表，避免了Linux的這種問題。像筆者維護的一套系統，連線數平常都是5000以上，例項的SGA在60GB左右，要是按Linux的分頁處理方式，系統中大部分記憶體都會被頁表給用掉。

那麼，怎麼樣為Oracle啟用大記憶體頁(Huge Page)？以下是實施步驟。由於案例中涉及的資料庫在過一段時間後將SGA調整為了18G，這裡就以18G為例：

1、檢查/proc/meminfo，確認系統支援HugePage：

HugePages_Total: 0

HugePages_Free: 0

HugePages_Rsvd: 0

Hugepagesize: 2048 kB

HugePages Total表示系統中配置的大記憶體頁頁面數。HugePages Free表示沒有訪問過的大記憶體頁面數，這裡free容易引起誤解，這在稍後有所解釋。HugePages Rsvd表示已經分配但是還未使用的頁面數。Hugepagesize表示大記憶體頁面大小，這裡為2MB，注意在有的核心配置中可能為4MB。

比如HugePages總計11GB，SGA_MAX_SIZE為10GB，SGA_TARGET為8GB。那麼資料庫啟動後，會根據SGA_MAX_SIZE分配HugePage記憶體，這裡為10GB，真正Free的HugePage記憶體為11-10=1G。但是SGA_TARGET只有8GB，那麼會有2GB不會被訪問到，則HugePage_Free為2+1=3GB，HugePage_Rsvd記憶體有2GB。這裡實際上可以給其他例項使用的只有1GB，也就是真正意義上的Free只有1GB。

2. 計劃要設定的記憶體頁數量。到目前為止，大記憶體頁只能用於共享記憶體段等少量型別 的記憶體。一旦將實體記憶體用作大記憶體頁，那麼這些實體記憶體就不能用作其他用途，比如作為程序的私有記憶體。因此不能將過多的記憶體設定為大記憶體頁。我們通常將大記憶體頁用作Oracle資料庫的SGA，那麼大記憶體頁數量：

HugePages_Total=ceil(SGA_MAX_SIZE/Hugepagesize)+N

比如，為資料庫設定的SGA_MAX_SIZE為18GB，那麼頁面數可以為ceil(18*1024/2)+2=9218。

這裡加上N，是需要將HugePage記憶體空間設定得比SGA_MAX_SIZE稍大，通常為1-2即可。我們通過ipcs -m命令檢視共享記憶體段的大小，可以看到共享記憶體段的大小實際上比SGA_MAX_SIZE約大。如果伺服器上有多個Oracle例項，需要為每個例項考慮共享記憶體段多出的部分，即N值會越大。另外，Oracle資料庫要麼全部使用大記憶體頁，要麼完全不使用大記憶體頁，因此不合適的HugePages_Total將造成記憶體的浪費。

除了使用SGA_MAX_SIZE計算，也可以通過ipcs -m所獲取的共享記憶體段大小計算出更準確的HugePages_Total。

HugePages_Total=sum(ceil(share_segment_size/Hugepagesize))

3. 修改/etc/sysctl.conf檔案，增加如下行：

vm.nr_hugepages=9218

然後執行sysctl –p命令，使配置生效。

這裡vm.nr_hugepages這個引數值為第2步計算出的大記憶體頁數量。然後檢查/proc/meminfo，如果HugePages_Total小於設定的數量，那麼表明沒有足夠的連續實體記憶體用於這些大記憶體頁，需要重啟伺服器。

4. 在/etc/security/limits.conf檔案中增加如下行：

oracle soft memlock 18878464

oracle hard memlock 18878464

這裡設定oracle使用者可以鎖定記憶體的大小 ，以KB為單位。

然後重新以oracle使用者連線到資料庫伺服器，使用ulimit -a命令，可以看到：

max lockedmemory (kbytes,-l) 18878464

這裡將memlock配置為unlimited也可以。

5. 如果資料庫使用MANUAL方式管理SGA，需要改為AUTO方式，即將SGA_TARGET_SIZE設定為大於0的值。對於11g，由於HugePage只能用於共享記憶體，不能用於PGA，所以不能使用AMM，即不能設定MEMORY_TARGET為大於0，只能分別設定SGA和PGA，SGA同樣只能是AUTO方式管理。

6. 最後啟動資料庫，檢查/proc/meminfo中檢視HugePages_Free是否已經減少。如果已經減少，表明已經使用到HugePage Memory。

不過查看出故障資料庫伺服器上的/proc/meminfo時發現，居然沒有HugePage相關的資訊，sysctl -a檢視所有系統引數也沒有找到vm.nr_hugepages這個引數。這是由於Linux核心沒有編譯進HugePage這個特性。我們需要使用其他的核心來啟用HugePage。

檢視/boot/grub/grub.conf：

# grub.confgenerated by anaconda

# Note thatyou do not have to rerun grub after making changes to this file

#NOTICE: You have a /boot partition. This means that

# all kerneland initrd paths are relative to /boot/,eg.

# root(hd0,0)

# kernel/vmlinuz-version ro root=/dev/VolGroup00/LogVol00

# initrd/initrd-version.img

#boot=/dev/cciss/c0d0

default=0

timeout=5

splashimage=(hd0,0)/grub/splash.xpm.gz

hiddenmenu

title Red HatEnterprise Linux Server (2.6.18-8.el5xen) with RDAC

root (hd0,0)

kernel /xen.gz-2.6.18-8.el5

module /vmlinuz-2.6.18-8.el5xen roroot=/dev/VolGroup00/LogVol00 rhgb quiet

module /mpp-2.6.18-8.el5xen.img

title Red HatEnterprise Linux Server (2.6.18-8.el5xen)

root (hd0,0)

kernel /xen.gz-2.6.18-8.el5

module /vmlinuz-2.6.18-8.el5xen roroot=/dev/VolGroup00/LogVol00 rhgb quiet

module /initrd-2.6.18-8.el5xen.img

title Red HatEnterprise Linux Server-base (2.6.18-8.el5)

root (hd0,0)

kernel /vmlinuz-2.6.18-8.el5 roroot=/dev/VolGroup00/LogVol00 rhgb quiet

module/initrd-2.6.18-8.el5.img

發現這個系統使用的核心帶有"xen"字樣，我們修改這個檔案，將default=0改為default=2，或者將前面2種核心用#號遮蔽掉，然後重啟資料庫伺服器，發現新的核心已經支援HugePage。

資料庫啟用大記憶體頁之後，本文描述的效能問題甚至是在增大了SGA的情況下也沒有出現。觀察/proc/meminfo資料，PageTables佔用的記憶體一直保持在120M以下，與原來相比，減少了4500MB。據觀察，CPU的利用率也較使用HugePages之前有所下降，而系統執行也相當地穩定，至少沒有出現因使用HugePage而產生的BUG。

測試表明，對於OLTP系統來說，在執行Oracle資料庫的Linux上啟用HugePage，資料庫處理能力和響應時間均有不同程度的提高，最高甚至可以達到10%以上。

四、小結

本文以一個案例，介紹了Linux作業系統下大記憶體頁在效能提升方面的作用，以及如何設定相應的引數來啟用大記憶體頁。在本文最後，筆者建議在Linux作業系統中執行Oracle資料庫時，啟用大記憶體頁來避免本文案例遇到的效能問題，或進一步提高系統性能。可以說，HugePage是少數不需要額外代價就能提升效能的特性。另外值得高興的是，新版本的Linux核心提供了Transparent Huge Pages，以便執行在Linux上的應用能更廣泛更方便地使用大記憶體頁，而不僅僅是隻有共享記憶體這類記憶體才能使用大記憶體頁。對於這一特性引起的變化，讓我們拭目以待。

文章來源:《Oracle DBA手記 3》Linux大記憶體頁Oracle資料庫優化 作者：熊軍

配圖來源: http://2.bp.blogspot.com/-o1ihxahkl0o/VQFhFj2lHwI/AAAAAAAAAV4/egUhLwaYtmc/s1600/oracle_linux.png

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對我們的支援。