******************************************************************
今天遇到一个系统问题,系统内存不足,但是用VMSTAT 那些命令看,又看不到哪个进程在占用内存。搞了很久没找到原因,后来是因为这个系统配置了hugepage,给账号weblogic 分配了几个G的内存,导致系统内存不足的原因,下面来详细介绍下hugepage的配置方法。
******************************************************************
/etc/security/limits.conf:
weblogic soft memlock 6291456 (物理内存总和减2G) x*1024*1024
weblogic hard memlock 6291456
/etc/sysctl.conf:
kernel.shmmax = 7516192768 (cat /proc/meminfo | grep MemTotal:kb x 1024,可设为物理内存大小)
这个值必须大于hugepage小于物理内存 x*1024*1024*1024
vm.hugetlb_shm_group = 500
vm.nr_hugepages = 2560 (5G)
groupadd -g 500 hugepage
usermod -G hugepage weblogic (将hugepage作为weblogic的次要组)
grep -i hugepage /proc/meminfo
Hugepage、VLM、SGA和Share memory
由于新数据库环境使用了一些VLM、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内存是共享内存,它会一直pin在内存中的,不会被交换出去,也就是说使用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显示的大小基本一致)