Hugepage、VLM、SGA和Share memory

一、相关概念
Hugepage/Big page:
系统进程是通过虚拟地址访问内存,但是CPU必须把它转换程物理内存地址才能真正访问内存。为了提高这个转换效率,CPU会缓存最近的虚拟内存地址和物理内存地址的映射关系,并保存在一个由CPU维护的映射表中。为了尽量提高内存的访问速度,需要在映射表中保存尽量多的映射关系。
而在Redhat Linux中,内存都是以页的形式划分的,默认情况下每页是4K,这就意味着如果物理内存很大,则映射表的条目将会非常多,会影响CPU的检索效率。因为内存大小是固定的,为了减少映射表的条目,可采取的办法只有增加页的尺寸。这种增大的内存页尺寸在Linux 2.1中,称为Big page;在AS 3/4中,称为Hugepage。
如果系统有大量的物理内存(大于8G),则物理32位的操作系统还是64位的,都应该使用Hugepage。
注意:使用Hugepage内存是共享内存,它会一直keep在内存中的,不会被交换出去,也就是说使用hurgepage的内存不能被其他的进程使用,所以,一定要合理设置这个值,避免造成浪费。对于只使用Oracle的服务器来说,把Hugepage_pool设置成SGA大小即可。

VLM(Very Large Memory ):这个是要是针对32位的操作系统,对于64位操作系统,则需要设置VLM。在启用了Hugepage的情况下,32位的ORACLE可以把SGA扩展到62G。需要注意的是,VLM只对SGA中buffer cache有效,对shared pool、large pool、java pool等无效。
VLM的原理是把内存虚拟程一个文件,系统进程通过读取这个内存文件达到使用内存的目的。
如果ORACLE想要使用VLM,则必须设置参数use_indirect_data_buffers=true。如果是10g的数据库,还需要把db_cache_size转换成老版本的db_block_buffers,否则会报错。
当SGA使用VLM时,SGA对应的共享内存会分成两个部分:
 . 普通的系统共享内存,也就是可以从ipcs -ma看到的部分,这部分主要对应非buffer cache的SGA(large pool/shared pool/java pool/streams pool)等。
 . 基于内存文件的共享内存,这部分可以通过ls -al /dev/shm查看。这部分主要对应SGA中的data buffer部分。

注意:使用VLM时,用于非buffer cache部分的内存会保留512M用于管理VLM。如如果分配了2.5G给非buffer cache使用,实际上,只有2G的实际可用内存。

当使用VLM时,以上两个部分共享内存之和等于SGA。(如果不使用VLM,则SGA大小就等于ipcs -ma显示的大小基本一致)

下面举一个例子说明这四者的关系:

1、SGA相关
SQL> show sga

Total System Global Area 1879048192 bytes
Fixed Size                   778452 bytes
Variable Size             802430764 bytes
Database Buffers         1073741824 bytes
Redo Buffers                2097152 bytes
-----非BUFFER CACHE部分
SQL> show parameter shared_pool_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
shared_pool_size                     big integer 512M
SQL> show parameter java_pool_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
java_pool_size                       big integer 32M
SQL> show parameter large_pool_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
large_pool_size                      big integer 128M
SQL> show parameter streams_pool_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
streams_pool_size                    big integer 80M
SQL> show parameter log_buffer

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_buffer                           integer     2097152

-----BUFFER CACHE部分
SQL> show parameter block_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_block_size                        integer     8192
SQL> show parameter db_block_buffers

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_block_buffers                     integer     131072

 

2、ipcs显示的大小
$ipcs -a

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0xf258e130 32769      oracle    600        807403520  0
0x00000000 65538      oracle    640        4096       0

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x610520f4 98304      oracle    640        602
0x610520f5 131073     oracle    640        602
0x610520f6 163842     oracle    640        602

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

 
3、/dev/shm大小
$ls -al /dev/shm
total 120
drwxrwxrwt    1 root     root            0 Feb 15 02:11 .
drwxr-xr-x   22 root     root       118784 Feb 15 02:11 ..
-rw-r-----    1 oracle   dba      1073741824 Feb 15 02:12 ora_test_65538

 

 
(shared_pool_size + java_pool_size + large_pool_size + streams_pool_size + log_buffer) = (512 + 32 + 128 + 80)*1024*1024+2097152=790626304 和ipcs的结果807403520基本一致。
131072*8192=1073741824 和ls -al /dev/shm的结果1073741824相等。
这个结果也验证了以上我们做的结论。

 

 

