0Linux大內(nèi)存Oracle數(shù)據(jù)庫優(yōu)化-熊軍概述

1、Inactive:6085396 kBLinux大內(nèi)存頁Oracle數(shù)據(jù)庫優(yōu)化PCServer發(fā)展到今天，在性能方面有著長足的進(jìn)步。64位的CPU在數(shù)年前都已經(jīng)進(jìn)入到尋常的家用 PC之中，更別說是更高端的PC Server ;在Intel和AMD兩大處理器巨頭的努力下，x86 CPU在處理能力上不斷提升；同時(shí)隨著制造工藝的發(fā)展，在PC Server上能夠安裝的內(nèi)存容量也越來越大，現(xiàn)在隨處可見數(shù)十G內(nèi)存的PCServer。正是硬件的發(fā)展，使得PC Server的處理能力越來越強(qiáng)大，性能越來越高。而在穩(wěn)定性方面，搭配PC Server和Linux操作系統(tǒng)，同樣能夠滿重要業(yè)務(wù)系統(tǒng)所需要的穩(wěn)定性和可靠

2、性。當(dāng)然在成本方面， 引用一位在行業(yè)軟件廠商的網(wǎng)友的話來說，“如果不用PC Server改用小型機(jī)，那我們賺什么錢??？”。不管從初期的購買，運(yùn)行期的能耗和維護(hù)成本，PC Server都比相同處理能力的小型機(jī)便宜很多。正是在性能和成本這兩個(gè)重要因素的影響下，運(yùn)行在PCServer上的數(shù)據(jù)庫越來越多。筆者所服務(wù)的一些客戶，甚至把高端的 PCServer虛擬化成多臺(tái)機(jī)器，在每 臺(tái)虛擬機(jī)上跑一套 Oracle數(shù)據(jù)庫，這些數(shù)據(jù)庫不乏承載著重要的生產(chǎn)系統(tǒng)。毫無疑問，在 PC Server上運(yùn)行Oracle數(shù)據(jù)庫，最適合的操作系統(tǒng)無疑是Linux。作為與UNIX極為類似的操作系統(tǒng)，在穩(wěn)定性、可靠性和性能方面

3、有著與UNIX同樣優(yōu)異的表現(xiàn)。但是Linux在內(nèi)存分頁處理機(jī)制上與 AIX、HP-UX等操作系統(tǒng)相比有一個(gè)明顯的缺陷，而這 個(gè)缺陷在使用較大 SGA的 Oracle數(shù)據(jù)庫上體現(xiàn)尤為明顯，嚴(yán)重時(shí)對(duì)數(shù)據(jù)庫性能有著顯著的 負(fù)面影響，甚至?xí)?dǎo)致數(shù)據(jù)庫完全停止響應(yīng)。而本文就將從一個(gè)案例來詳述這種缺陷，并使用Linux下的大內(nèi)存頁來解決這一問題。、案例的引入客戶的一套系統(tǒng)，出現(xiàn)了嚴(yán)重的性能問題。在問題出現(xiàn)時(shí)，系統(tǒng)基本不可使用，應(yīng)用上所有的業(yè)務(wù)操作完全失去響應(yīng)。系統(tǒng)的數(shù)據(jù)庫是運(yùn)行在 RHEL5.2 (Red Hat Enterprise LinuxServer release 5 (Tikanga)下的 O

4、racle 10.2.0.4 Oracle Database ， CPU為 4 顆 4 核至強(qiáng)處理器(Intel(R)Xeon(R) CPU E7430 2.13GHz),也就是邏輯 CPU為 16,內(nèi)存 32GB故障期間，數(shù)據(jù)庫服務(wù)器的CPU長期保持在100%甚至將應(yīng)用的所有Weblogic Server 都關(guān)閉之后，數(shù)據(jù)庫服務(wù)器的CPU利用率在數(shù)分鐘之內(nèi)都一直是100%然后逐漸下降，大約需要經(jīng)過20分鐘才會(huì)下降到正常的空閑狀態(tài)，因?yàn)檫@個(gè)時(shí)候所有的應(yīng)用都已經(jīng)關(guān)閉，只有 非常低的CPU利用率才是正常的狀態(tài)。據(jù)這套系統(tǒng)的數(shù)據(jù)庫維護(hù)人員反映，這種情況已經(jīng)出現(xiàn)多次，就算是重啟數(shù)據(jù)庫之后，過不了一兩天

