ITPub博客

首页 > 数据库 > Oracle > Oracle Memory Management and HugePage (连载三)

Oracle Memory Management and HugePage (连载三)

原创 Oracle 作者:沃趣科技 时间:2016-04-18 11:07:43 1 删除 编辑

作者:沃趣科技高级数据库工程师  魏兴华 



Transparent Hugepage

RedHat6, RedHat7, OL6, OL7 SLES11 UEK2 kernels开始transparent hugepage被默认开启,它允许大页做动态的分配,而不是系统启动后就分配好,根据Oracle MOS DOC1557478.1transparent hugepage导致了很多的问题,建议将其关闭 查看是否启用了transparent hugepage cat /sys/kernel/mm/transparent_hugepage/enabled [always] never []内的值是当前启用的值,上面的输出说明启用了transparent hugepage 可以通过 /etc/grub.conf 文件来关闭transparent hugepage



通过增加关键字transparent_hugepage=never来讲transparent hugepage关闭。 也可以通过开机启动后,echo相应的值到对应的文件来动态关闭transparent hugepage



OS层面查看大页使用情况



HugePages_Total为所分配的页面数目,和Hugepagesize相乘后得到所分配的内存大小。43000*2/1024大约为84GB

HugePages_Free为从来没有被使用过的Hugepages数目。即使Oracle sga已经分配了这部分内存,但是如果没有实际写入,那么看到的还是Free的。这是很容易误解的地方。

HugePages_Rsvd为已经被分配预留但是还没有使用的page数目。在Oracle刚刚启动时,大部分内存应该都是Reserved并且Free的,随着Oracle SGA的使用,ReservedFree都会不断的降低。

HugePages_Free – HugePages_Rsvd 这部分是没有被使用到的内存,如果没有其他的Oracle instance,这部分内存也许永远都不会被使用到,也就是被浪费了。在该系统上有11.5GB的内存被浪费了。

最佳实践

对于Oracle来说,这是一个最佳实践泛滥的时代,所有的最佳实践其实都有特定的应用场景,而不是放之四海皆准,但是当今信息爆炸时代(数据库种类爆炸时代),很多DBA没有那么多的耐心去专注学习一门数据库,只是拿来主义从网上找出一些最佳实践来,不管三七二十一就用到自己的环境中(甚至是生产环境中),一定程度上来说,崇拜最佳实践是懒惰的结果。

针对于Oracle的内存分配方式,肉丝给大家推荐在核心系统上: 1.使用手工的SGA管理,这种管理方式已经非常的成熟,但是这种方式对DBA要求较高,一定程度上需要了解业务特点。 2.如果第一种方法你感觉到比较难,那么使用ASMM,但是为buffer cache,shared pool设定最小值的方式,这种方式是我非常推荐的方式。

至于AMM这种内存分配方式,由于不能使用大页,建议不要去用。

具体到内存如何分配,针对是OLTP场景,还是OLAP场景,有着不同的内存分配原则,即使是OLTP场景,针对进程数的多少,并发数的多少,SQL语句的特点,都会导致产生不同的内存分配方法。作为DBA要掌握基本的Oracle内存使用原理,然后根据实际情况去根据业务自身特点分配内存。

不管是OLTP系统或者OLAP系统,一般都建议至少为操作系统预留出20%的内存空间,这些内存空间用于kernalpage table以及一些其他的进程需要,例如rman备份,文件系统缓存。这个也是Oracle官方的建议。

把这一部分的内存刨去后,针对OLTP系统,可以考虑先尝试预留出20%的内存给PGA使用,80%的内存给SGA使用。如果系统上进程数比较多,特别是同时活跃的进程数比较多,需要给PGA预留出更多的内存,可以按照每个进程12MPGA占用进行计算。

针对OLAP系统,刨去操作系统的预留内存后,可以考虑预留出50%的内存给PGA使用,50%的内存给SGA使用。毕竟在纯OLAP下,buffer cache其实不需要那么大的内存空间。

SGAPGA分配好后,要考虑到是否需要为buffer cacheshared pool来手工设定一个值,就像上文已经提到过的,可以参考buffer cache 的命中率,Library Hit的命中率作为一个辅助参考.如果命中率较低,有可能是内存分配的不够合理。当然你还需要借助于像AWR报告这样的工具,根据SQL的执行计划等内容来进一步的做诊断,比如命中率低的原因可能不是分配的buffer cache小,而是存在大量的低效的全表扫描,进而导致命中率低,这样的话,需要优化的就是SQL,而不是继续加大buffer cache。再比如,如果你发现Library cache Hit比较低,可能并不是shared pool比较小,还可能是系统的SQL存在大量未使用绑定变量的情况,导致硬解析过重。

优化经常是个系统工程,不能一蹴而就,特别像Oracle是一个很庞大的复杂系统,对于问题的出现,更是要仔细推敲,不能轻易的下结论。随着做DBA时间越来越长,你也会越来越懂TOM的一句话:It depends

关于作者

魏兴华,沃趣科技高级技术专家,主要参与公司一体机产品、监控产品、容灾产品、DBaaS平台的研发和设计。曾就职于东软集团,阿里巴巴集团,Oracle ACE组成员,DBGEEK 用户组发起人,ITPUB认证博客专家,ACOUGSHOUG核心成员。曾在Oracle技术嘉年华、ORCL-CONYY分享平台等公开场合 多次做过数据库技术专题分享。对Oracle 并行机制、数据库异常恢复方法、ASM等有深入的研究,人称”Oracle Internal达人,对企业数据库架构设计、故障恢复、高并发下数据库性能调优有丰富的经验,擅长从等待时间角度分析解决数据库性能问题,是OWI方法论的提倡者和践行者。

个人邮箱: xinghua.wei@woqutech.com

DB GEEK QQ :516293316

公司主页:www.woqutech.com

其它白皮书

SQL MONITOR: http://pan.baidu.com/s/1gfO2DtL

Parallel原理实现: http://pan.baidu.com/s/1i5xun9F

12C IN-MEMORY http://pan.baidu.com/s/1ge7r1oZ

(全文完结



来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/28218939/viewspace-2083183/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
杭州沃趣科技股份有限公司创建于2012年(股票代码:839849),是一家专注为企业用户提供基于高性能、高可用、可扩展的开放数据库云平台解决方案的国产厂商。公司创始团队为原阿里巴巴数据库技术团队核心骨干,凭借丰富的研发及运维经验,为行业客户提供数据库云产品及软硬件一体化解决方案。

注册时间:2016-07-18

  • 博文量
    219
  • 访问量
    659677