[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)
do
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)
do
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的好处.有许多错误希望大家指正...
--//以前写的帖子问题多多,希望看我博客的朋友不要见怪..哈哈.

[201804012]关于hugepages 3.txt的更多相关文章

  1. 关于hugepages 3.txt

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

  2. Linux内核配置选项

    http://blog.csdn.net/wdsfup/article/details/52302142 http://www.manew.com/blog-166674-12962.html Gen ...

  3. [20170927]关于hugepages.txt

    [20170927]关于hugepages.txt --//今天测试hugepages与内核参数nr_overcommit_hugepages,才发现HugePages_Surp表示什么? --// ...

  4. [20170927]hugepages与内核参数nr_overcommit_hugepages.txt

    [20170927]hugepages与内核参数nr_overcommit_hugepages.txt /proc/sys/vm/nr_overcommit_hugepages specifies h ...

  5. [20190409]pre_page_sga=true与连接缓慢的问题.txt

    [20190409]pre_page_sga=true与连接缓慢的问题.txt --//曾经遇到11g下设置pre_page_sga=true启动缓慢的问题(没有使用hugepages).--//链接 ...

  6. 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 ...

  7. [20190321]smem的显示缺陷.txt

    [20190321]smem的显示缺陷.txt1.smem 加入-m参数显示存在缺陷,map的信息不全:# smem -tk -m -U oracle -P "oraclepeis|ora_ ...

  8. 转://linux下hugepages理解

    就Linux应用程序而言,使用的都是虚拟地址,当应用程序读写一个指定的虚拟地址时,内存管理单元会自动进行虚拟地址到物理地址的转换.一个虚拟地址可以映射到多个物理地址,但当前映射到哪一个物理地址取决于当 ...

  9. 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 ...

随机推荐

  1. laravel5实现第三方登录(微信)

    背景 最近手头一个项目需要实现用户在网站的第三方登录(微信和微博),后端框架laravel5.4. 实现过程以微信网页版第三方登录,其他于此类似,在此不做重复. 准备工作 网站应用微信登录是基于OAu ...

  2. 记hangfire后台任务运行一段时间后不运行了。

    什么是Hangfire Hangfire 是一个开源的.NET任务调度框架,目前1.6+版本已支持.NET Core.个人认为它最大特点在于内置提供集成化的控制台,方便后台查看及监控. https:/ ...

  3. 纯JavaScript实现俄罗斯方块(详细注释,ES6)

    借鉴了慕课网的课程<基于websocket的火拼俄罗斯(单机版)>虽然改动比较多,但是还是核心部分没有改,加了一些不怎么好听的声音,和看起来并不好看的界面. CSS部分基本是瞎写的,因为对 ...

  4. 课程四(Convolutional Neural Networks),第二 周(Deep convolutional models: case studies) —— 2.Programming assignments : Keras Tutorial - The Happy House (not graded)

    Keras tutorial - the Happy House Welcome to the first assignment of week 2. In this assignment, you ...

  5. 线程的中断(Lock与synchronized)

    Thread包含interrupt()方法,因此你可以终止被阻塞的任务,这个方法将设置线程的中断状态.如果一个线程已经被阻塞,或者试图执行一个阻塞操作.那么设置这个线程的中断状态将 抛出Interru ...

  6. Java基础 - 线程(一)

    一.什么是线程 首先,介绍一下线程.进程的概念. 进程是操作系统分配资源的最小单元,线程是操作系统调度的最小单元.进程是指运行中的应用程序,Windows任务管理器进程窗口看到的每一项都是一个进程.每 ...

  7. SQL 必知必会·笔记<1>了解SQL

    1.1 基本概念 数据库(DataBase) 保存有组织的数据库的容器(通常是一个文件或一组文件). 表(Table) 某种特定数据类型的结构化清单. 模式(Schema) 关于数据库和表的布局及特性 ...

  8. Maven教程1(介绍安装和配置)

    官网地址:http://maven.apache.org/ 1.Maven介绍 1.1为什么需要使用Maven 之前学Spring和SpringMVC的时候我们需要单独自己去找相关的jar. 这些ja ...

  9. S5PV210中断体系结构分析

    我们按照Tiny210官方的裸板程序来梳理S5PV210的中断体系. 关于 S5PV210 的中断体系结构 S5PV210 的中断控制器是由 4 个向量中断控制器(VIC). ARM PrimeCel ...

  10. forfiles

    关键命令就这一条了:forfiles.exe /p "D:\Kugou" /m *.tar /d -14 /c "cmd /c del @path" 这条命令的 ...