[201804012]关于hugepages 3.txt-白红宇

[201804012]关于hugepages 3.txt

阅读量：6555 次

发布时间：2019-06-24

本文共 9823 字，大约阅读时间需要 32 分钟。

[201804012]关于hugepages 3.txt

--//有一段时间我一直强调安装oracle一定要配置hugepage,因为现在的服务器内存越来越大,如果还使用4K的页面表,如果内存表占用内存巨大,

--//特别连接数量很大的情况下,更加明显,结果导致内存紧张,使用交换,这些类似的例子网上很多.

--//链接:

http://blog.itpub.net/267265/viewspace-2128811/=>[20161121]关于使用hugepage的讨论.txt

http://blog.itpub.net/267265/viewspace-2134900/=>[20170308]再谈hugepages.txt

--//感觉我第2次测试,可能没有排除直接路径读干扰,1:3效果不是很明显,我决定重复测试看看

1.环境:

SCOTT@book> @ &r/ver1

PORT_STRING VERSION BANNER

------------------------------ -------------- --------------------------------------------------------------------------------

x86_64/Linux 2.4.xx 11.2.0.4.0 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SCOTT@book> create table t as select rownum id from dual connect by level<=2;

Table created.

SCOTT@book> ALTER TABLE t MINIMIZE RECORDS_PER_BLOCK ;

Table altered.

--//这样可以实现每块2条记录.

SCOTT@book> insert into t select rownum+2 from dual connect by level <=64000-2;

63998 rows created.

SCOTT@book> commit ;

Commit complete.

SYS@book> create pfile='/tmp/@.ora' from spfile;

File created.

--//重启数据库:

SYS@book> startup pfile='/tmp/book.ora';

ORACLE instance started.

Total System Global Area 634732544 bytes

Fixed Size 2255792 bytes

Variable Size 197133392 bytes

Database Buffers 427819008 bytes

Redo Buffers 7524352 bytes

Database mounted.

Database opened.

SYS@book> show sga

Total System Global Area 634732544 bytes

Fixed Size 2255792 bytes

Variable Size 197133392 bytes

Database Buffers 427819008 bytes

Redo Buffers 7524352 bytes

2.测试说明:

--//首先说一下我的想法,如果执行计划走直接路径读,相关数据块并没有进入缓存,这样测试使用pagesizes的结果就不包括这部分.

--//这样执行计划走直接路径读与不走直接路径读的比较就是这部分缓存使用pagesizes.

--//建立测试连接的执行脚本

$ cat b.sh

#!/bin/bash

grep -i page /proc/meminfo

echo

for i in $(seq 100)

nohup sqlplus -s scott/book <<EOF > /dev/null 2>&1 &

variable a number;

exec :a := 0;

alter session set "_serial_direct_read"=never;

select count(*) from t where 1=:a;

host sleep 10

commit;

quit;

EOF

done

echo sleep 5s

sleep 5

echo

grep -i page /proc/meminfo

3.测试使用hugepages的情况:

--// 执行b.sh脚本,exec :a := 0;

$ . b.sh

AnonPages: 348784 kB

PageTables: 63448 kB

AnonHugePages: 0 kB

HugePages_Total: 305

HugePages_Free: 3

HugePages_Rsvd: 3

HugePages_Surp: 201

Hugepagesize: 2048 kB

sleep 5s

AnonPages: 983640 kB

PageTables: 118716 kB

AnonHugePages: 0 kB

HugePages_Total: 305

HugePages_Free: 3

HugePages_Rsvd: 3

HugePages_Surp: 201

Hugepagesize: 2048 kB

--//条件1=0,不用访问表

--//说明:开启100个会话,仅仅执行select count(*) from t where 1=:a;页面表

--//从63448kb变化到 118716kB. 118716-63448 = 55268,每个会话消耗550K.

--//这个是我以前测试没有注意的问题.

--//修改b.sh换成exec :a := 1;访问表之外,与前面没有区别:

--// 执行b.sh脚本,exec :a := 0;

$ . b.sh

AnonPages: 348788 kB

PageTables: 63404 kB

AnonHugePages: 0 kB

HugePages_Total: 305

HugePages_Free: 3

HugePages_Rsvd: 3

HugePages_Surp: 201

Hugepagesize: 2048 kB

sleep 5s

AnonPages: 983548 kB

PageTables: 118948 kB

AnonHugePages: 0 kB

HugePages_Total: 305

HugePages_Free: 3

HugePages_Rsvd: 3

HugePages_Surp: 201

Hugepagesize: 2048 kB

--//你可以对比发现2个差距不大,使用hugepages后,访问表与不访问表PageTables的变化很小.

4.测试不使用hugepages的情况:

--//重启数据库./tmp/book.ora 参数修改不使用hugepages看看.

--//*.use_large_pages='FALSE'

SYS@book> startup pfile='/tmp/book.ora';

ORACLE instance started.

Total System Global Area 634732544 bytes

Fixed Size 2255792 bytes

Variable Size 197133392 bytes

Database Buffers 427819008 bytes

Redo Buffers 7524352 bytes

