星期一 二月 25, 2013

在Linux 64位系统下使用hugepage


首先,为什么要介绍/使用HugePage?


在步入正题之前,先讲一个非常普遍的数据库性能问题。


众所周知,Oracle数据库使用共享内存(SGA)来管理可以共享的一些资源;比如shared pool中存储了共享的SQL语句及执行计划,buffer pool中存储了数据块。对这些资源的访问,其实就是Oracle使用OSAPI来访问内存资源的过程。内存操作理应/通常意义上都是很快的,这时候Oracle数据库可以很正常的工作。


但是


a)如果SGA内的某一部分被swap到硬盘上,那么再次访问它,就需要花非常多的时间


b)如果OS本身的内存非常的大,那么管理/访问到我们需要的内存的过程就需要更长时间。


在这些情况下,我们往往会碰到诸如latch/mutex/library cache lock[pin]/row cache lock的问题.



LinuxHugePage 可以解决由以上两种问题引发的性能波动。


我们知道,在Linux 64位系统里面,默认内存是以4K的页面(Page)来管理的,当系统有非常多的内存的时候,管理这些内存的消耗就比较大;HugePage使用2M大小的页面来减小管理开销。HugePage管理的内存并不能被Swap,这就避免了swap引发的数据库性能问题。所以,如果您的系统经常碰到因为swap引发的性能问题的系统毫无疑问需要启用HugePage。另外,OS内存非常大的系统也需要启用HugePage。但是具体多大就一定需要使用HugePage?这并没有定论,有些文档曾经提到12G以上就推荐开启,我们强烈建议您在测试环境进行了充分的测试之后,再决定是否在生产环境应用HugePage



当然,任何事情都是有两面性的,HugePage也有些小缺点。第一个缺点是它需要额外配置,但是这完全是可以忽略的。另外, 如果使用了HugePage11g新特性 AMMAutomatic Memory Management)就不能使用了,但是ASMMAutomatic
Shared Memory Management
)仍然可以继续使用。


接下来,我们对配置HugePage需要完成的步骤进行介绍。以下步骤以RHEL5为例。


a) 设置memlock的限制,更改/etc/security/limits.conf加入下面的行



注意上面的数字是以 K 为单位的,可以让它的值稍微比系统的物理内存小就可以了


b) 检查memlock是否生效,要使用oracle的用户执行下面的操作,如果没有生效尝试重新登陆系统



c) 如果使用11g数据库,确认参数MEMORY_TARGETMEMORY_MAX_TARGET已经设为0


d) 启动数据库,并运行Document
401749.1
提供的脚本来计算应该分配多少HugePage页面。例如:



e) 更改/etc/sysctl.conf,把上一步得到的值指定给vm.nr_hugepages参数



f) 重启数据库和OS


g) 验证HugePage是否已启用


如下图,HugePage一共分配了1496个页面,其中有6个页面为Free,那么使用了1490个页面,每个页面为2048K.




最后,如果您想了解更多的和HugePage相关的问题,请参考以下的note


Note 361323.1 : HugePages on Linux: What It
Is... and What It Is Not...


Note 361468.1 : HugePages on Oracle Linux
64-bit 


关于这个主题,如果有后续的问题欢迎点击链接参与我们在中文社区的讨论。


About

本博客由Oracle全球技术支持中国区的工程师维护。为中文用户提供数据库相关的技术支持信息,包括常用的诊断工具、诊断方法、产品新特性、案例分析等。此外,MOS也陆续推出各类中文内容:技术通讯统一发布在Note 1529795.1 中,中文文档列表更新在Note 1533057.1 中,网上讲座请查看MOS文档 1456176.1,在"Archived"中可以下载历史的录音和文档。

Search

Archives
« 七月 2014
星期日星期一星期二星期三星期四星期五星期六
  
1
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
今天