[20170308]再谈hugepages.txt
--//节前跟别人的交流,不幸被我言中.当时是去年5月份的事前,系统迁移,我去观摩,我感觉很奇怪的是内存128G的机器,不知道为什么不
--//应用hugepages,让我吃惊对方并不知道.因为毕竟是别的系统,别人如何做我无权过问.我当时只是提醒如果连接用户数量大,按照他们
--//当时的是设置,有可能会出现内存不足的情况.
--//我在链接http://blog.itpub.net/267265/viewspace-2128811/的测试中:
--//使用与不使用仅仅2倍差距,这是因为我但是连接后基本没执行什么sql语句.今天在写一个例子说明问题:
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.
--//建立测试连接的执行脚本
$ cat a.sh
#! /bin/bash
for i in $(seq 100)
do
sqlplus -s scott/book <<EOF > /dev/null &
select count(*) from t;
host sleep 60
commit;
quit;
EOF
done
2.测试一:
--//测试前可以执行select count(*) from t;让该表数据块全部进入缓存.
--//使用hugepages的情况:
$ cat /proc/meminfo | grep -i page
AnonPages: 221076 kB
PageTables: 11972 kB
AnonHugePages: 40960 kB
HugePages_Total: 305
HugePages_Free: 3
HugePages_Rsvd: 3
HugePages_Surp: 0
Hugepagesize: 2048 kB
--//执行脚本a.sh
$ cat /proc/meminfo | grep -i page
AnonPages: 876416 kB
PageTables: 66296 kB
AnonHugePages: 40960 kB
HugePages_Total: 305
HugePages_Free: 3
HugePages_Rsvd: 3
HugePages_Surp: 0
Hugepagesize: 2048 kB
--//页面的使用情况:
--//66296-11972=54324. 54324/100=543.24 平均每个会话使用543K.
3.测试二:
SYS@book> alter system set use_large_pages=false scope=spfile;
System altered.
--//重启数据库.
--//测试前可以执行select count(*) from t;让该表数据块全部进入缓存.
--//如果走直接路径读,可以先设置
alter session set events '10949 trace name context forever, level 1';
select count(*) from t;
$ oerr ora 10949
10949, 00000, "Disable autotune direct path read for full table scan"
// *Cause:
// *Action: Disable autotune direct path read for serial full table scan.
--//不使用hugepages的情况:
$ cat /proc/meminfo | grep -i page
AnonPages: 146628 kB
PageTables: 15832 kB
AnonHugePages: 20480 kB
HugePages_Total: 305
HugePages_Free: 305
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
--//执行脚本a.sh
$ cat /proc/meminfo | grep -i page
AnonPages: 789256 kB
PageTables: 161916 kB
AnonHugePages: 20480 kB
HugePages_Total: 305
HugePages_Free: 305
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
--//161916-15832=146084,146084/100=1460.84,平均每个会话使用1460.84K.对比前面也就是不到3倍的量.
--//与我的理解存在差距,我一直认为这样应该存在很大的差异,不知道那位给出解析.
4.测试三:
--//如果建立索引呢?
SCOTT@book> alter table t modify (id not null);
Table altered.
SCOTT@book> create index i_t_id on t(id);
Index created.
--//这样执行计划如下:
SQL_ID cyzznbykb509s, child number 1
-------------------------------------
select count(*) from t
Plan hash value: 3548397654
Plan hash value: 3548397654
------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | Cost (%CPU)| E-Time | A-Rows | A-Time | Buffers |
------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 40 (100)| | 1 |00:00:00.02 | 149 |
| 1 | SORT AGGREGATE | | 1 | 1 | | | 1 |00:00:00.02 | 149 |
| 2 | INDEX FAST FULL SCAN| I_T_ID | 1 | 64000 | 40 (0)| 00:00:01 | 64000 |00:00:00.01 | 149 |
------------------------------------------------------------------------------------------------------------------
--//不使用hugepages的情况:
$ cat /proc/meminfo | grep -i page
AnonPages: 142228 kB
PageTables: 17136 kB
AnonHugePages: 20480 kB
HugePages_Total: 305
HugePages_Free: 305
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
--//执行脚本a.sh:
$ cat /proc/meminfo | grep -i page
AnonPages: 795240 kB
PageTables: 104772 kB
AnonHugePages: 20480 kB
HugePages_Total: 305
HugePages_Free: 305
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
--//104772-17136=87636, 87636/100=876.36K,平均每个会话使用876.36K.比测试二要小一点.从另外一个侧面也可以说明优化也可以减
--//少页面表的内存占用.
5.测试四:
--//取消use_large_pages;,这样缺省是true.
SYS@book> alter system reset use_large_pages;
System altered.
--//重启数据库.回到使用hugepages的情况:
--//使用hugepages的情况:
$ cat /proc/meminfo | grep -i page
AnonPages: 135852 kB
PageTables: 10768 kB
AnonHugePages: 20480 kB
HugePages_Total: 305
HugePages_Free: 94
HugePages_Rsvd: 94
HugePages_Surp: 0
Hugepagesize: 2048 kB
--//执行脚本a.sh:
$ cat /proc/meminfo | grep -i page
AnonPages: 789384 kB
PageTables: 64512 kB
AnonHugePages: 20480 kB
HugePages_Total: 305
HugePages_Free: 91
HugePages_Rsvd: 91
HugePages_Surp: 0
Hugepagesize: 2048 kB
--//与测试一相似.
总结:
--我一直报者这样的观点,使用比不使用好,虽然我上面的测试相差比例1:3.缺点不能使用assm,实际上assm根本不适合大型系统.
--但是当你不使用hugepages,出现内存不足后,改用hugepages效果明显.
--而且如果你仔细看的前面的测试,实际上暗含一个提示,优化sql语句也可以达到减少页面表使用的情况.
--或者页面表占用大量的内存情况下,可能暗含统可能存在大量的不良sql语句问题.
--实际上当时我去看了一下,优化一些语句,页面表马上减少很多(当时的情况是无法重启数据库的).至少当时业务高峰顶过去了.
--但是如果采用hugepages,问题就看不出来,我看过我们生产系统的数据库,如果hugepages,大约每个用户使用500K页面表内存.
--而且内存越大,采用hugepages效果越好.