5、，這樣的故障同樣會(huì)出現(xiàn)。同時(shí)這套系統(tǒng)最近也沒做過大的變動(dòng)。筆者在接到接到故障報(bào)告后，通過SSH連接到數(shù)據(jù)庫數(shù)據(jù)庫都非常慢，需要差不多1分鐘才能連接上去。 先簡(jiǎn)單的看一下服務(wù)器的性能狀況，發(fā)展IO極低、內(nèi)存剩余還比較多，至少還有1GB以上，也沒有 page in / page out。而最顯著的現(xiàn)象就是CPU利用率相當(dāng)?shù)馗?，一直保持?00%,同時(shí)CPU利用率的SYS部分，均在95%以上。而操作系統(tǒng)運(yùn)行隊(duì)列也 一直在200以上。服務(wù)器內(nèi)存的使用情況如下：$cat /proc/meminfoMemTotal: 32999792 kBMemFree:1438672 kBBuffers:112304

6、kBCached:23471680 kBSwapCached:1296 kBActive:19571024 kBHighTotal:0 kBHighFree:0 kBLowTotal:32999792kBLowFree:1438672kBSwapTotal:38371320 kBSwapFree:38260796 kBDirty:280 kBWriteback:0 kBAnonPages:2071192 kBMapped:12455324 kBSlab:340140 kBPageTables:4749076 kBNFS_Unstable:0 kBBounce:0 kBCommitLimit:5

7、4871216 kBCommitted_AS: 17226744 kBVmallocTotal: 34359738367 kBVmallocUsed:22016 kBVmallocChunk: 34359716303 kB從現(xiàn)象上看，SYS CPU高是分析問題的一個(gè)重要線索。在以最快的速度了解了一下操作系統(tǒng)層面的性能情況之后，立即通過Sqlplus連接到數(shù)據(jù)庫，查看數(shù)據(jù)庫內(nèi)部的性能信息：（注：以下數(shù)據(jù)關(guān)于 SQL服務(wù)器名稱、數(shù)據(jù)庫名稱等相關(guān)信息經(jīng)過處理。）SQL> select sid,serial#,program,machine,sql_id,eventfrom v$session

8、where type='USER' andstatus='ACTIVE：SID SERIAL# PROGRAM MACHINE SQL_ID EVENT5194304xxx_app10gc4uvt2pqvpu latch: cache buffers chains45912806xxx_app10gc4uvt2pqvpu latch: cache buffers chains4545518xxx_app115hq76k17h4ta latch: cache buffers chains5297708xxx_app10gc4uvt2pqvpu latch: cache b

9、uffers chains42040948xxx_app10gc4uvt2pqvpu latch: cache buffers chains35356222xxx_app1f7fxxczffp5rx latch: cache buffers chains24342611xxx_app12zqg4sbrq7zay latch: cache buffers chains45863221xxxTimer.exe）APPSERVER 9t1ujakwt6fnf local write wait.為節(jié)省篇幅，省略部分內(nèi)容4094951xxx_app17d4c6m3ytcx87 read by other

10、 session23951959xxx_app17d4c6m3ytcx87 read by other session5253815xxxTimer.exeAPPSERVER 0ftnnr7pfw7r6 enq: RO - fast object reu5187845xxx_app1log file sync4731972xxxTimer.exeAPPSERVER 5017jsr7kdk3b log file sync19737462xxx_app1cbvbzbfdxn2w7 db file sequential read3194939xxxTimer.exeAPPSERVER 6vmk5uz

11、u1p45m db file sequential read434 2939xxx_app1 gw921z764rmkc latch: shared pool22050017xxx_app1 2zqg4sbrq7zay latch: library cache30136418xxx_app1 02dw161xqmrgf latch: library cache19325003 oraclexxx_db1 (J001)xxx_db1 jobq slave wait36864846 oraclexxx_db1 (J000)xxx_db1 jobq slave wait21813307 sqlplu