Database mounted.

Database opened.

SYS@book> show parameter use_large_pages

NAME TYPE VALUE

--------------- ------ ------

use_large_pages string FALSE

--// 执行b.sh脚本,exec :a := 0;

$ . b.sh

AnonPages: 265200 kB

PageTables: 63952 kB

AnonHugePages: 0 kB

HugePages_Total: 104

HugePages_Free: 104

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

sleep 5s

AnonPages: 905808 kB

PageTables: 148476 kB

AnonHugePages: 0 kB

HugePages_Total: 104

HugePages_Free: 104

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

--//说明:开启100个会话,仅仅执行select count(*) from t where 1=:a;页面表

--//从63952kb变化到148476 kB. 148476-63952 = 84524 kb,每个会话消耗840K.但是前面使用hupages每个会话仅仅消耗550K,

--//这样如果会话很多累积起来差别还是很大的.

--// 执行b.sh脚本,exec :a := 1;

$ . b.sh

AnonPages: 268096 kB

PageTables: 64276 kB

AnonHugePages: 0 kB

HugePages_Total: 104

HugePages_Free: 104

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

sleep 5s

AnonPages: 904432 kB

PageTables: 215188 kB

AnonHugePages: 0 kB

HugePages_Total: 104

HugePages_Free: 104

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

--//你可以发现访问表与不访问表,PageTables变化148476 kB =>215188 kB.存在很大差距.

--//以下计算存在很大偏差,不过还是能说明问题:

--//(215188-64276)-(148476-63952) = 66388,使用hugepages,访问表页面表增加66388.

--//(118948-63404)-(118716-63448) = 276, 不使用hugepages,访问表页面表增加276.

--//66388/276 = 240.53623188405797101449

--//可以发现对比访问数据与不访问数据,hugepages存在240倍差距.当然我这样计算误差很大.哈哈也不知道这样算是否有问题.

--//我的数据库使用手工管理内存,全部参数手工设置,这样内存的分配是连续.看看内存分配情况.参考链接:http://blog.itpub.net/267265/viewspace-2136689/

SYS@book> @ &r/memalloc

MIN(BASEADDR) MAX(BASEADDR) GRANULES MB GRANFLAGS COMPONENT GRANSTATE

---------------- ---------------- ---------- ---------- ---------- -------------------------------- ----------------

0000000060C00000 000000007A000000 102 408 4 DEFAULT buffer cache ALLOC

000000007A400000 000000007A400000 1 4 4 java pool ALLOC

000000007A800000 000000007B000000 3 12 4 large pool ALLOC

000000007B400000 0000000085C00000 43 172 4 shared pool ALLOC

SYS@book> show parameter db_cache_size

NAME TYPE VALUE

------------- ----------- ------

db_cache_size big integer 408M

--//gransize=4*1024*1024=4194304

--//4194304 = 0x400000

--//0x7A400000+0x400000= 0x7A400000

--//可以看出缓存分配范围0x0000000060C00000-0x000000007A400000.

--//转换10进制 0x60C00000=1623195648, 0x7A400000=2051014656.

SYS@book> select OBJECT_ID,DATA_OBJECT_ID from dba_objects where owner='SCOTT' and object_name='T';

OBJECT_ID DATA_OBJECT_ID

---------- --------------

90610 90610

SELECT xx, COUNT (*)

FROM (SELECT ROUND ( (TO_NUMBER (ba, 'xxxxxxxxxxxxxxxxxxxxxx') - 1623195648) / (2 * 1024 * 1024) ,0) xx

FROM x$bh

WHERE obj = 90610 AND state <> 0)

GROUP BY rollup(xx)

ORDER BY xx;

XX COUNT(*)

---------- ----------

27 18

29 44

31 120

32 21

33 153

34 50

35 172

36 106

37 208

38 204

39 256

40 227

41 256

42 230

43 256

44 234

45 256

46 234

47 256

48 234

49 256

50 234

51 256

52 234

53 256

54 234

55 256

56 234

57 256

58 234

59 256

60 234

61 256

62 234

63 256

64 234

65 256

66 234

67 256

68 234

69 256

70 234

71 256

72 234

73 256

74 234

75 256

76 234

77 256

78 234

79 256

80 234

81 256

82 234

83 256

84 234

85 256

86 234

87 256

88 234

89 256

90 234

91 256

92 234

93 256

94 234

95 256

96 234

97 256

98 234

99 256

100 234

101 256

102 234

103 256

104 234

105 256

106 234

107 256

108 234

109 256

110 234

111 256

112 234

113 256

114 234

115 256

116 234

117 256

118 234

119 256

120 234

121 256

122 234

123 256

124 234

125 256

126 234

127 256

128 234

129 256

130 234

131 256

132 234

133 256

134 234

135 256

136 232

137 256

138 234

139 256

140 234

141 256

142 234

143 256

144 234

145 256

146 234

147 256

148 234

149 256

150 234

151 256

152 234

153 256

154 234

155 256

156 234

157 256

158 234

159 256

160 234

161 256

162 234

163 220

164 200

165 88

166 81

