今天檢視生產某個伺服器的負載的時候，發現記憶體的使用情況有些異常。
top - 12:00:08 up 15 days, 12:04, 13 users, load average: 63.31, 55.12, 43.39
Tasks: 5542 total, 21 running, 5511 sleeping, 0 stopped, 10 zombie
Cpu(s): 13.6%us, 3.7%sy, 0.0%ni, 81.1%id, 0.1%wa, 0.3%hi, 1.2%si, 0.0%st
Mem: 363033360k total, 257187848k used, 105845512k free, 1368028k buffers
Swap: 377487328k total, 0k used, 377487328k free, 167742788k cached

這個引數在前幾天可是200多G,那100多G到哪去了呢？
使用ipcs來檢視共享段的情況，沒有發現異常的情況。
> ipcs -a
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 500105218 root 644 80 2
0x00000000 500137988 root 644 16384 2
0x00000000 500170757 root 644 280 2
0x550002fb 500203526 root 644 256064 1 locked
0xba17ff18 500760585 xxxxx 660 35704012800 3963
0xd9152b54 500695050 xxxxx 660 3542089728 37
0x91442618 500826123 xxxx 660 4096 0
0xdb22d1bc 500957196 xxxxxx 660 3340763136 32
使用free -m來檢視剩餘內容情況，剩餘268913M的內容，這個和期望的結果還是一致的。
total used free shared buffers cached
Mem: 354524 250998 103526 0 1336 164050
-/+ buffers/cache: 85611 268913
Swap: 368639 0 368639

關於top和free的命令解釋，我覺得http://blog.itpub.net/34596/viewspace-588857/這個帖子解釋得很好，

free命令顯示在作業系統中使用和空閒的記憶體數量。

Top 顯示是和Linux 對記憶體使用的方式關係緊密，linux 儘可能的要求

使用實體記憶體來提高Buffer 和Cache 對Disk 的I/O操作。Linux 將盡可能多的將I/O 操作磁碟上的資訊儲存在記憶體當中，如果Oracle（其他程式也一樣）需要更多的記憶體空間，Linux 才會將一些記憶體使用LRU 演算法清理出來，如果不需要則繼續保持這些資料資訊在記憶體中。

儘管從這個解釋來看，不是問題，從vmstat來看也沒有發現swap的異常。總算鬆了口氣，但是還是希望能夠查出倒底那100多G的空間都消耗到哪了。
> vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
49 1 0 105913072 1368380 167977888 0 0 1330 81 0 0 10 3 87 0 0
525 1 0 105816848 1368380 167978320 0 0 138008 10340 40898 90606 17 6 77 0 0
22 0 0 105814304 1368380 167978544 0 0 225004 6875 37504 78706 12 5 83 0 0
8 0 0 105782352 1368380 167978672 0 0 112008 12034 39147 86160 13 4 83 0 0
11 0 0 105787408 1368380 167978896 0 0 237008 6868 38895 84063 13 4 83 0 0

