環境：SLES11 SP4 + oracle 11.2.0.4

新搭建測試資料庫，跑了兩天左右發現一個名為kswapd0的程式竟然佔用了1個cpu資源(該主機一共只有2個cpu)，而且幾乎都耗在cpusys上。
如下圖所示：
圖1

網上搜尋得知kswapd0是一個核心程式，用來處理頁的交換，當OS的可用記憶體小於閥值時，kswapd會將部分程式的頁從實體記憶體交換到swap上，這個閥值如何確定，頗費周折的找尋了一番仍然沒有結果，至少在SLES 11這個版本下打消了我透過修改閥值來阻止kswapd0程式過渡活躍地消耗cpusys的解決思路。

從資料庫層面入手，首先檢查SGA是否被lock在了記憶體裡
SQL> show parameter lock_sga

NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
lock_sga boolean TRUE
SQL>

OS層面再double check一下，確實lock住了
oracle@cspdb1:~> ipcs -m

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 196611 oracle 640 16777216 29 locked <--確實lock住了
0x00000000 229380 oracle 640 1560281088 29 locked
0xf8e2566c 262149 oracle 640 2097152 29 locked

OS層面檢查實體記憶體尚有空閒，而真正的swap動作發生的次數並不多，不然應用早就來投訴了

圖4

圖5

從上述檢查結果我們初步可以判斷: 資料庫的SGA確被鎖定在了實體記憶體裡，kswapd0雖然辛勤勞作(佔去了一個cpu資源)但產出卻很少(被swap出來的頁很少)

該伺服器上除了oracle db外，並沒有其它應用，db上的會話數也只有幾十個，因此最大的記憶體空間還是SGA，想起之前曾經在AIX上啟用過大記憶體頁，最大的好處當然是提供更大size的連續頁塊，減少頁表在記憶體裡的佔用空間，加快頁表的搜尋速度，還有一個好處就是大記憶體頁永遠不會被swap out

為排除SGA可能會被換出實體記憶體或者至少避免kswapd0程式對SGA區域進行的無謂掃描來檢測是否有能被swap out的頁，我們按照如下步驟啟用大記憶體頁

###1、設定/etc/security/limits.conf以及設定後的檢查
* soft memlock unlimited
* hard memlock unlimited

---以oracle登入主機執行檢查上述設定是否生效
oracle@cspdb1:~> ulimit -Hl
unlimited
oracle@cspdb1:~> ulimit -Sl
unlimited

###2、確認沒有啟用AMM，因為AMM和lock_sga不相容
set linesize 100
col name format a30
col value format a30
select name,value from v$system_parameter where name in ('memory_target','memory_max_target','lock_sga');

NAME VALUE
------------------------------ ------------------------------
lock_sga TRUE
memory_target 0
memory_max_target 0

---如果AMM引數或者lock_sga設定不符合要求，可以按照如下步驟重設
SQL> alter system reset memory_max_target;

SQL> alter system reset memory_target;

SQL> alter system set lock_sga=true scope=spfile;

###3、設定大記憶體頁
---計算大記憶體頁的數量，注意執行這一步的時候必須保證例項至少啟動到nomount狀態
oracle@cspdb1:~> ipcs -m

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 196611 oracle 640 16777216 29 locked
0x00000000 229380 oracle 640 1560281088 29 locked
0xf8e2566c 262149 oracle 640 2097152 29 locked

oracle@cspdb1:~> cat /proc/meminfo | grep Hugepagesize
Hugepagesize: 2048 kB

最終需要的hugepages=(16777216/2048/1024+1)+(1560281088/2048/1024+1)+(2097152/2048/1024+1)=756

---在/etc/sysctl.conf里加入
vm.nr_hugepages=756

###4、重啟資料庫例項與主機，檢查大記憶體頁設定是否生效
sqlplus '/as sysdba'
shutdown immediate

init 6

cspdb1:~ # sysctl -n vm.nr_hugepages
756

oracle@cspdb1:~> grep HugePages /proc/meminfo
AnonHugePages: 45056 kB
HugePages_Total: 756
HugePages_Free: 756
HugePages_Rsvd: 0
HugePages_Surp: 0

startup

oracle@cspdb1:~> ipcs -m

------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 196611 oracle 640 16777216 27 <---狀態從locked變為空值了，說明大頁天生不會被swapout，所以不care lock_sga的設定:)
0x00000000 229380 oracle 640 1560281088 27
0xf8e2566c 262149 oracle 640 2097152 27

cspdb1:~ # grep HugePages /proc/meminfo
AnonHugePages: 67584 kB
HugePages_Total: 756
HugePages_Free: 623 <---Free < Total，說明已經有huge page被使用了
HugePages_Rsvd: 620
HugePages_Surp: 0

過去一週了kswapd0程式沒有再冒泡上來，詳見下圖
圖6

以下是我對這個現象原因的猜測：當SGA以普通頁的形式存在於記憶體中的時候，雖然lock_sga=TRUE，但仍然無法阻止kswapd0程式對於sga記憶體區域的不斷掃描當然結果是不會有page會被swap out，因為lock_sga=TRUE。但這一過程中存在較多的核心級呼叫所以kswapd0程式會佔用大量的cpusys資源。所以徹底的方法就是啟用大記憶體頁。

linux上設定大記憶體頁解決kswapd0程式過渡消耗cpusys的問題

相關文章