12、sxxx_db1 (TNS V1-V3) xxx_db1 5rby2rfcgs6b7 SQL*Net message to client435 1883xxx_app1 fd7369jwkuvty SQL*Net message from client4483001 xxxTimer.exeAPPSERVER bskOkpawwztnw SQL*Net message from dblinkSQL> waiteventSID EVENTSECONDS_IN_WAIT STATE556latch: cache buffers chains35WAITED KNOWN TIME464latc

13、h: cache buffers chai ns2WAITING427latch: cache buffers chai ns34WAITED SHORT TIME458local write wait63WAITING403write complete waits40WAITING502write complete waits41WAITING525enq: RO - fast object reu se40WAITING368enq: RO - fast object reu se23WAITING282db file sequential read0WAITING501db file s

14、equential read2WAITED SHORT TIME478db file sequential read0WAITING281db file sequential read6WAITED KNOWN TIME195db file sequential read4WAITED KNOWN TIME450db file sequential read2WAITED KNOWN TIME529db file sequential read1WAITING310db file sequential read0WAITED KNOWN TIME316db file sequential re

15、ad89WAITED SHORT TIME370db file sequential read1WAITING380db file sequential read1WAITED SHORT TIME326jobq slave wait122WAITING378jobq slave wait2WAITING425jobq slave wait108WAITING208SQL*Net more data from db11WAITED SHORT TIME link537Streams AQ: waiting for t7042WAITING ime management or cleanup t

16、asks549Streams AQ: qmn coordinat1585854WAITING or idle wait507Streams AQ: qmn slave idl1585854WAITING e wait430latch free2WAITED KNOWN TIME565latch: cache buffers lru136WAITED SHORT TIME chain從數(shù)據(jù)庫中的活動(dòng)以及等待事件來看，并沒有太大的異常。 值得注意的是，在數(shù)據(jù)庫服務(wù)器CPU利用率長期在100%,或物理內(nèi)存耗盡并伴有大量的交換內(nèi)存換入換出時(shí)，需要仔 細(xì)地診斷數(shù)據(jù)庫中的性能現(xiàn)象，比如某類較多的等待事件，

17、是由CPU或內(nèi)存不足導(dǎo)致的結(jié)果還是因?yàn)檫@些數(shù)據(jù)庫中的特定的活動(dòng)才是Root Cause引起CPU過高或內(nèi)存耗盡。從上面的數(shù)據(jù)來看，活動(dòng)會(huì)話并不是特別多，不到50個(gè)，加上后臺(tái)進(jìn)程的數(shù)量，與操作系統(tǒng)中高達(dá)200的運(yùn)行相比，存在不小的差異。數(shù)據(jù)庫中主要有三類的非空閑等待事件，10 相關(guān)的等待如 db file sequential read， database link 相關(guān)的 SQL*Net more data from db link以及l(fā)atch 相關(guān)的等待事件。在這三類種，通常只有l(wèi)atch這類等待事件才會(huì)引起CPU的利用率增加。通過分析對(duì)比AWR艮告，在故障期間和正常期間，從數(shù)據(jù)庫活動(dòng)來說

18、，沒有特別明顯的差異。但是在系統(tǒng)統(tǒng)計(jì)上，差異較大：Statistic Name1st2ndValueBUSY_TIME3,475,7761,611,753IDLE_TIME2,266,2244,065,506IOWAIT_TIME520,453886,345LOAD-67-3NICE_TIME00NUM_CPU_SOCKETS0 0PHYSICAL_MEMORY_BYTES0 0RSRC_MGR_CPU_WAIT_TIME0 0SYS_TIME1,802,025205,644USER_TIME1,645,8371,381,719上面的數(shù)據(jù)中，是來自于包含故障時(shí)間段的1小時(shí)(1st)和正常時(shí)間段

19、1小時(shí)(2nd)的AWR勺對(duì)比數(shù)據(jù)。對(duì)于故障分析來說，特別是故障時(shí)間比較短的情況下，1小時(shí)的AWR艮告會(huì)不夠準(zhǔn)確地反映故障期間的性能情況。但是我們?cè)赥rouble Shoot ing之時(shí)，首要的是需要從各種數(shù)據(jù)中，確定方向。正如前面提到，SYS部分的CPU利用率過高是一個(gè)很重要的線索，而數(shù)據(jù)庫內(nèi)部的其他性能數(shù)據(jù)相差不大的情況下，可以先從CPU這一點(diǎn)著手。二、操作系統(tǒng)中CPU使用分析那么，在操作系統(tǒng)中，SYS和USER這兩個(gè)不同的利用率代表著什么？或者說二者有什么區(qū)別？簡(jiǎn)單來說，CPU利用率中的SYS部分，指的是操作系統(tǒng)內(nèi)核 (Kernel )使用的CPU部分， 也就是運(yùn)行在內(nèi)核態(tài)的代碼所消耗的

