[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占用的内存。