[20220909]AnonHugePages與transparent hugepage 3.txt

[20220909]AnonHugePages與transparent hugepage 3.txt

--//前一段時間生產系統exadata做了升級,更換了新核心.記憶體從384G-> 512G,CPU的主頻也做了升級，並且CPU數量從24->32.
--//當時的情況實際上exadata的linux核心配置CONFIG_TRANSPARENT_HUGEPAGE is not set.
--//以前的測試連結如下:
--//http://blog.itpub.net/267265/viewspace-2770237/=>[20210428]AnonHugePages與transparent hugepage.txt
--//當時的測試摘要如下(exadata沒有升級前的情況):
#  grep -i page /proc/meminfo
AnonPages:      36422176 kB
PageTables:      2596604 kB
HugePages_Total:   70540
HugePages_Free:     3401
HugePages_Rsvd:     3391
HugePages_Surp:        0
Hugepagesize:       2048 kB
--//36422176/1024/1024 = 34.73G.
--//你可以發現沒有顯示的AnonHugePages列,很容易將這個問題與TRANSPARENT_HUGEPAGE聯絡起來,oracle的一些安裝文件要求關閉
--//TRANSPARENT_HUGEPAGE特性的。

#  grep -i hugepage config-2.6.39-400.126.1.el5uek
# CONFIG_TRANSPARENT_HUGEPAGE is not set
--//你可以發現exadata使用的核心連TRANSPARENT_HUGEPAGE都沒有設定.grep -i page /proc/meminfo沒有出現AnonHugePages也正常了.
--//是否其它伺服器要關閉TRANSPARENT_HUGEPAGE嗎?我覺得沒必要.原因如下:
--//1.沒有因為開啟出現問題,儘管oracle有一些文件提到要關閉它,也許是早期版本它有一些問題.
--//2.理論講使用它能減少PageTables的大小,節約記憶體使用.

--//exadata升級後的情況:
# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.14.35-2047.510.5.5.el7uek.x86_64 root=LABEL=DBSYS bootarea=dbsys bootfrom=BOOT boot=LABEL=BOOT
fips=0 ro loglevel=7 panic=60 log_buf_len=1m nmi_watchdog=0 transparent_hugepage=never rd_NO_PLYMOUTH audit=1
                                                            ~~~~~~~~~~~~~~~~~~~~~~~~~~
console=tty1 console=ttyS0,115200n8 crashkernel=548M numa=off pci=noaer ifnames_skip=100 biosdevname=0 net.ifnames=0

# cat  /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]
--//可以確定新版本核心配置了CONFIG_TRANSPARENT_HUGEPAGE，但是在啟動核心的命令列上加入了transparent_hugepage=never。
--//也就是關閉了TRANSPARENT_HUGEPAGE。

# grep -i hugepage /boot/config-4.14.35-2047.510.5.5.el7uek.x86_64
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS=y
# CONFIG_TRANSPARENT_HUGEPAGE_MADVISE is not set
--//很明顯exadata目前出於安全的需要,核心配置了TRANSPARENT_HUGEPAGE,但是啟動的核心還是關閉了這個特性
--//transparent_hugepage=never,並沒有開啟transparent_hugepage.

# grep -i page /proc/meminfo
AnonPages:      58448692 kB
PageTables:      4442536 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:   153600
HugePages_Free:    54037
HugePages_Rsvd:     4761
HugePages_Surp:        0
Hugepagesize:       2048 kB

--//AnonHugePages=0,也說明情況這樣.不像前面執行grep -i page /proc/meminfo，沒有AnonPages那行。
--//這樣AnonPages會變得很大,當前等於58448692KB,相當於58448692/1024 = 57078MB, 57078/1024 = 55G.
--//理論講現在開啟TRANSPARENT_HUGEPAGE是很安全的,不會出現問題,至少我目前的測試沒有遇到過這方面的問題.

--//測試開啟transparent_hugepage的情況:
# echo always >| /sys/kernel/mm/transparent_hugepage/enabled

# grep -i page /proc/meminfo
AnonPages:      59069912 kB
PageTables:      4495312 kB
AnonHugePages:    169984 kB
ShmemHugePages:        0 kB
~~~~~~~~~~~~~~~~~~~~~~~~~~~
HugePages_Total:   153600
HugePages_Free:    54035
HugePages_Rsvd:     4759
HugePages_Surp:        0
Hugepagesize:       2048 kB

--//現在可以使用了AnonHugePages.等幾天觀察看看.也就是一些新連線oracle程式可以使用TRANSPARENT_HUGEPAGE。
--//另外發現一些記憶體配置的問題,做一些記錄,對比前面grep -i page /proc/meminfo的輸出、
--//1.專案實施者設定hugepage佔用記憶體有點大。浪費了(HugePages_Free-HugePages_Rsvd)*Hugepagesize
--// = (54035-4759)*2 = 98552 M記憶體，相當於98552/1024 = 96G記憶體。這個問題先放一放。
--//2.ShmemHugePages＝0，似乎標識在tmpfs裝置上使用HugePages的數量，似乎當前沒用。
--//3.AnonPages = 59069912 kB ,而前面顯示的是AnonPages = 36422176 kB ,主要原因是升級後例項2出現一些問題重啟了,現在資料庫
--//的連線全部執行在例項1上,我自己也沒有調整過來.
--// 這樣AnonPages的使用增加，以及PageTables也隨之增加是正常現象.

--//過了好幾天，當前時間 ：
# zzdate
trunc(sysdate)+08/24+40/1440+13/86400 == 2022/09/23 08:40:13

# grep -i page /proc/meminfo
AnonPages:      47120620 kB
PageTables:      3292732 kB
AnonHugePages:   5402624 kB
ShmemHugePages:        0 kB
HugePages_Total:   153600
HugePages_Free:    53742
HugePages_Rsvd:     4466
HugePages_Surp:        0
Hugepagesize:       2048 kB
--//對比前幾天的輸出可以發現AnonHugePages增加不少,PageTables使用減少不少，理論講應該節省一些記憶體的使用.
--//(4495312-3292732)/1024/1024 = 1.15G,相當於減少了1.15G記憶體的使用.
--//看看後臺程式是否有使用AnonHugePages的程式,注意資料庫沒有重啟.

# grep -e AnonHugePages /proc/*/smaps |awk '{ if($2>0) print $0} ' | awk -F '/' '{print $3}'| paste -sd, | xargs ps -fp| grep ora[_] | grep dbcn1
*/
grep: /proc/43113/smaps: No such file or directory
grep: /proc/43389/smaps: No such file or directory
...
grep: /proc/45549/smaps: No such file or directory
grep: /proc/92989/smaps: No such file or directory
grep: /proc/97507/smaps: No such file or directory
oracle    64180      1  4 Aug15 ?        1-19:05:27 ora_dia0_dbcn1
oracle   378987      1 98 Sep22 ?        09:05:34 ora_j001_dbcn1
--//當前有2個後臺程式使用了AnonHugePages。
--//注:前面grep: /proc/43113/smaps: No such file or directory的錯誤主要是執行時間太長,一些連線已經退出,程式已經不存在了.

總結：
--//僅僅為了測試，還是有一點點風險，畢竟是生產系統環境。
--//從另外角度說明目前的核心在使用HugePages的情況下開啟TRANSPARENT_HUGEPAGE是很安全的。
--//看你應用的模式，我們目前的連線數量快過10000個連線，至少一定程度減少PageTables佔用的記憶體。