hugepages使用出現kswapd導致系統負載突然上升

在運行Oracle 資料庫的linux 伺服器上，某個時間段的每分鐘負載會突然上升到40 以上，在進程隊列裡看到kswapd0 出現，導致資料庫無響應，期間數分鐘。
對於應用而言，這個時間段有明顯的停滯感，像系統已經掛掉了一樣。
如果這是發生在Oracle RAC 環境中某一個節點上，那麼這個節點就可能會重啟。
這屬於非常嚴重和致命的問題。

1.  問題
環境是這樣，資料庫伺服器的記憶體96GB ，作業系統linux RedHat 5 ，採用hugepages 管理部分記憶體，運行一個資料庫執行個體，資料庫系統版本為10.2.0.4 。
資料庫執行個體中sga_max_size 的值為48GB, pga_aggregate_target 的值為24GB 。
還有個執行個體為ASM ，用於儲存資料庫的資料檔案等。
效能搖擺期間的top 顯示的結果如下：
 
top - 13:21:11 up 49 days, 21:52,   4 users,   load average: 42.76, 14.42, 6.12
Tasks: 471 total,   26 running, 444 sleeping,    0 stopped,    1 zombie
Cpu(s): 87.2%us, 12.2%sy,   0.0%ni,   0.1%id,   0.1%wa,   0.1%hi,   0.2%si,   0.0%st
Mem:   98989932k total, 98152840k used,    837092k free,      2056k buffers
Swap: 50331636k total, 12554316k used, 37777320k free, 37715224k cached
 
   PID USER       PR   NI   VIRT   RES   SHR S %CPU %MEM     TIME+   COMMAND
 1057 root       20   -5      0     0     0 R 100.2   0.0 991:39.65 [kswapd0]
 
zzz ***Fri Jun 29 13:21:35 CST 2012
 
top - 13:21:39 up 49 days, 21:52,   4 users,   load average: 28.99, 13.85, 6.19
Tasks: 471 total,    2 running, 468 sleeping,    0 stopped,    1 zombie
Cpu(s):   0.2%us,   8.4%sy,   0.0%ni, 91.3%id,   0.1%wa,   0.0%hi,   0.0%si,   0.0%st
Mem:   98989932k total, 98104680k used,    885252k free,      3028k buffers
Swap: 50331636k total, 12801004k used, 37530632k free, 37606456k cached
 
   PID USER       PR   NI   VIRT   RES   SHR S %CPU %MEM     TIME+   COMMAND
 1057 root       20   -5      0     0     0 R 100.3   0.0 992:07.44 [ kswapd0 ]
12530 root       15    0 13032 1400   812 R   0.7   0.0    0:00.03 top -b -c -n 2
 1376 root       10   -5      0     0     0 S   0.3   0.0   22:00.23 [scsi_eh_1]
 
可以明顯看到伺服器的一分鐘負載上升的很厲害，都到42 了，而正常才4 左右。在啟動並執行進程隊列中，看到 kswapd0 。
作業系統每過一定時間就會喚醒kswapd ，看看記憶體是否緊張，如果不緊張，則睡眠，在 kswapd 中，有2 個閥值, pages_hige和pages_low,當空閑記憶體頁的數量低於 pages_low 的時候, kswapd進程就會掃描記憶體並且每次釋放出32 個free pages,直到 free page 的數量到達pages_high.
 
通過檢查vmstat 的輸出結果，發現在那個時間段內，系統的頁面換入換成現象很嚴重。
zzz ***Fri Jun 29 13:22:05 CST 2012
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r   b    swpd    free    buff   cache    si    so     bi     bo    in    cs us sy id wa st
 7   0 13022188 919216    3064 37429916    27    17    203    559     0     0   3   1 95   1   0
 4   0 13040224 914712    3116 37411924   680 2196   1450   2844 1387 1654 13 10 77   0   0
 2   0 13058536 919060    3216 37395064   104 1444   1118   1492 1235   839 16   9 75   0   0