這個時候還是使用top命令直接使用shift+M能夠檢視出使用記憶體的程式情況。
top - 13:05:54 up 15 days, 13:10, 12 users, load average: 45.59, 48.43, 49.50
Tasks: 5451 total, 5 running, 5436 sleeping, 0 stopped, 10 zombie
Cpu(s): 7.8%us, 2.7%sy, 0.0%ni, 88.3%id, 0.1%wa, 0.1%hi, 0.9%si, 0.0%st
Mem: 363033360k total, 256454800k used, 106578560k free, 1368868k buffers
Swap: 377487328k total, 0k used, 377487328k free, 167948244k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16422 oraaems2 15 0 6399m 5.3g 5.3g S 0.0 1.5 4:16.15 ora_dbw1_AEM02
16426 oraaems2 15 0 6399m 5.3g 5.2g S 0.0 1.5 4:08.93 ora_dbw3_AEM02
16424 oraaems2 15 0 6399m 5.2g 5.2g S 0.0 1.5 4:09.52 ora_dbw2_AEM02
16419 oraaems2 15 0 6399m 5.2g 5.2g S 0.0 1.5 4:06.01 ora_dbw0_AEM02
26885 oraaems2 15 0 6394m 3.9g 3.9g S 0.0 1.1 7:01.84 oracleAEM02 (LOCAL=NO)
9779 oraaems2 16 0 6392m 3.8g 3.8g S 0.0 1.1 3:36.58 oracleAEM02 (LOCAL=NO)
26535 oraaems2 15 0 6394m 3.5g 3.5g S 0.0 1.0 7:26.10 oracleAEM02 (LOCAL=NO)
5825 oraaems2 15 0 6394m 3.5g 3.5g S 0.0 1.0 4:29.41 oracleAEM02 (LOCAL=NO)
26932 oraaems2 15 0 6394m 3.4g 3.4g S 0.0 1.0 5:46.79 oracleAEM02 (LOCAL=NO)
5882 oraaems2 15 0 6394m 3.4g 3.4g S 0.0 1.0 3:55.93 oracleAEM02 (LOCAL=NO)
26479 oraaems2 15 0 6394m 3.4g 3.4g S 0.0 1.0 6:43.21 oracleAEM02 (LOCAL=NO)
25670 oraaems2 15 0 6394m 3.3g 3.3g S 0.0 1.0 6:00.96 oracleAEM02 (LOCAL=NO)
28928 oraaems2 15 0 6394m 3.3g 3.3g S 0.0 0.9 3:05.69 oracleAEM02 (LOCAL=NO)
5792 oraaems2 15 0 6394m 3.1g 3.1g S 0.0 0.9 4:42.41 oracleAEM02 (LOCAL=NO)
29874 oraaems2 15 0 6394m 2.9g 2.9g S 0.0 0.8 2:20.13 oracleAEM02 (LOCAL=NO)
1964 oraaems2 15 0 6398m 2.8g 2.8g S 0.0 0.8 1:16.83 oracleAEM02 (LOCAL=NO)
1954 oraaems2 15 0 6394m 2.7g 2.7g S 0.0 0.8 0:54.40 oracleAEM02 (LOCAL=NO)
5788 oraaems2 15 0 6394m 2.6g 2.6g S 0.0 0.8 3:26.67 oracleAEM02 (LOCAL=NO)
1970 oraaems2 15 0 6394m 2.5g 2.5g S 0.0 0.7 0:37.69 oracleAEM02 (LOCAL=NO)
16435 oraaems2 15 0 6393m 1.9g 1.9g S 0.0 0.6 1:29.38 ora_smon_AEM02
5816 oraaems2 15 0 6394m 1.9g 1.8g S 0.0 0.5 2:35.20 oracleAEM02 (LOCAL=NO)
24344 oraaems2 15 0 6389m 1.6g 1.6g S 0.0 0.5 0:03.12 oracleAEM02 (LOCAL=NO)
5790 oraaems2 16 0 6394m 1.3g 1.3g S 0.0 0.4 0:47.47 oracleAEM02 (LOCAL=NO)
16417 oraaems2 15 0 6386m 1.2g 1.2g S 0.0 0.4 0:21.68 ora_mman_AEM02
24323 oraaems2 15 0 6389m 1.2g 1.2g S 0.0 0.3 2:02.72 oracleAEM02 (LOCAL=NO)
1962 oraaems2 15 0 6394m 1.2g 1.2g S 0.0 0.3 0:41.28 oracleAEM02 (LOCAL=NO)
1958 oraaems2 15 0 6394m 1.1g 1.1g S 0.0 0.3 0:39.05 oracleAEM02 (LOCAL=NO)
22982 oraaems2 15 0 6393m 814m 807m S 0.0 0.2 2:24.63 ora_cjq0_AEM02
18024 oraaems2 15 0 6393m 599m 592m S 0.9 0.2 74:31.45 oracleAEM02 (LOCAL=NO)

能夠看到程式的記憶體消耗都集中在AEM02這個庫上，這個庫其實是一個很小的庫，SGA的設定只有6G，怎麼記憶體消耗這麼大呢。
首先檢視資料庫日誌，沒有相關的警告和錯誤。從啟動開始，負載都很小。發現了一句比較奇怪的日誌，但是hugapage的部分沒有報錯。
Starting ORACLE instance (normal)
****************** Huge Pages Information *****************
Huge Pages memory pool detected (total: 30000 free: 16509)
DFLT Huge Pages allocation successful (allocated: 0)
***********************************************************
然後檢視了下sga的設定。發現sga_target設定為了0，同時shared_pool_size,db_cache_size也都是0，這個從配置來說也確實是個問題。
因為負載很小，就線上做了修改，觀察了一下資料庫的記憶體使用情況，還是沒有任何的改變。
排除了shared_pool_size和db_cache_size的影響，注意力都集中在了啟動日誌的那句話上"DFLT Huge Pages allocation successful (allocated: 0)"

為什麼hugepage可用，但是沒有分配呢。檢視其它的例項啟動情況都使用到了hugepage。
最後能夠想到的只能是11g中的新引數memory_target了。
一檢視發現還真是，memory自動管理啟動之後，hugep page就不會啟用了，這也就是為什麼日誌中huge page allocation 為0的原因了。

SQL> show parameter memory
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
hi_shared_memory_address integer 0
memory_max_target big integer 16016M
memory_target big integer 16016M
shared_memory_address integer 0

但是這個和那100G的記憶體關係大嗎，我使用top 把AEM02記憶體使用第一頁的程式情況作了統計，發現已經佔用了85G的記憶體資源，基本能夠說明問題了。
明白了這一點再來看ipcs的結果就能夠理解一些資料的意義了。
> ipcs -a
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 500105218 root 644 80 2
0x00000000 500137988 root 644 16384 2
0x00000000 500170757 root 644 280 2
0x550002fb 500203526 root 644 256064 1 locked
0xba17ff18 500760585 xxxxx 660 35704012800 3963
0xd9152b54 500695050 xxxxx 660 3542089728 37
0x91442618 500826123 aems2 660 4096 0
0xdb22d1bc 500957196 xxxxxx 660 3340763136 32

但是memory_target的修改和引數memory_max_target是關聯的，無法線上修改，而且在生產中也不適宜做這樣大膽的嘗試，所以以上的分析只能說是一個猜想，只能靜靜等待下一次例項重啟的機會來驗證這個判斷了。

關於記憶體異常的一個猜想

相關文章