大並發連接的oracle在Linux下內存不足的問題的分析（轉）

最近一台裝有Rhel5.3的40G內存的機器上有一個oracle數據庫，數據庫的SGA設置為20G，當運行業務時，一個業務高峰期時，發現swap頻繁交換，CPU 100%，Load很高，基本體現為內存不足。此時的連接數在600個左右。按內存的計算：每個連接占用內存基本在5M，這樣600個連接只占用3G內存，SGA內存20G，操作系統占用內存1G，這樣總占用的內存為24G，而總共內存有40G，怎么會內存不足呢？當時是百思不得其解，於是做了大量的壓力測試，首先是寫了一個java程序，啟動多個線程，每個線程與數據庫建一個連接，然后循環運行一個簡單的SQL，這個SQL按一個隨機函數生成的ID去查詢一個很大的表（有索引）。當啟動1000個連接后，使用free -m查看內存：

 

#free -m
             total       used       free     shared    buffers     cached
Mem:         40210      25842      14368          0          9        177
-/+ buffers/cache:       25655      14554
Swap:        20481        479      20001

 

發現free的內存值很小，used的內存值為斷增長，運行大約20分鍾后，當free減少到40M左右的時候， 系統的CPU一下子到100%，Load從15升到600。

從這個結果看到，還是內存不足，當時還寫了一個腳本，查看所有oracle進程的內存情況，也沒有發現oracle進程占用內存太多。所以一直沒有找到原因。

 

最后試着用cat /proc/meminfo查看內存時，終於找到了原因，沒有加壓力時，cat /proc/meminfo看到的結果為：

root@xxxx:/proc/sys/vm>cat /proc/meminfo
MemTotal:     41175744 kB
MemFree:      27603324 kB
Buffers:         36572 kB
Cached:       13006240 kB
SwapCached:     232980 kB
Active:         304448 kB
Inactive:     12990616 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:     41175744 kB
LowFree:      27603324 kB
SwapTotal:    20972816 kB
SwapFree:     20070348 kB
Dirty:            1232 kB
Writeback:           0 kB
AnonPages:      240500 kB
Mapped:         354120 kB
Slab:           136980 kB
PageTables:      34004 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:  41560688 kB
Committed_AS: 17163928 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    273756 kB
VmallocChunk: 34359464051 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

 

當壓力上來時：

root@bopspri:/proc/sys/vm>cat /proc/meminfo
MemTotal:     41175744 kB
MemFree:        375212 kB
Buffers:         36444 kB
Cached:       13005200 kB
SwapCached:     232984 kB
Active:       16919192 kB
Inactive:       509908 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:     41175744 kB
LowFree:        375212 kB
SwapTotal:    20972816 kB
SwapFree:     20070340 kB
Dirty:             184 kB
Writeback:           0 kB
AnonPages:     4375088 kB
Mapped:       12889760 kB
Slab:           168916 kB
PageTables:   23005464 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
CommitLimit:  41560688 kB
Committed_AS: 40413008 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    273756 kB
VmallocChunk: 34359464051 kB
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     2048 kB

 

可以看到壓力上來后，PageTables占用的內存居然高達23G。PageTables是Linux下虛擬內存到物理內存中做映射時映射表占用的空間，這個映射表居然占用了這么大的內存，真讓人不可思議。

 

為了解決這個問題，想到了Linux的大頁管理，正常的頁大小為4k，而大頁管理的頁大小為2M，通過大頁管理后，映射表占用的空間將會大大減少。

 

於是把數據庫停了,啟動大頁管理，給大頁管理分配20G內存：

echo 10240 > /proc/sys/vm/nr_hugepages

 

增加

root                soft    memlock -1 
root                hard    memlock -1

oracle              soft    memlock -1 
oracle              hard    memlock -1

 

把數據庫的lock_sga改成true后，再做壓力測試，系統終於能穩定運行了，free -m查看到的空閑內存一直空閑13G：

root@xxxx:/etc/security>free -m
             total       used       free     shared    buffers     cached
Mem:         40210      26234       13976          0         20        184
-/+ buffers/cache:      26029      14181
Swap:        20481        479      20001

 

http://www.cnblogs.com/woxing/p/3854178.html