关于hugepages 3.txt
关于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)
do
nohup sqlplus -s scott/book < /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)
do
nohup sqlplus -s scott/book < /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(编辑：雷林鹏 来源：网络)
关于hugepages 3.txt的更多相关文章
- [201804012]关于hugepages 3.txt
[201804012]关于hugepages 3.txt --//有一段时间我一直强调安装oracle一定要配置hugepage,因为现在的服务器内存越来越大,如果还使用4K的页面表,如果内存表占用内 ...
- Linux内核配置选项
http://blog.csdn.net/wdsfup/article/details/52302142 http://www.manew.com/blog-166674-12962.html Gen ...
- [20170927]关于hugepages.txt
[20170927]关于hugepages.txt --//今天测试hugepages与内核参数nr_overcommit_hugepages,才发现HugePages_Surp表示什么? --// ...
- [20170927]hugepages与内核参数nr_overcommit_hugepages.txt
[20170927]hugepages与内核参数nr_overcommit_hugepages.txt /proc/sys/vm/nr_overcommit_hugepages specifies h ...
- [20190409]pre_page_sga=true与连接缓慢的问题.txt
[20190409]pre_page_sga=true与连接缓慢的问题.txt --//曾经遇到11g下设置pre_page_sga=true启动缓慢的问题(没有使用hugepages).--//链接 ...
- 1GB pages can only be allocated at boot time using hugepages= and not freed afterwards
2018-6-27 9:12:38 https://stackoverflow.com/questions/26385554/error-setting-nr-hugepages-via-sysfs ...
- [20190321]smem的显示缺陷.txt
[20190321]smem的显示缺陷.txt1.smem 加入-m参数显示存在缺陷,map的信息不全:# smem -tk -m -U oracle -P "oraclepeis|ora_ ...
- 转：//linux下hugepages理解
就Linux应用程序而言,使用的都是虚拟地址,当应用程序读写一个指定的虚拟地址时,内存管理单元会自动进行虚拟地址到物理地址的转换.一个虚拟地址可以映射到多个物理地址,但当前映射到哪一个物理地址取决于当 ...
- How to use, monitor, and disable transparent hugepages in Red Hat Enterprise Linux 6
Resolution Note: Transparent Huge Pages are not available on the 32-bit version of RHEL 6. Transpare ...
随机推荐
- python学习笔记（十八）网络编程之requests模块
上篇博客中我们使用python自带的urllib模块去请求一个网站,或者接口,但是urllib模块太麻烦了,传参数的话,都得是bytes类型,返回数据也是bytes类型,还得解码,想直接把返回结果拿出 ...
- Jenkins+Ant+Jmeter自动化测试平台
持续集成 持续集成是一种软件开发实践,即团队开发成员经常集成他们的工作,通常每个成员每天至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化的构建(包括编译,发布,自动 ...
- NOSQL概念入门
一.NOSQL概念 随着大数据时代的到来,分布式存储得到了快速发展,其中比较受欢迎的,主要以key-value键值对存储的非关系型数据库进入了大家的视野. NOSQL的全称是Not Only Sql, ...
- SQL Server 使用 Pivot 和 UnPivot 实现行列转换
对于行列转换的数据,通常也就是在做报表的时候用的比较多,之前也零零散散的看了一些,今天就来总结一下. 先创建一个用于演示的临时表: create table #temp ( 年份 ) null, 月份 ...
- 一个App项目设计开发完整流程
作为一个PHP程序猿想转行APP开发可不是件容易的事情,话说隔行如隔山,这隔着一层语言也是多东西需要学习啊,一直对APP开发很感兴趣,最近请教了几个做移动开发的朋友,看了很多的资料,决定把自己学到的东 ...
- spring cloud 转
http://blog.csdn.net/forezp/article/details/70148833 服务的注册与发现(Eureka) 服务注册(consul) 服务消费者(rest+ribbon ...
- python3 驱动 PyMySQL
Python版本: 3.5.0 MySqlDB官网只支持Python3.4, 使用第三方库PyMysql连接Mysql数据库. https://pypi.python.org/pypi/PyMySQ ...
- JS 原生JS 判断滚动条滑动到底部（兼容苹果safari）
ListenerScoller () { var pageIndex = 1; var startX, startY; document.addEventListener('touchstart',f ...
- 解决NodeJS+Express模块的跨域访问控制问题：Access-Control-Allow-Origin
在一个项目上想用NodeJS,在前端的js(http://localhost/xxx)中ajax访问后端RestAPI(http://localhost:3000/….)时(Chrome)报错: XM ...
- python_threading模块实现多线程详解（转）
综述 Python这门解释性语言也有专门的线程模型,Python虚拟机使用GIL(Global Interpreter Lock,全局解释器锁)来互斥线程对共享资源的访问,但暂时无法利用多处理器的优势 ...