20、CPU最常見的就是系統(tǒng)調(diào)用(SYS CALL)時(shí)消耗的CPU而USER部分則是應(yīng)用軟件自己的代碼使用的CPU部分，也就是運(yùn)行在用戶態(tài)的代碼所消耗的CPU比如Oracle在執(zhí)行SQL時(shí)，從磁盤讀數(shù)據(jù)到 db buffer cache ，需要發(fā)起read調(diào) 用，這個(gè)read調(diào)用主要是由操作系統(tǒng)內(nèi)核包括設(shè)備驅(qū)動(dòng)程序的代碼在運(yùn)行，因此消耗的CPU計(jì)算到SYS部分；而Oracle在解析從磁盤中讀到的數(shù)據(jù)時(shí)，則只是Oracle自己的代碼在運(yùn)行，因此消耗的 CPU計(jì)算到USER部分。那么SYS部分的CPU主要會(huì)由哪些操作或是系統(tǒng)調(diào)用產(chǎn)生呢：1. I/O操作，比如讀寫文件、訪問外設(shè)、通過網(wǎng)絡(luò)傳輸數(shù)據(jù)等。這部分

21、操作一般不會(huì)消耗太多的CPU因?yàn)橹饕臅r(shí)間消耗會(huì)在IO操作的設(shè)備上。比如從磁盤讀文件時(shí)，主要的時(shí)間在磁盤內(nèi)部的操作上，而消耗的CPU時(shí)間只占I/O操作響應(yīng)時(shí)間的少部分。只有在過高的并發(fā)I/O時(shí)才可能會(huì)使SYS CPUW所增加。2. 內(nèi)存管理，比如應(yīng)用進(jìn)程向操作系統(tǒng)申請(qǐng)內(nèi)存，操作系統(tǒng)維護(hù)系統(tǒng)可用內(nèi)存，交換空間換頁等。其實(shí)與 Oracle類似，越大的內(nèi)存，越頻繁的內(nèi)存管理操作，CPU的消耗會(huì)越高。3. 進(jìn)程調(diào)度。這部分CPU的使用，在于操作系統(tǒng)中運(yùn)行隊(duì)列的長短，越長的運(yùn)行隊(duì)列，表明越多的進(jìn)程需要調(diào)度，那么內(nèi)核的負(fù)擔(dān)也就越高。4. 其他，包括進(jìn)程間通信、信號(hào)量處理、設(shè)備驅(qū)動(dòng)程序內(nèi)部一些活動(dòng)等等。從系

22、統(tǒng)故障時(shí)的性能數(shù)據(jù)來看，內(nèi)存管理和進(jìn)程調(diào)度這兩項(xiàng)可能是引起SYSCPU很高的原因。但是運(yùn)行隊(duì)列高達(dá) 200以上，很可能是由于 CPU利用率高導(dǎo)致的結(jié)果，而不是因?yàn)檫\(yùn) 行隊(duì)列高導(dǎo)致了 CPU利用率高。從數(shù)據(jù)庫里面來看活動(dòng)會(huì)話數(shù)不是特別高。那么接下來，需要關(guān)注是否是由于系統(tǒng)內(nèi)存管理方面的問題導(dǎo)致了CPU利用率過高？回顧本文開始部分收集的/proc/memi nfo 中系統(tǒng)內(nèi)存方面數(shù)據(jù)，可以發(fā)現(xiàn)一項(xiàng)重要的數(shù) 據(jù)：PageTables: 4749076 kB從數(shù)據(jù)可以看到，PageTables內(nèi)存達(dá)到了 4637MB PageTables在字面意思上是指“頁 面表”。簡(jiǎn)單地說，就是操作系統(tǒng)內(nèi)核用于維護(hù)

