memlock過低導致的資料庫效能問題

今天在一臺備庫機器上準備搭建active data guard ，在主庫上做配置的時候，發現主庫的反應有些慢，主要的感覺就是敲命令的時候似乎都有些停頓。
帶著疑問檢視了下資料庫的負載情況，發現連進來的使用者很少，資料庫負載也很低，歸檔每天切換不到20次
但是使用top命令檢視的時候還是能夠看到kswapd1的身影，這個程式是一個效能出現問題的標誌，因為在之前的一個專案中因為配置hugepage出現問題，結果導致系統出現了嚴重的swap現象，當時的top 程式就是kswapd這樣的程式。
我按照top程式的時間簡單檢視了下。
Tasks: 289 total,   1 running, 282 sleeping,   0 stopped,   6 zombie
Cpu(s):  7.7%us,  7.7%sy,  0.0%ni, 84.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  65996212k total, 65804840k used,   191372k free,     2768k buffers
Swap: 16771776k total,  5473276k used, 11298500k free, 13392336k cached
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 
  827 root      10  -5     0    0    0 S  0.0  0.0 393:54.67 [kswapd1]
 6176 oracle    18   0 18.2g  52m  48m S  0.0  0.1 313:30.37 ora_dia0_xxxx
  826 root      10  -5     0    0    0 S  0.0  0.0 262:21.47 [kswapd0]   
 6190 oracle    16   0 18.2g 462m 459m S  0.0  0.7 198:13.92 ora_mmon_xxxx
 3654 root      34  19     0    0    0 S  0.0  0.0  67:30.61 [kipmi0]   
 6180 oracle    16   0 18.3g  11g  11g S  0.0 17.7  43:07.78 ora_dbw0_xxxx
 6192 oracle    15   0 18.2g 104m 102m S  0.0  0.2  42:29.52 ora_mmnl_xxxx
 6184 oracle    16   0 18.2g 613m 613m S  0.0  1.0  30:04.32 ora_ckpt_xxxx   
 6182 oracle    16   0 18.2g  75m  75m S  0.0  0.1  23:53.08 ora_lgwr_xxxx 
 6186 oracle    15   0 18.2g 855m 853m S  0.0  1.3  13:33.32 ora_smon_xxxx
 6162 oracle    15   0 18.2g  29m  28m S  0.0  0.0   8:08.11 ora_pmon_xxxx    
 2773 root      10  -5     0    0    0 S  0.0  0.0   5:43.35 [kjournald]                                               
 6354 oracle    15   0 18.2g 358m 352m S  0.0  0.6   4:01.47 ora_cjq0_xxxx
 3473 root      11  -4 92888  780  556 S  0.0  0.0   2:42.97 auditd      
 6302 oracle    15   0 18.3g  42m  22m S  0.0  0.1   2:08.43 ora_arcf_xxxx 
 6276 oracle    15   0 18.3g  42m  22m S  0.0  0.1   2:08.10 ora_arc4_xxxx
 6318 oracle    15   0 18.3g  42m  22m S  0.0  0.1   2:06.25 ora_arcn_xxxx
 6290 oracle    15   0 18.3g  42m  22m S  0.0  0.1   2:05.30 ora_arca_xxxx
 6274 oracle    15   0 18.3g  42m  22m S  0.0  0.1   2:04.12 ora_arc3_xxxx
 6304 oracle    15   0 18.3g  42m  22m S  0.0  0.1   2:03.83 ora_arcg_xxxx
 6286 oracle    15   0 18.3g  42m  22m S  0.0  0.1   2:02.99 ora_arc9_xxxx
 6326 oracle    15   0 18.3g  42m  22m S  0.0  0.1   2:02.70 ora_arcp_xxxx
 6330 oracle    15   0 18.3g  42m  22m S  0.0  0.1   2:02.26 ora_arcq_xxxx
 6278 oracle    15   0 18.3g  42m  22m S  0.0  0.1   2:02.00 ora_arc5_xxxx