167 10

32062

140 rows selected.

--//页面表占用139项(如果使用hugepages).占用数据块数 32062.

--//如果使用4k的页面表.32062*8192/4096 = 64124.

--//64128/139 = 461.35251798561151079136.为什么不是前面计算240被.

--//如果你仔细看查询x$bh输出,就可以发现问题,我数据库重启后(不使用hugepages)看到的数据分布,它全部集中在前面.

--//而我前面使用hugepages时机器很长时间没有关闭数据库,我估计数据会均匀分布在这个数据缓存,这样我的测试环境

--//db_cache_size=408M,这样页面表应该接近204项.

--//64128/204 = 314.35294117647058823529,还是存在很大误差.或许我这样计算存在问题...^_^.

5.测试不使用hugepages的情况,建立索引的情况呢?

SCOTT@book> alter table t modify (id not null);

Table altered.

SCOTT@book> create index i_t_id on t(id);

Index created.

--// 执行b.sh脚本,exec :a := 0;

$ . b.sh

AnonPages: 282884 kB

PageTables: 67876 kB

AnonHugePages: 0 kB

HugePages_Total: 104

HugePages_Free: 104

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

sleep 5s

AnonPages: 918952 kB

PageTables: 152108 kB

AnonHugePages: 0 kB

HugePages_Total: 104

HugePages_Free: 104

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

--// 执行b.sh脚本,exec :a := 1;

$ . b.sh

AnonPages: 282840 kB

PageTables: 67860 kB

AnonHugePages: 0 kB

HugePages_Total: 104

HugePages_Free: 104

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

sleep 5s

AnonPages: 917564 kB

PageTables: 159184 kB

AnonHugePages: 0 kB

HugePages_Total: 104

HugePages_Free: 104

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

--//可以建立索引后,执行计划走索引全 INDEX FAST FULL SCAN.这样访问的块明显减少.

--//对比PageTables使用内存变化也不是很大,从另外一个访问也说明一个问题,当应该优化不好PageTables占用空间也会很大.

--//当转换使用hugepages直接把问题掩盖起来.

5.测试不使用hugepages的情况,访问表走直接路径读的情况呢?

--//清除数据缓存.

SYS@book> alter system flush buffer_cache;

System altered.

--// 修改脚本注解alter session set "_serial_direct_read"=never;.

$ cat b.sh

#!/bin/bash

grep -i page /proc/meminfo

echo

for i in $(seq 100)

nohup sqlplus -s scott/book <<EOF > /dev/null 2>&1 &

variable a number;

exec :a := 0;

--//alter session set "_serial_direct_read"=never;

Select count(*) from t where 1=:a;

host sleep 10

commit;

quit;

EOF

done

echo sleep 5s

sleep 5

echo

grep -i page /proc/meminfo

--//执行b.sh脚本,exec :a := 0;

$ . b.sh

AnonPages: 280592 kB

PageTables: 68312 kB

AnonHugePages: 0 kB

HugePages_Total: 104

HugePages_Free: 104

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

sleep 5s

AnonPages: 917436 kB

PageTables: 155852 kB

AnonHugePages: 0 kB

HugePages_Total: 104

HugePages_Free: 104

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

--//执行b.sh脚本,exec :a := 1;

$ . b.sh

AnonPages: 281504 kB

PageTables: 68348 kB

AnonHugePages: 0 kB

HugePages_Total: 104

HugePages_Free: 104

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

sleep 5s

AnonPages: 1129404 kB

PageTables: 159832 kB

AnonHugePages: 0 kB

HugePages_Total: 104

HugePages_Free: 104

HugePages_Rsvd: 0

HugePages_Surp: 0

Hugepagesize: 2048 kB

--//对比可以发现走直接路径读的情况下,PageTables基本没有变化.

--//但愿这个帖子能说明hugepage的好处.有许多错误希望大家指正...

--//以前写的帖子问题多多,希望看我博客的朋友不要见怪..哈哈.

转载于:https://www.cnblogs.com/lfree/p/8818575.html

你可能感兴趣的文章

Flutter 布局（三）- FittedBox、AspectRatio、ConstrainedBox详解

查看>>

React Native填坑之旅--Stateless组件

查看>>

技术沙龙|区块链商用落地的策略与技术坑-区块链扩展和Fabric商用（杭州）

java.lang.OutOfMemoryError总结

查看>>

IIS下虚拟主机的四种使用方法

查看>>

腾讯技术工程 | 腾讯AI Lab解析2017 NIPS三大研究方向，启动教授及学生合作项目...

查看>>

搭建android + cordova环境

查看>>

centos6.5监控平台nagios搭建与配置

lync客户端外网登陆提示exchange连接错误

查看>>

计算机应用一级B考试专题整理三

查看>>

bzoj 2762: [JLOI2011]不等式组——树状数组

查看>>

uva 437，巴比伦塔

查看>>

利用FFmpge进行视频解码(从H264视频流到图像)

查看>>

P51、面试题5：从尾到头打印链表

查看>>

有关一些 c++ cmath 库中的函数的精度问题

查看>>