23、進(jìn)程線性虛擬地址和實(shí)際物理內(nèi)存地址對(duì)應(yīng) 關(guān)系的表格。現(xiàn)代計(jì)算機(jī)對(duì)于物理內(nèi)存，通常是將其以頁(Page Frame)為單位進(jìn)行管理和分配，在x86處理器架構(gòu)上，頁面大小為4K。運(yùn)行在操作系統(tǒng)上的進(jìn)程，可訪問的地址空間稱為虛地 址空間，跟處理器位數(shù)有關(guān)。對(duì)于32位的x86處理器，進(jìn)程的可訪問地址空間為4GB在操作系統(tǒng)中運(yùn)行的每一個(gè)進(jìn)程，都有其獨(dú)立的虛地址空間或線性地址空間，而這個(gè)地址空間同樣也是按頁(Page)進(jìn)行管理，在Linux中，頁大小通常為 4KB進(jìn)程在訪問內(nèi)存時(shí)，由操 作系統(tǒng)和硬件配合，負(fù)責(zé)將進(jìn)程的虛擬地址轉(zhuǎn)換成為物理地址。兩個(gè)不同的進(jìn)程， 其相同的虛擬線性地址，指向的物理內(nèi)存，可能相同

24、，比如共享內(nèi)存；也可能不同，比如進(jìn)程的私有 內(nèi)存。F圖是關(guān)于虛擬地址和物理內(nèi)存對(duì)應(yīng)關(guān)系的示意圖:Process BProcess A假設(shè)有兩個(gè)進(jìn)程 A B,分別有一個(gè)內(nèi)存指針指向的地址為0x12345( 0x表示16進(jìn)制數(shù))，比如一個(gè)進(jìn)程fork或clone出另一個(gè)進(jìn)程，那么這 2個(gè)進(jìn)程就會(huì)存在指向相同內(nèi)存地址的 指針的情況。進(jìn)程在訪問0x12345這個(gè)地址指向的內(nèi)存時(shí)，操作系統(tǒng)將這個(gè)地址轉(zhuǎn)換為物理地址，比如 A進(jìn)程為0x23456，B進(jìn)程為0x34567，二者互不影響。那么這個(gè)物理地址是什 么時(shí)候得來？對(duì)于進(jìn)程私有內(nèi)存(大部分情況均是如此)來說，是進(jìn)程在向操作系統(tǒng)請(qǐng)求分配內(nèi)存時(shí)得來。進(jìn)程向操

25、作系統(tǒng)請(qǐng)求分配內(nèi)存時(shí)，操作系統(tǒng)將空閑的物理內(nèi)存以Page為單位分配給進(jìn)程，同時(shí)給進(jìn)程產(chǎn)生一個(gè)虛擬線程地址，在虛擬地址和物理內(nèi)存地址之間建立映射關(guān)系，這個(gè)虛擬地址作為結(jié)果返回給進(jìn)程。Page Table (頁表)就是用于操作系統(tǒng)維護(hù)進(jìn)程虛擬地址和物理內(nèi)存對(duì)應(yīng)關(guān)系的數(shù)據(jù)結(jié) 構(gòu)。下圖是一個(gè)比較簡(jiǎn)單情況下的Page Table示意圖：披性地恥物理地址下面簡(jiǎn)單地描述在 32位系統(tǒng)下，頁大小為4K時(shí)，操作系統(tǒng)是如何為進(jìn)程的虛擬地址和 實(shí)際物理地址之間進(jìn)行轉(zhuǎn)換的。1. 目錄表是用于索引頁表的數(shù)據(jù)結(jié)構(gòu)，每個(gè)目錄項(xiàng)占32位，即4字節(jié)，存儲(chǔ)一個(gè)頁表的位置。目錄表剛好占用1頁內(nèi)存，即4KB,可以存儲(chǔ)1024個(gè)目錄項(xiàng)