對於一個記憶體有60多G的系統來說，只有一個資料庫例項，而且例項的sga大小可以看出來大概在18G左右，反應有些慢確實有些不合理。
不過直接來看，發現這裡面有一個問題比較明顯就是存在很多的歸檔程式 arc這樣的程式，一般的系統中就2~4個左右，這個似乎有些多了。
自己也暗自慶幸，好像發現問題的原因了。帶著疑問檢視了資料庫的歸檔配置引數LOG_ARCHIVE_MAX_PROCESSES竟然是30，從官方文件來看，就是最高值了。
簡單確認之後就開始修改這個引數，從30改到了4個。
從top命令的情況來看，似乎swap有了一些改進，也確實騰出了一些記憶體空間
top - 17:12:45 up 81 days, 21:08,  3 users,  load average: 0.09, 0.39, 0.49
Tasks: 287 total,   1 running, 280 sleeping,   0 stopped,   6 zombie
Cpu(s):  0.1%us,  0.1%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  65996212k total, 65803376k used,   192836k free,     4588k buffers
Swap: 16771776k total,  5470956k used, 11300820k free, 13424524k cached

top - 17:17:39 up 81 days, 21:13,  3 users,  load average: 0.01, 0.17, 0.36
Tasks: 261 total,   1 running, 254 sleeping,   0 stopped,   6 zombie
Cpu(s):  0.1%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  65996212k total, 65271068k used,   725144k free,     5768k buffers
Swap: 16771776k total,  4940324k used, 11831452k free, 13427832k cached

但是swap還是比較高，對於這樣一個配置還不錯的系統，swap應該很低，接近於0.
帶著疑問開始嘗試使用addm來分析指定時間段的資料庫情況，但是從報告來看得到的資訊還是比較少，報告中說系統有大量的paging現象，但是原因不明，建議調大記憶體，調記憶體在這個問題裡面
還是站不住腳的。對於報告中的sql語句，也是相對的，因為這個庫的使用人數極少，執行的sql語句也不多。sql帶來的影響非常有限。

這個時候資料庫日誌是一個很好的參考，因為從v$database可以看出資料庫是在5月份重啟的，所以就檢視當時啟動以來的一些日誌，所幸的是一查就有了一些收穫。
在啟動的時候還是丟擲了一些警告。
而且從警告資訊來看，應該是核心引數出了問題。
Starting ORACLE instance (normal)
Memlock limit too small: 32768 to accommodate segment size: 4194304
Memlock limit too small: 32768 to accommodate segment size: 44040192
Memlock limit too small: 32768 to accommodate segment size: 44040192
Memlock limit too small: 32768 to accommodate segment size: 46137344
Memlock limit too small: 32768 to accommodate segment size: 67108864
Memlock limit too small: 32768 to accommodate segment size: 67108864
。。。。。
****************** Large Pages Information ***************** 
Total Shared Global Region in Large Pages = 0 KB (0%)
Large Pages used by this instance: 0 (0 KB)
Large Pages unused system wide = 24576 (48 GB) (alloc incr 64 MB)
Large Pages configured system wide = 24576 (48 GB)
Large Page size = 2048 KB
RECOMMENDATION:
  Total Shared Global Region size is 18 GB. For optimal performance,
  prior to the next instance restart increase the number
  of unused Large Pages by atleast 0 2048 KB Large Pages (0 KB)
  system wide to get 100% of the Shared
  Global Region allocated with Large pages

這個庫沒有配置huge page，large_page也沒有配置，至少沒有生效。
metalink中的文章1511239.1也給出了比較詳細的解釋，就是memlock的配置問題。
使用ulimit 來檢視。
$ ulimit -l
32
這個和警告資訊是一致的。
而從oracle的解釋和建議來看，這個值還是應該比記憶體配置略小，也就是要配置的足夠大。
可以在/etc/security/limits.conf  修改memlock的值。比如64G的記憶體，就可以這麼配置
*   soft   memlock    60397977
*   hard   memlock    60397977

然後重新登入即可。這樣就需要重啟資料庫例項，需要和開發進行協調來完成了，期待看到極大的效能改進。