about hugepage

一、相关概念
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会自动分配适当大小的内存文件作为共享内存。