[20160516]11G HugePage的使用问题.txt

[20160516]11G HugePage的使用问题.txt

--我们的dg内存不足,配置的/etc/sysctl.conf如下:
vm.nr_hugepages = 3200

--没有启动数据库前如下:

# grep -i huge /proc/meminfo
AnonHugePages:     14336 kB
HugePages_Total:    3200
HugePages_Free:     3200
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

--3200*2=6400M,也就是配置了6G上下给HugePAGE,而我们数据库原来的参数很大,达到SGA_TAGGET=76G,正常不会HUPEGE.

--启动数据库后:

SYS@dbcn1> startup open read only
ORACLE instance started.
Total System Global Area 8.0973E+10 bytes
Fixed Size                  2261968 bytes
Variable Size            9932114992 bytes
Database Buffers         7.0867E+10 bytes
Redo Buffers              171487232 bytes
Database mounted.
Database opened.

SYS@dbcn1> show parameter sga_
NAME          TYPE         VALUE
------------- ------------ --------
sga_max_size  big integer  77568M
sga_target    big integer  77568M

# grep -i huge /proc/meminfo
AnonHugePages:     26624 kB
HugePages_Total:    3200
HugePages_Free:     3003
HugePages_Rsvd:     3003
HugePages_Surp:        0
Hugepagesize:       2048 kB

--你可以发现依旧使用HUGEPAGE.检查alert*.log文件:

************************ Large Pages Information *******************
Per process system memlock (soft) limit = 58 GB

Total Shared Global Region in Large Pages = 6400 MB (8%)

Large Pages used by this instance: 3200 (6400 MB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 3200 (6400 MB)
Large Page size = 2048 KB

RECOMMENDATION:
  Total System Global Area size is 76 GB. For optimal performance,
  prior to the next instance restart:
  1. Increase the number of unused large pages by
at least 35585 (page size 2048 KB, total size 70 GB) system wide to
  get 100% of the System Global Area allocated with large pages
  2. Large pages are automatically locked into physical memory.
Increase the per process memlock (soft) limit to at least 76 GB to lock
100% System Global Area's large pages into physical memory
********************************************************************

--换一句话讲及时即使你配置不足,oracle也会使用它.不知道从那个版本开始支持这个特性.

这个情况在11.2.0.3版本中有一些变化。Oracle首先会使用可用的HugePage,如果使用尽了,同样会采用剩下的small pages作为SGA使用
。变化在于对使用HugePage的方式上,根据官方的说法:

With this new behavior additional shared memory segments are an expected side effect. Part of the change is to ensure
that each shared memory segment making up the SGA only contains sub-areas with an identical alignment requirement -
hence the SGA will spread over more separate SHM segments. In this supported mixed page mode the database will exhaust
the available hugepages, before switching to regular sized pages.

--另外必须注意一个问题,如果设置不用这些内存不用就浪费了.
--假设设置
vm.nr_hugepages = 26000

# free -m
             total       used       free     shared    buffers     cached
Mem:        129161      41066      88094          0        892      31060
-/+ buffers/cache:       9113     120047
Swap:        30718          0      30718

# sysctl -p

# free -m
             total       used       free     shared    buffers     cached
Mem:        129161      86665      42495          0        892      31060
-/+ buffers/cache:      54713      74448
Swap:        30718          0      30718

--内存马上使用45G,free也减少了.这个在配置时注意,假设你设置了以上参数,数据库又没有重启,这样不会使用hugepage,双重内存使用,内存很快会耗尽.

时间: 2024-09-20 17:28:38

[20160516]11G HugePage的使用问题.txt的相关文章

[20160517]11G HugePage的使用问题2.txt

[20160517]11G HugePage的使用问题2.txt --昨天测试了HUGEPAGE的使用问题,自己也看了一些文档,从11.2.0.2,加入了参数use_large_pages. SYS@book> @ &r/ver1 PORT_STRING         VERSION        BANNER ------------------- -------------- -------------------------------------------------------

[20170620]11G 12c expand sql text.txt

[20170620]11G 12c expand sql text.txt --//原来写的脚本只能分别在11g,12c单独使用.上午花一点点时间.把两者整合起来. --//讨论链接:http://www.itpub.net/thread-2088981-1-1.html --//再次感谢solomon_007的指点: set long 20000 set serveroutput on declare     L_sqltext clob := null;     l_version varc

[20161208]11g直方图与char数据类型.txt

[20161208]11g直方图与char数据类型.txt --以前看tom大师的书提到过不要使用char数据类型,哪怕是char(1)也不要使用,最近看了几篇blob里面都提到了11g升级后会出现char数 --据类型直方图统计发生了变化,我重复别人的例子来说明.再次强调不要生产环境使用char类型. --参考链接:http://blog.dbi-services.com/histograms-on-character-strings-between-11-2-0-3-and-11-2-0-4

[20171120]11G关闭直接路径读.txt

[20171120]11G关闭直接路径读.txt --//今天做filesystemio_options参数测试时,遇到一个关于直接路径读的问题. --//如果看以前的博客介绍,设置"_serial_direct_read"=never或者events '10949 trace name context forever';就可以关闭直接路径读. --//我的测试在11GR2下set events '10949 trace name context forever';不行. --//通过

[20170518]11G审计日志清除3.txt

[20170518]11G审计日志清除3.txt --//以前写的链接:http://blog.itpub.net/267265/viewspace-2133145/ --//我当时写存在许多问题,仅仅清除sys.aud$内容,参数audit_file_dest目录的文件不清除,而这里参数大量的aud文件,重新测试看看. 1.环境: SYS@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER -------

[20150504]11G口令不对的问题.txt

[20150504]11G口令不对的问题.txt --前一阵子,遇到用户口令不对,导致登录缓慢的问题,主要11G加入密码错误验证延迟导致的.(哎现在看文档才知道) http://blog.itpub.net/267265/viewspace-1479718/ Preventing passwords from being broken. If a user tries to log in to Oracle Database multiple times using an incorrect p

[20150706]11G谓词推入问题.txt

[20150706]11G谓词推入问题.txt --生产系统遇到一个sql语句的问题. --生产系统的sql语句比较复杂,做一个简化的例子来说明问题.来说明自己优化遇到的困惑. 1.建立测试环境: SCOTT@test> @ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ----------------------------------

[20160816]11G dataguard坏块修复.txt

[20160816]11G dataguard坏块修复.txt --11GR2 不仅仅支持在备库在只读的情况下,日志应用(ACTIVE Data Guard),还提供主备库的坏块修复.自己以前也做过相关测试, --我记得上次测试的仅仅是主库数据块损坏,没有测试备库的数据块损坏.补充一些测试: 1.环境: SYS@test> @ ver1 PORT_STRING                    VERSION        BANNER ---------------------------

[20120626]11G的Extended Stats问题.txt

[20120626]11G的Extended Stats问题.txt select * from v$version ; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production PL/SQL Release 11.2.0.1.