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