二、配置Hugepage
因为使用hugepage部分的共享内存不能被swap,也不能被其他进程使用,如果把hugepage共享内存设置过大,会导致系统hang住。
既要考虑性能,又要不浪费内存,一定要把使用hugepage部分的共享内存设置一个最佳值。下面的一些参考:
1) 如果是32位操作系统,且没有用VLM,则设置 hugetlb_pool=所有运行在该服务器上的实例SGA总和。如果有ASM,则每一个ASM实例再增加200M左右
2) 如果是32位操作系统,且使用了VLM,则设置 hugetlb_pool=所有运行在该服务器上的实例除data buffer外的SGA总和。如果有ASM,则每一个ASM实例再增加200M左右
3) 如果是64位操作系统,不管是否启用VLM,都设置 hugetlb_pool=所有运行在该服务器上的实例SGA总和。如果有ASM,则每一个ASM实例再增加200M左右

在RHEL 2.1/3/4设置Hugepage的方法各不一样,因为2.1版本太低,这里就不介绍了。

1、在RHEL3中设置hugepage
很简单,只需要在/etc/sysctl.conf添加如下行即可:
#设置1024M hugepage momory
vm.hugetlb_pool=1024

执行sysctl -p使得修改生效。

此时从/proc/meminfo中可以验证设置是否生效:
$more /proc/meminfo |grep -i HugePage
HugePages_Total:   512
HugePages_Free:    512
Hugepagesize:     2048 kB

因为设置的1024M的hugepage_pool,每页2M,所以会有512页。
理想情况下,当oracle实例启动后,HugePages_Free应等于或者接近0。

2、在RHEL4中设置hugepage
类似于RHEL3,在RHEL4配置hugepage也很简单,
1)在/etc/sysctl.conf添加如下行:
#设置1024M hugepage momory
vm.nr_hugepages=512

在RHEL4中,是直接设置hugepage的页数。

执行sysctl -p使得修改生效。

2) 在/etc/security/limits.conf 添加如下行
oracle           soft    memlock         1048576
oracle           hard    memlock         1048576

必须设置这个,否则启动数据库可能会报错:
ORA-27103: internal error
Linux Error: 11: Resource temporarily unavailable

此时从/proc/meminfo中可以验证设置是否生效:
$more /proc/meminfo |grep -i HugePage
HugePages_Total:   512
HugePages_Free:    512
Hugepagesize:     2048 kB

理想情况下,当oracle实例启动后,HugePages_Free应等于或者接近0。

如果不想设置hugepage,则设置vm.nr_hugepages=0即可。

有几点需要注意:
1) 无论RHEL3还是RHEL4,只要设置了hugepage_pool或者nr_hugepages,都意味着指定尺寸的内存被pin在内存中了。就算SGA需要的共享内存小于设置的hugepage_pool,这部分内存也无法被其他进程使用,所以,一定要计算好需要的大小,不宜设置过大的hugepage共享内存,避免浪费。

 

三、配置VLM
在RHEL3和RHEL4中,可以使用两种内存文件方式配置VLM:
. shmfs/tmpfs:这个内存文件方式会发生换页,与hugepage冲突,不适用于使用hugepage的内存管理方式。其中shmfs只适用于RHEL3,tempfs适用于RHEL3和RHEL4。
. ramfs:这种方式不会发生换页,可以与hugepage搭配使用。
要配置VLM,系统内核必须支持以上三种文件系统之一,可以用以下命令判断:
egrep "shm|tmpfs|ramfs" /proc/filesystems
如果结果有对应的条目输出,则表示支持该类型文件系统,如:
nodev   tmpfs
nodev   ramfs
表示内存支持tmpfs和ramfs两种内存文件系统。

下面以为一个32位的数据库配置8G大小的buffer cache为例说明如何在RHEL3/4中配置VLM(首先要保证内核支持并已经配置Hugepage)
1、挂载内存文件系统
umount /dev/shm
mount -t ramfs ramfs /dev/shm
chown oracle:dba /dev/shm
注意
1)为了重启后也生效,最好把以上几行写在/etc/rc.local里
2)如果oracle用户的主组不是dba,如是oinstall,则chown oracle:oinstall /dev/shm

2、修改oracle参数
use_indirect_data_buffers=true
db_block_size=8192
db_block_buffers=1048576
shared_pool_size=2831155200

3、修改oracle的资源限制
在/etc/security/limits.conf中设置memlock=3145728,也就是在该文件中添加如下两行:
 
oracle           soft    memlock         3145728
oracle           hard    memlock         3145728

用ulimit -l验证

 

 

 

 

使用VLM时:
1) 无论是什么版本,不能用db_cache_size参数,必须转换成对应的db_block_buffers和db_block_size
2) data buffer部分的共享内存来自VLM,但SGA的其他部分,如shared_pool使用的共享内存来自系统的普通共享内存。
3) kernel.shmmax的设置应大于等于除data buffer以外的其他SGA部件之和
4) 不必像设置hugepage_pool那样考虑要位data buffer设置多大的共享内存,操作系统会自动生成一个与设置的data buffer一样大小的内存文件
5) 即使hugepage足够大,data buffer需要的共享内存也不会从hugepage_pool中分配,而是使用VLM内存文件扩展共享内存段
6) 即使hugepage不足,非data buffer部分的SGA需要的共享内存也不会从VLM中分配,而是使用系统其他的空闲内存扩展共享内存段