26、，也就是可以存儲(chǔ)1024個(gè)頁表的位置。2. 頁表項(xiàng)(Page Table Entry )大小為4字節(jié)，存儲(chǔ)一個(gè)物理內(nèi)存頁起始地址。每個(gè)頁表同樣占用4K內(nèi)存，可以存儲(chǔ)1024個(gè)物理內(nèi)存頁起始地址。由于物理內(nèi)存頁起始地址以4KB為單位對(duì)齊，所以 32位中，只需要20位來表示地址，其他 12位用 于其他用途，比如表示這1內(nèi)存頁是只讀還是可寫等等。3. 1024個(gè)頁表，每個(gè)頁表 1024個(gè)物理內(nèi)存頁起始地址，合計(jì)就是1M個(gè)地址，每個(gè)地址指向的物理內(nèi)存頁大小為4KB,合計(jì)為4GB4. 操作系統(tǒng)及硬件將虛擬地址映射為物理地址時(shí)，將虛擬地址的31-22這10位用于從目錄項(xiàng)中索引到1024個(gè)頁表中的一個(gè)；將虛

27、擬地址的12-21這10位用于從頁表 中索引到1024個(gè)頁表項(xiàng)中的一個(gè)。從這個(gè)索引到的頁表項(xiàng)中得到物理內(nèi)存頁的起始地址，然后將虛擬地址的 0-11這12位用作4KB內(nèi)存頁中的偏移量。那么物理內(nèi) 存頁起始地址加上偏移量就是進(jìn)程所需要訪問的物理內(nèi)存的地址。再看看目錄表和頁表這 2種數(shù)據(jù)結(jié)構(gòu)占用的空間會(huì)有多少。目錄表固定只有4KB而頁表呢？由于最多有1024個(gè)頁表，每個(gè)頁表占用4KB,因此頁表最多占用 4MB內(nèi)存。實(shí)際上32位Linux中的進(jìn)程通常不會(huì)那么大的頁表。進(jìn)程不可能用完所有的4GB大小地址空間，甚至有1GB虛擬地址空間分給了內(nèi)核。同時(shí)Linux不會(huì)為進(jìn)程一次性建立那么大的頁表，只有進(jìn)程在分

28、配和訪問內(nèi)存時(shí)，操作系統(tǒng)才會(huì)為進(jìn)程建立相應(yīng)地址的映射。這里只描述了最簡(jiǎn)單情況下的分頁映射。實(shí)際上頁表目錄連同頁表一共有四級(jí)。同時(shí)在32位下啟用PAE或64位系統(tǒng)，其頁表結(jié)構(gòu)比上面的示意圖更復(fù)雜。但無論怎么樣，最后 級(jí)即頁表的結(jié)構(gòu)是一致的。在64位系統(tǒng)中，Page Table (頁表)中的頁表項(xiàng)，與32位相比，大小從 32位變?yōu)?4位。那么這會(huì)有多大的影響？假如一個(gè)進(jìn)程，訪問的物理內(nèi)存有1GB即262144個(gè)內(nèi)存頁，在32位系統(tǒng)中，頁表需要 262144*4/1024/1024=1MB，而在64位系統(tǒng)下，頁表占用的空間 增加1倍，即為2MB那再看看對(duì)于Linux系統(tǒng)中運(yùn)行的 Oracle數(shù)據(jù)庫，

29、又是怎么樣一番情景。本文案例中 數(shù)據(jù)庫的SGA大小12GB如果一個(gè) Oracle Process訪問到了所有的 SGA內(nèi)存，那么其頁表 大小會(huì)是24MB這是一個(gè)驚人的數(shù)字。這里忽略掉PGA因?yàn)槠骄聛砻總€(gè)進(jìn)程的PGA不超過2M,與SGA相比實(shí)在太小。從 AWF報(bào)告來看，有300個(gè)左右的會(huì)話，那么這300個(gè)連接的頁表會(huì)達(dá)到7200MB只不過并不是每個(gè)進(jìn)程都會(huì)訪問到SGA中所有的內(nèi)存。而從meminfo查看到的Page Tables大小達(dá)到4637MB,這么大的Page Table空間，正是 300個(gè)會(huì)話，SGA 大小達(dá)到12GB的結(jié)果。系統(tǒng)中顯然不會(huì)只有 Page Table這唯一的內(nèi)存管理數(shù)據(jù)