zzz ***Fri Jun 29 13:22:35 CST 2012
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r   b    swpd    free    buff   cache    si    so     bi     bo    in    cs us sy id wa st
 9   0 13573224 912300    3356 36885376    27    17    203    559     0     0   3   1 95   1   0
 8   0 13573088 913408    3368 36885224   276     0   3740   5643 1643 7707 31   9 60   0   0
 1   0 13572892 913300    3368 36885920   252     0    374   3955 2209 9632 14   9 77   0   0
 
就是說，問題是記憶體緊張了，導致了交換分區頻繁使用到。kswapd0 進程需要換入換出虛擬記憶體磁碟空間，導致了系統出現短時間搖擺。
作業系統的實體記憶體有25576 個page 沒有被使用，所以肯定會有kswap 進程執行虛擬記憶體換頁操作。
 
2.  分析
問題既然發生在記憶體使用量上，但我們的伺服器實體記憶體配置是96GB ，資料庫執行個體的記憶體配置也是合理的。
但在vmstat 確實有交換分區的換頁情況發生。
我們需要分析的是，這96GB 的記憶體都是如何使用的呢？
在環境介紹中，我們介紹了使用大記憶體管理員模式管理記憶體的。因此，我們首先查詢系統記憶體資訊中關於大記憶體的使用方式。
[root@db3 ~]# cat /proc/meminfo |grep -i huge
HugePages_Total: 25576
HugePages_Free:   25517
HugePages_Rsvd:       4
Hugepagesize:      2048 kB
 
哇，看到結果大吃一驚。大記憶體有25517 個頁面沒有使用，一個頁面大小是2MB ，也就是說有51034MB 記憶體被大記憶體管理機制限制了，屬於空閑狀態，而系統上其他進程也無法使用到。只有59 個頁面合計118MB 的記憶體使用量到了。
（注，為什麼新進程如何使用到該記憶體地區，而是使用虛擬記憶體空間呢？這是一個疑問。可能是新資料庫執行個體的SGA 已經使用了剩餘的48 記憶體，還不夠用，所以用到虛擬記憶體。）
 
在系統配置中，hugepages 的大小設定為25576 ，計48GB 記憶體，是實體記憶體的一半。
[root@db3 ~]# sysctl -p
vm.nr_hugepages = 25576
 
使用ipcs –m 看到oracle 使用者下使用的共用記憶體段如下所示：
------ Shared Memory Segments --------
key         shmid       owner       perms       bytes       nattch      status      
0xb0af65c0 3047451     oracle     600         132120576   13                      
0x4507bd98 3702814     oracle     640         51541704704 132  
最大的51541704704 位元組，計49154MB 。這個SGA 中所有 'shared_pool_size' , 'large_pool_size' , 'java_pool_size' , 'streams_pool_size' , 'db_cache_size' 大小之和。
Oracle 使用者的共用記憶體段完全沒有使用到hugepages 。
 
再檢查系統日誌，發現之前有一個oracle 的執行個體使用到該hugepages ，而現在的執行個體是後來啟動的，所以使用到另外的記憶體。
後來前一個執行個體關閉了，但hugepages 中的記憶體空間卻一直空閑下來，新的執行個體也不能使用到這個記憶體空間。
 
3.  解決
問題分析到這裡，其實已經有解決方案了。
我們重啟了一下資料庫執行個體，就可以使用該hugepages 記憶體空間。
如果執行個體不能重啟，我們也可以通過設定nr_hugepages 的值降低設定。但這隻是個人建議，不排除有新的問題出現。
 
4.  技術hugepages
如果需要增大hugepages 大小，需要重啟作業系統。
如果您認為這就是一個記憶體參數值，可以使用sysctl –w 修改的。這點是不正確的。這裡涉及到記憶體管理方面，hugepages 需要大量連續的記憶體地區，否則嚴重的記憶體片段會影響到系統的效能。 
 
linux 的hugepages 技術隨著近年大記憶體伺服器陸續上市，逐步推廣使用，因此關於hugepages 的問題也隨著而來。
本文是在hugepages 使用中遇到的問題的解決分析總結。