最后做一个简单总结:

1、hugepage是为了提高内存的性能;VLM是为了使32位操作系统使用大内存
2、如果服务器上有大量物理内存:
如果是64位的操作系统,只需要设置hugepage即可,且可以使用db_cache_size这一新参数。
如果是32位的操作系统,需要配置hugepage和VLM,并且不能使用db_cache_size这一新参数。其中hugepage_pool设置为非buffer cache的内存总和大小。buffer cache对应的共享内存部分无需设置,OS会自动分配适当大小的内存文件作为共享内存。

时间: 2024-08-06 19:46:45

Hugepage、VLM、SGA和Share memory的相关文章

pgpool-II 3.2 coming soon, get cool feature with it, on memory query cache and Built in HA

Almost one year worth of development, pgpool-II 3.2 release is getting closer. This version has two major new features: On memory query cache Built in HA On memory query cache is similar to MySQL's query cache.  Caching query SELECT query results by

Oracle 隐含参数

Oracle 隐含参数 点击(此处)折叠或打开 set pagesize 9999 set line 9999 col NAME format a40 col KSPPDESC format a50 col KSPPSTVL format a20 SELECT a.INDX,        a.KSPPINM NAME,        a.KSPPDESC,        b.KSPPSTVL FROM x$ksppi a,        x$ksppcv b WHERE a.INDX = b.

Linux 日志报错 xxx blocked for more than 120 seconds

        监控作业发现一台服务器(Red Hat Enterprise Linux Server release 5.7)从凌晨1:32开始,有一小段时间无法响应,数据库也连接不上,后面又正常了.早上检查了监听日志,并没有发现错误信息.但是检查告警日志,发现有下面错误信息: Thread 1 advanced to log sequence 19749 (LGWR switch)   Current log# 2 seq# 19749 mem# 0: /u01/oradata/epps/r

内存异常消耗诊断案例

转自:http://blog.csdn.net/lunar2000/article/details/404111 本文已经发表在ITPUB优化技术丛书,未经许可,不得转载. (作者不让转,但是小弟就是为了有个记录,没有商业用途哈,非要追究我的话,我就删了..嘿嘿) 1.   问题发现 一大早,接到通知说现网数据库(RAC中的一个节点)出现异常,现象是大量的业务拥堵,系统可用内存很低,经常徘徊在100m左右,随着业务高峰期的时间就要到了,眼看系统的内存已经处在极其危险的状态.   2.   解决过

Oracle结果集缓存(Result Cache)--服务器、客户端、函数缓存

Oracle结果集缓存(Result Cache)--服务器.客户端.函数缓存 在11g中,Oracle提供了结果集缓存特性.该缓存是在共享内存中存储全部的结果集,如果一个查询SQL被执行,且它对应的结果集在缓存中,那么,该SQL的几乎全部开销都可以避免.这些开销包括,解析时间.逻辑读.物理读和任意的通常可能会遭遇的争用.但是,在实际的情况中,结果集缓存仅在少数的情况下是有效的,原因有如下几点: (1)有数据重叠的多个SQL会在缓存中保存冗余的数据. (2)对依赖对象的任何改变(包括对查询中引用

ORA-04031错误

ORA-04031错误 ORA-4031 错误故障排除与诊断[视频] (文档 ID 2016002.1).Troubleshooting and Diagnosing ORA-4031 Error [Video] (文档 ID 396940.1) 文档内容 用途   常见 Bug 问题和答案   在 SGA 池中内存是如何分配和释放的?   什么是子池(Subpools)?   什么是保留区域?   SGA 中的各池的作用是什么?   ORA-4031 错误是什么?   我的保留区域大小是否合适

Systemtap examples, Identifying Contended User-Space Locks

本文的例子 可用于判断程序性能问题是否由于futex锁冲突引起的. This section describes how to identify contended user-space locks throughout the system within a specific time period. The ability to identify contended user-space locks can help you investigate poor program performa

检查Oracle数据库中不合理的sql语句

oracle|数据|数据库|语句 代码: select sql_text ,sharable_mem from v$sql where sharable_mem > '100000' order by sharable_mem ; 上面的sql语句是查询shared pool中占用内存超过100K的sql语句. 这个sql可以非常有效的检查出Oracle shared pool中那些严重占用内存的sql,根据我的经验,绝大多数有问题的sql语句都会在这里留下痕迹,通过在这里找出有问题的sql语句

Informix 5.0 for OpenServer安装

1. 建立informix组.informix用户: 2. 修改informix用户的$HOME/.profile文件,加入: INFORMIXDIR=/usr/informix (informix的主目录) PATH=$PATH:$INFORMIXDIR/bin export INFORMIXDIR export PATH 3.修改系统核心参数, #vi /etc/conf/cf.d/mtune 将"MAXUMEM"参数所在行的最后一列的值"524287"改为&q