30、結(jié)構(gòu)，還有其他一些數(shù)據(jù)結(jié)構(gòu) 用于管理內(nèi)存。這些過大的內(nèi)存管理結(jié)構(gòu)，無疑會(huì)大大增加操作系統(tǒng)內(nèi)核的負(fù)擔(dān)和對(duì)CPU的消耗。而在負(fù)載變化或其他原因?qū)е聝?nèi)存需求大幅變化，比如多進(jìn)程同時(shí)申請(qǐng)大量的內(nèi)存，可能引起CPU在短時(shí)間內(nèi)達(dá)到高峰，從而引起問題。三、使用大內(nèi)存頁來解決問題雖然沒有確實(shí)的證據(jù)，也沒有足夠長的時(shí)間來收集足夠的證據(jù)來證明是過大的PageTable導(dǎo)致了問題，那需要面臨多次半小時(shí)以上的系統(tǒng)不可用故障。但是從目前來看，這是 最大的可疑點(diǎn)。因此，決定先使用大內(nèi)存頁來調(diào)優(yōu)系統(tǒng)的內(nèi)存使用。大內(nèi)存頁是一種統(tǒng)稱，在低版本的Linux中為Large Page，而當(dāng)前主流的Linux版本中為Huge Page

31、。下面以Huge Page為例來說明Huge Page的優(yōu)點(diǎn)及如何使用。使用大內(nèi)存頁有哪些好處：1. 減少頁表(Page Table )大小。每一個(gè) Huge Page，對(duì)應(yīng)的是連續(xù)的 2MB物理內(nèi)存， 這樣12GB的物理內(nèi)存只需要 48KB的Page Table，與原來的24MB相比減少很多。2. Huge Page內(nèi)存只能鎖定在物理內(nèi)存中，不能被交換到交換區(qū)。這樣避免了交換引 起的性能影響。3. 由于頁表數(shù)量的減少，使得CPU中的TLB (可理解為CPU對(duì)頁表的CACHE的命中率大大提高。4. 針對(duì)Huge Page的頁表，在各進(jìn)程之間可以共享，也降低了Page Table的大小。實(shí)際上這

32、里可以反映出Linux在分頁處理機(jī)制上的缺陷。而其他操作系統(tǒng)，比如AIX，對(duì)于共享內(nèi)存段這樣的內(nèi)存，進(jìn)程共享相同的頁表，避免了Linux的這種問題。像筆者維護(hù)的一套系統(tǒng)，連接數(shù)平常都是5000以上，實(shí)例的SGA在 60GB左右，要是按Linux的分頁處理方式，系統(tǒng)中大部分內(nèi)存都會(huì)被頁表給用掉。那么，怎么樣為 Oracle啟用大內(nèi)存頁(Huge Page) ?以下是實(shí)施步驟。由于案例中涉及 的數(shù)據(jù)庫在過一段時(shí)間后將SGA調(diào)整為了 18G,這里就以18G為例：1. 檢查 /proc/memi nfo ，確認(rèn)系統(tǒng)支持 HugePage：HugePages_Total: 0HugePages_Free

33、:0HugePages_Rsvd:0Hugepagesize: 2048 kBHugePages Total表示系統(tǒng)中配置的大內(nèi)存頁頁面數(shù)。HugePages Free表示沒有訪問過的大內(nèi)存頁面數(shù)，這里 free容易引起誤解，這在稍后有所解釋。HugePages Rsvd表示已經(jīng)分配但是還未使用的頁面數(shù)。 Hugepagesize表示大內(nèi)存頁面大小， 這里為2MB注意在有的 內(nèi)核配置中可能為 4MB比如 HugePages總計(jì) 11GB SGA_MAX_SIZ為 10GB SGA_TARGE為 8GB 那么數(shù)據(jù)庫啟 動(dòng)后，會(huì)根據(jù) SGA_MAX_SIZ分配 HugePage內(nèi)存，這里為 10G

34、B,真正Free的HugePage內(nèi) 存為11-10=1G。但是SGA_TARGE只有8GB那么會(huì)有2GB不會(huì)被訪問到，貝U HugePage_Free 為2+1=3GB HugePage_Rsvd內(nèi)存有2GB這里實(shí)際上可以給其他實(shí)例使用的只有1GB也就是真正意義上的 Free只有1GB2. 計(jì)劃要設(shè)置的內(nèi)存頁數(shù)量。到目前為止，大內(nèi)存頁只能用于共享內(nèi)存段等少量類型的內(nèi)存。一旦將物理內(nèi)存用作大內(nèi)存頁，那么這些物理內(nèi)存就不能用作其他用途， 比如作為進(jìn)程的私有內(nèi)存。因此不能將過多的內(nèi)存設(shè)置為大內(nèi)存頁。我們通常將大內(nèi)存頁用作Oracle數(shù)據(jù)庫的SGA那么大內(nèi)存頁數(shù)量：HugePages_Total=c

35、eil(SGA_MAX_SIZE/Hugepagesize)+N比如，為數(shù)據(jù)庫設(shè)置的 SGA_MAX_SIZE為18GB,那么頁面數(shù)可以為 ceil(18*1024/2)+2=9218。這里加上N,是需要將HugePage內(nèi)存空間設(shè)置得比 SGA_MAX_SIZ稍大，通常為1-2即 可。我們通過ipcs -m 命令查看共享內(nèi)存段的大小，可以看到共享內(nèi)存段的大小實(shí)際上比 SGA_MAX_SIZ約大。如果服務(wù)器上有多個(gè)Oracle實(shí)例，需要為每個(gè)實(shí)例考慮共享內(nèi)存段多出的部分，即 N值會(huì)越大。另外，Oracle數(shù)據(jù)庫要么全部使用大內(nèi)存頁，要么完全不使用 大內(nèi)存頁，因此不合適的 HugePages_T

36、otal將造成內(nèi)存的浪費(fèi)。除了使用SGA_MAX_SIZ計(jì)算，也可以通過ipcs -m所獲取的共享內(nèi)存段大小計(jì)算出更 準(zhǔn)確的 HugePages_Total 。HugePages_Total=sum(ceil(share_segment_size/Hugepagesize)3. 修改/etc/sysctl.co nf 文件，增加如下行：vm.nr_hugepages=9218然后執(zhí)行sysctl - p命令，使配置生效。這里vm.nr_hugepages這個(gè)參數(shù)值為第2步計(jì)算出的大內(nèi)存頁數(shù)量。然后檢查/proc/meminfo ，如果HugePages_Total小于設(shè)置的數(shù)量，那么表明沒有足

37、夠的連續(xù)物理內(nèi) 存用于這些大內(nèi)存頁，需要重啟服務(wù)器。4. 在 /etc/security/limits.co nf文件中增加如下行：oracle soft memlock 18878464oracle hard memlock 18878464這里設(shè)定oracle用戶可以鎖定內(nèi)存的大小，以KB為單位。然后重新以oracle用戶連接到數(shù)據(jù)庫服務(wù)器，使用ulimit -a命令，可以看到：max locked memory (kbytes, -l) 18878464這里將memlock配置為unlimited 也可以。5. 如果數(shù)據(jù)庫使用 MANUA方式管理SGA需要改為AUTC方式，即將SGA_T

38、ARGET_SIZE設(shè)置為大于0的值。對(duì)于11g,由于HugePage只能用于共享內(nèi)存，不能用于PGA所以不能使用 AMM即不能設(shè)置 MEMORY_TARG為大于0,只能分別設(shè)置 SGA和PGASGA同樣只能是AUTO方式管理。6.最后啟動(dòng)數(shù)據(jù)庫，檢查 /proc/meminfo 中查看HugePages_Free是否已經(jīng)減少。如果已經(jīng)減少，表明已經(jīng)使用到 HugePage Memory。不過查看出故障數(shù)據(jù)庫服務(wù)器上的/proc/memi nfo 時(shí)發(fā)現(xiàn)，居然沒有 HugePage相關(guān)的信息，sysctl -a查看所有系統(tǒng)參數(shù)也沒有找到vm.nr_hugepages這個(gè)參數(shù)。這是由于Linux

39、內(nèi)核沒有編譯進(jìn)HugePage這個(gè)特性。我們需要使用其他的內(nèi)核來啟用HugePage查看 /boot/grub/grub.c onf:# grub.conf generated by anaconda# Note that you do not have to rerun grub after making changes to this file# NOTICE: You have a /boot partition. This means that# all kernel and initrd paths are relative to /boot/, eg.# root (hd0,0)# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00# initrd /initrd-version.img#boot=/dev/cci