[20210803]对比transparent hugepage的内存消耗.txt

--//打开transparent hugepage时：
--//时间是 20210427
# free -m
             total       used       free     shared    buffers     cached
Mem:         64302      61683       2618          0        434      36519
-/+ buffers/cache:      24729      39573
Swap:        16383          0      16383

# grep -i page /proc/meminfo
AnonPages:      12180556 kB
PageTables:     11196784 kB
AnonHugePages:   4888576 kB
HugePages_Total:     220
HugePages_Free:      184
HugePages_Rsvd:      157
HugePages_Surp:        0
Hugepagesize:       2048 kB
--//顺便说一下该数据库没有使用hugepages，不然PageTables:11196784 kB不会这么大，占用11g。

# grep -e AnonHugePages /proc/*/smaps |awk '{ if($2>0) print $0} ' | awk -F '/' '{print $3}'| paste -sd, | xargs ps -fp | grep oracleywdb1|wc
    241    2169   17189
*/
--//有241个oracle用户进程使用AnonHugePages。

--//关闭transparent_hugepage看看呢？
# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

# echo never >| /sys/kernel/mm/transparent_hugepage/enabled

# cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

--//等待明天观察看看,结果第2天观察发现变化不是很大：
# grep -e AnonHugePages /proc/*/smaps |awk '{ if($2>0) print $0} ' | awk -F '/' '{print $3}'| paste -sd, | xargs ps -fp | grep oracleywdb1|wc
     70     630    5009
*/
--//昏还有70个链接，难道用户从不退出应用程序吗？依旧有这么多oracle用户进程使用AnonHugePages。

# free -m
             total       used       free     shared    buffers     cached
Mem:         64302      63015       1287          0        437      36655
-/+ buffers/cache:      25922      38380
Swap:        16383          0      16383

# grep -i page /proc/meminfo
AnonPages:      12245992 kB
PageTables:     12311564 kB
AnonHugePages:   4526080 kB
HugePages_Total:     220
HugePages_Free:      184
HugePages_Rsvd:      157
HugePages_Surp:        0
Hugepagesize:       2048 kB

--//可以发现AnonHugePages再减少，但是PageTables再增加，free  -m 可以看出used使用增加，感觉采用transparent hugepage更好。
--//等待更长的时间观察，结果等了3个月，主要原因时等保检查改了口令，我没有申请无法登陆服务器。

# grep -e AnonHugePages /proc/*/smaps |awk '{ if($2>0) print $0} ' | awk -F '/' '{print $3}'| paste -sd, | xargs ps -fp | grep oracleywdb1|wc
      7      63     536
--//还有7个连接没有退出.

# grep -e AnonHugePages /proc/*/smaps |awk '{ if($2>0) print $0} ' | awk -F '/' '{print $3}'| paste -sd, | xargs ps -fp| grep ora[_] | grep ywdb1|wc
     59     472    3721
--//后台进程没有退出，一直在使用AnonHugePages。

# free -m
             total       used       free     shared    buffers     cached
Mem:         64302      63261       1041          0        457      37732
-/+ buffers/cache:      25071      39231
Swap:        16383          0      16383

# grep -i page /proc/meminfo
AnonPages:      12085140 kB
PageTables:     11643576 kB
AnonHugePages:   4302848 kB
HugePages_Total:     220
HugePages_Free:      184
HugePages_Rsvd:      157
HugePages_Surp:        0
Hugepagesize:       2048 kB

# grep -e AnonHugePages /proc/*/smaps |awk '{ if($2>0) print $0} ' | awk '{print $2}' | paste -sd+ | bc
4302848
*/

--//看看生产系统exadata的情况更加明显,数据库使用hugepage，可以发现AnonPages很大大约38G，PageTables很小仅仅不到3G。
--//我前面已经提到exadata的服务器内核缺省没有开启transparent hugepage，可以发现根本没有AnonHugePages项。
#  grep -i hugepage config-2.6.39-400.126.1.el5uek
# CONFIG_TRANSPARENT_HUGEPAGE is not set

$  grep -i page /proc/meminfo
AnonPages:      40119940 kB
~~~~~~~~~~~~~~~~~~~~~~~~~~
PageTables:      2952044 kB
HugePages_Total:   70540
HugePages_Free:     3401
HugePages_Rsvd:     3391
HugePages_Surp:        0
Hugepagesize:       2048 kB

--//没有AnonHugePages项
--//40119940/1024/1024 = 38.26G ,AnonPages占用38G。

2.总结：
--//1.没有因为打开transparent hugepage出现问题,尽管oracle有一些文档提到要关闭它,也许是早期版本它有一些问题.
--//2.理论讲使用transparent hugepage能减少PageTables的大小,节约内存使用.
--//3.我对transparent hugepage的理解,连续使用内存大于2048KB的进程自动使用它，小于2048KB，使用4K的pagetables。
--//4.感觉exadata的服务器内核缺省应该选择编译支持开启transparent hugepage的选项，我想现在许多数据库只要你安装
--//不是oracle kenrel版本，应该都是开启transparent hugepage的，根本不存在任何问题。有问题在一些论坛早发现了。

3.收尾,开启transparent_hugepage:

# cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

# echo always >| /sys/kernel/mm/transparent_hugepage/enabled

# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never