環境描述：

SYSTEM: rhe5.3 x86_64bit

ORACLE:ORACLE 11.1.7.0

內存：8G

現像：

現場運維發郵件回來前端應用緩慢，不時會拋出異常！

分析：

通過查看服務器進程使用情況發現一些進程使用內存相當高，通過vmstat 查詢，系統層面已經大量使用Swap交換分區了。說明內存使用不足，系統層面反應也是比較緩慢

vmstat情況：

但查看Oracle進程查詢沒發現有消耗性能的SQL,

調整：

1：服務器內存：

2：調整/dev/shm

3：調整內核參數

4：調整數據庫參數

5：監控DB情況

先為兩臺服務器增加16G內存，輪流重啟服務器，完成內存增加后，修改SGA,hugepage size hugepage_setting.sh查詢出vm.nr_hugepages = 6146

節點正常，但節點2不正常，和未增加內存前一樣，Swap交換分區被大量使用。

解決：

通過分析及查詢資料發現hugepage 沒被使用

進一步分析 ：還是與hugepage設置及系統參數有關：

HugePages配置

進程需要訪問內存的數據時，它的虛擬內存地址段先連接到page?tables(Page?Table是用來存放虛擬內存也和物理內存頁對應關系的內存結構)，然后再連接到物理內存。所以在訪問內存時需要先訪問page?tables得到虛擬內存和物理內存的映射關系，然后再訪問物理內存。page?size越小，相應的內存結構也會越大，在RHEL?系統中，缺省為4k為一個單位，則物理內存越大，page?tables相對越大。無形增加進程掃描內存的成本。

當物理內存大于8G時，建議使用hugepages配置，Hugepages的常見page?size為2M，是4k?size的500倍，所以可以大大減小page?table的尺寸，提交掃描內存的效率。

同時CPU?cache中有一部分TLB(Translation?Lookaside?Buffer)用來存放部分page?table以提高這種裝換的速度。因為page?size變大了，所以同樣大小的TLB，所覆蓋的內存大小也變大了。提高了TBL命中率，也就是提高了地址轉換的速度。

HugePages配置方法：

1、在?/etc/security/limits.conf?增加memlock配置

*?hard?memlock?unlimited

*?soft?memlock?unlimited

2、利用官方的提供的腳本hugepages_settings.sh[ID?401749.1]，計算需要配置的內存參數

$?./hugepages_settings.sh

......

Press?Enter?to?proceed...

Recommended?setting:?vm.nr_hugepages?=?6146

3、修改/etc/sysctl.conf?的項vm.nr_hugepages=6146

sysctl?-p;

sysctl?-a|grep?-i?huge

4、關閉實例及群集，重啟系統。

5、對hugepages配置進行檢查：

$?grep?-i?huge?/proc/meminfo

HugePages_Total:??6146

HugePages_Free:?????15

Hugepagesize:?????2048?kB

6、啟動實例及數據庫群集。

參考：

HugePages?on?Oracle?Linux?64-bit?[ID?361468.1]

Shell?Script?to?Calculate?Values?Recommended?Linux?HugePages?/?HugeTLB?Configuration?[ID?401749.1]

問題解決

總結

以上是生活随笔為你收集整理的oracle swap忽略可以吗,Oracle Swap居高不下处理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。