关于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的更多相关文章

  1. [201804012]关于hugepages 3.txt

    [201804012]关于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. 在firefox安装Selenium IDE

    1.打开地址:https://addons.mozilla.org/en-US/firefox/addon/selenium-ide/: 2.点击Add to Firefox: 3.打开Firefox ...

  2. TensorFlow学习笔记(七)Tesnor Board

    为了更好的管理.调试和优化神经网络的训练过程,TensorFlow提供了一个可视化工具TensorBoard.TensorBoard可以有效的展示TensorFlow在运行过程中的计算图..各种指标随 ...

  3. python手写bp神经网络实现人脸性别识别1.0

    写在前面:本实验用到的图片均来自google图片,侵删! 实验介绍 用python手写一个简单bp神经网络,实现人脸的性别识别.由于本人的机器配置比较差,所以无法使用网上很红的人脸大数据数据集(如lf ...

  4. Python中的None与Null(空字符)的区别

    参考自 Python中的None与空字符(NULL)的区别 - CSDN博客 http://blog.csdn.net/crisschan/article/details/70312764 首先了解p ...

  5. 实现:左边为菜单导航,当一个菜单中包含多个Tabs,并且不同的Tab要根据权限的不同显示。

    1.前台代码 //当点击左侧菜单时,将访问Controller中的Home方法,这样就会根据用户权限的不同,通过后台的判断来决定显示的页面<li class="@(ViewBag.Se ...

  6. DevStore分享:详析消费者十大心理学

    做生意,其实就是一个恋爱的过程,让用户找到你.了解你,爱上你.而这个过程中的关键点就是用户.只要与用户心理相关的,那么就会影响到他们的购买决策.而作为卖方的你,就应该了解消费者心里面在想些什么. 第一 ...

  7. python3_requests模块详解

    1.模块说明 requests是使用Apache2 licensed 许可证的HTTP库. 用python编写. 比urllib2模块更简洁. Request支持HTTP连接保持和连接池,支持使用co ...

  8. 【GZAdmin】开源BS demo快速搭建

    下载搭建项目:链接:https://pan.baidu.com/s/1jHZ3Kkm 密码:5k4q 项目源码: GZAdmin_API:https://github.com/GarsonZhang/ ...

  9. mybatis家族

    mybatis 优秀的持久层框架,它支持定制化SQL.存储过程以及高级映射. 备注:通过mapper实现数据库与实体类相互映射 MyBatis 避免了几乎所有的JDBC 代码和手动设置参数以及获取结果 ...

  10. saltstack之haproxy的安装配置

    使用saltstack编译安装haproxy: 由于编译安装haproxy,所以安装之前需要建立编译环境,将编译环境需要安装的包单独放置在一个目录中,当编译haproxy或其他时,直接include这 ...