博客访问： 345500
博文数量： 46
注册时间：
认证徽章：
技多不压人，一专多能！
oracle博文地址：http://blog.csdn.net/jacson_bai
ITPUB论坛APP
ITPUB论坛APP
APP发帖 享双倍积分
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Oracle
注意：HugePages和oracle AMM(自动内存管理）是互斥的，所有使用HugePages必须设置内存参数MEMORY_TARGET / MEMORY_MAX_TARGET 为0
配置HugePages的具体步骤
1、修改内核参数memlock，单位是KB，如果内存是512G，memlock的大小要稍微小于物理内存。计划lock 400GB的内存大小。参数设置为大于SGA+100MB，单位KB
#vi /etc/security/limits.conf
oracle soft memlock 0GB*
oracle hard memlock 0GB*
保存退出，参数就生效了
2、使用oracle帐号验证大小
[ora11g@ ~]#su - oracle
[ora11g@ ~]$ ulimit -a|grep lock
core file size (blocks, -c) 0
file size (blocks, -f) unlimited
max locked memory (kbytes, -l)
file locks (-x) unlimited
3、如果使用AMM内存管理，要取消改设置。MEMORY_TARGET和 MEMORY_MAX_TARGET参数设置为0
SQL> alter system reset memory_targets cope=
SQL> alter system reset memory_max_target scope=
SQL> alter system set sga_target = 288G scope=
SQL> alter system set pga_aggregate_target = 96G scope =
4、计算需要使用的hugepag大小（常用方法）
验证hugepage的大小
[root@ora11g ~]# grep Hugepagesize /proc/meminfo
Hugepagesize: 2048 kB
简单的计算原理是total SGA_MAX_SIZE(多个instance的总和）/hugepagesize + N,N为少量内存盈余，一般多出100就足够了。如果主机内存512GB，计划288GB用于SGA共享内存，
则大内存页需288×456（288×/）
5、修改vm.nr_hugepages参数,值等于第四步计算的值
参数vm.nr_hugepages指明了内存页数，如果设置大内存页为512G，则vm.nr_hugepages的大小为288G×/
vi /etc/sysctl.conf
vm.nr_hugepages = 147456
sysctl -p 命令使配置生效。
6、关闭数据库，建议完整重启主机和数据库
#grep HugePages /proc/meminfo
HugePages_Free小于HugePages_Total的值则表示设置成功。如果HugePages_Rsvd应该保持少量保留内存。
注意，HugePages如果配置不恰当会引起系统性能下降等风险，需要慎重。
小技巧：执行
#free -g,查看used选项的大小是不是288GB，就可以了
参考资料MOS文档
HugePages on Linux: What It Is... and WhatIt Is Not... [ID ]
HugePages on Oracle Linux 64-bit [ID]
阅读(1033) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。本文将分析是否Huge Page在任何条件下（特别是NUMA架构下）都能带来性能提升。
本博客已经迁移至：
为了更好的体验，请通过此链接阅读：
文章欢迎转载，但转载时请保留本段文字，并置于文章的顶部
作者：卢钧轶(cenalulu)
本文原文地址：
在阅读本文之前，需要读者至少了解以下基础知识
CPU Cache的基本概念，具体可参见 。
NUMA的基本概念，具体可参见
目前Linux基于多核CPU繁忙程度的线程调度机制，参看Chip Multi Processing aware Linux Kernel Scheduler论文
关于Huge Page
在正式开始本文分析前，我们先大概介绍下Huge Page的历史背景和使用场景。
为什么需要Huge Page
了解CPU Cache大致架构的话，一定听过TLB Cache。Linux系统中，对程序可见的，可使用的内存地址是Virtual Address。每个程序的内存地址都是从0开始的。而实际的数据访问是要通过Physical Address进行的。因此，每次内存操作，CPU都需要从page table中把Virtual Address翻译成对应的Physical Address，那么对于大量内存密集型程序来说page table的查找就会成为程序的瓶颈。所以现代CPU中就出现了TLB(Translation Lookaside Buffer) Cache用于缓存少量热点内存地址的mapping关系。然而由于制造成本和工艺的限制，响应时间需要控制在CPU Cycle级别的Cache容量只能存储几十个对象。那么TLB Cache在应对大量热点数据Virual Address转换的时候就显得捉襟见肘了。我们来算下按照标准的Linux页大小(page size) 4K，一个能缓存64元素的TLB Cache只能涵盖4K*64 = 256K的热点数据的内存地址，显然离理想非常遥远的。于是Huge Page就产生了。
Tips: 这里不要把Virutal Address和Windows上的虚拟内存搞混了。后者是为了应对物理内存不足，而将内容从内存换出到其他设备的技术（类似于Linux的SWAP机制）。
什么是Huge Page
既然改变不了TLB Cache的容量，那么只能从系统层面增加一个TLB Cache entry所能对应的物理内存大小，从而增加TLB Cache所能涵盖的热点内存数据量。假设我们把Linux Page Size增加到16M，那么同样一个容纳64个元素的TLB Cache就能顾及64*16M = 1G的内存热点数据，这样的大小相较上文的256K就显得非常适合实际应用了。像这种将Page Size加大的技术就是Huge Page。
Huge Page是万能的？
了解了Huge Page的由来和原理后，我们不难总结出能从Huge Page受益的程序必然是那些热点数据分散且至少超过64个4K Page Size的程序。此外，如果程序的主要运行时间并不是消耗在TLB Cache Miss后的Page Table Lookup上，那么TLB再怎么大，Page Size再怎么增加都是徒劳。在中就提到了这个原理，并且给出了比较详细的估算方法。简单的说就是：先通过oprofile抓取到TLB Miss导致的运行时间占程序总运行时间的多少，来计算出Huge Page所能带来的预期性能提升。
简单的说，我们的程序如果热点数据只有256K，并且集中在连续的内存page上，那么一个64个entry的TLB Cache就足以应付了。说道这里，大家可能有个疑问了：既然我们比较难预测自己的程序访问逻辑是否能从开启Huge Page中受益。反正Huge Page看上去只改了一个Page Size，不会有什么性能损失。那么我们就索性对所有程序都是用Huge Page好啦。
其实这样的想法是完全错误的！也正是本文想要介绍的一个主要内容，在目前常见的NUMA体系下Huge Page也并非万能钥匙，使用不当甚至会使得程序或者数据库性能下降10%。下面我们重点分析。
Huge Page on NUMA
一文的作者曾今做过一个实验，测试Huge Page在NUMA环境的各种不同应用场景下带来的性能差异。从下图可以看到Huge Page对于相当一部分的应用场景并不能很好的提升性能，甚至会带来高达10%的性能损耗。
性能下降的原因主要有以下两点
CPU对同一个Page抢占增多
对于写操作密集型的应用，Huge Page会大大增加Cache写冲突的发生概率。由于CPU独立Cache部分的写一致性用的是MESI协议，写冲突就意味：
通过CPU间的总线进行通讯，造成总线繁忙
同时也降低了CPU执行效率。
CPU本地Cache频繁失效
类比到数据库就相当于，原来一把用来保护10行数据的锁，现在用来锁1000行数据了。必然这把锁在线程之间的争抢概率要大大增加。
连续数据需要跨CPU读取(False Sharing）
从下图我们可以看到，原本在4K小页上可以连续分配，并因为较高命中率而在同一个CPU上实现locality的数据。到了Huge Page的情况下，就有一部分数据为了填充统一程序中上次内存分配留下的空间，而被迫分布在了两个页上。而在所在Huge Page中占比较小的那部分数据，由于在计算CPU亲和力的时候权重小，自然就被附着到了其他CPU上。那么就会造成：本该以热点形式存在于CPU2 L1或者L2 Cache上的数据，不得不通过CPU inter-connect去remote CPU获取数据。
假设我们连续申明两个数组，Array A和Array B大小都是1536K。内存分配时由于第一个Page的2M没有用满，因此Array B就被拆成了两份，分割在了两个Page里。而由于内存的亲和配置，一个分配在Zone 0，而另一个在Zone 1。那么当某个线程需要访问Array B时就不得不通过代价较大的Inter-Connect去获取另外一部分数据。
delays re-sulting from traversing a greater physical distance to reach a remote node, are not the most important source of performance overhead. On the other hand, congestion on interconnect links and in memory controllers, which results from high volume of data flowing across the system, can dramatically hurt performance.
Under interleaving, the memory latency re- duces by a factor of 2.48 for Streamcluster and 1.39 for PCA. This effect is entirely responsible for performance improvement under the better policy. The question is, what is responsible for memory latency improvements? It turns out that interleaving dramatically reduces memory controller and interconnect congestion by allevi- ating the load imbalance and mitigating traffic hotspots.
我们先谈谈理想情况。上文提到的其实他的主要目的就是讨论一种适用于NUMA架构的Huge Page自动内存管理策略。这个管理策略简单的说是基于Carrefour的一种对Huge Page优化的变种。（注：不熟悉什么是Carrefour的读者可以参看或者阅读）
下面是一些相关技术手段的简要概括：
为了减少只读热点数据跨NUMA Zone的访问，可以将读写比非常高的Page，使用Replication的方式在每个NUMA Zone的Direct内存中都复制一个副本，降低响应时间。
为了减少False Sharing，监控造成大量Cache Miss的Page，并进行拆分重组。将同一CPU亲和的数据放在同一个Page中
谈完了理想，我们看看现实。现实往往是残酷的，由于没有硬件级别的PMU(Performance Monitor Unit)支持，获取精准的Page访问和Cache Miss信息性能代价非常大。所以上面的理想仅仅停留在实验和论文阶段。那么在理想实现之前，我们现在该怎么办呢？
答案只有一个就是测试
实际测试的结果最具有说服力。所谓实际测试就是把优化对象给予真实环境的压力模拟。通过对比开启和关闭Huge Page时的性能差别来验证Huge Page是否会带来性能提升。当然大多数应用程序，要想模拟真实环境下的运行情况是非常困难的。那么我们就可以用下面这种理论测试
理论测试可以通过profile预估出Huge Page能够带来的潜在提升。具体原理就是计算当前应用程序运行时TLB Miss导致的Page Walk成本占程序总执行时间的占比。当然这种测试方式没有把上文提到的那两种性能损失考虑进去，所以只能用于计算Huge Page所能带来的潜在性能提升的上限。如果计算出来这个值非常低，那么可以认为使用Huge Page则会带来额外的性能损失。具体方法见上介绍的方法
具体的计算公式如下图：
如果没有hardware的PMU支持的话，计算需要用到oprofile和calibrator。
并不是所有的优化方案都是0性能损失的。充分的测试和对于优化原理的理解是一个成功优化的前提条件。
阅读(...) 评论()Linux 下 Hugepages的配置_Linux教程_Linux公社-Linux系统门户网站
你好，游客
Linux 下 Hugepages的配置
来源：Linux社区&
作者：wyzxg
Linux虽然没有aix，hp unix那么强悍，但Linux也是非常优秀的，为了提升Linux的性能，它采用了很多io，memory的调度机制，Linux使用内存的方式是采用vm的方式，即Linux把物理内存和swap共同虚拟成内存来对外提供，有时用户看似使用内存，可实际上是使用磁盘，那如何避免使用swap磁盘空间呢？
Linux管理内存的单位是页(pages),一般情况下是4k的page，当我们使用的大内存时(&8G),管理这么大的内存就会给系统造成很大的负担，再加上频繁的pagein/pageout，会成为系统的瓶颈。
<SPAN style="COLOR: #.hugepage介绍2.实践配置
<SPAN style="COLOR: #.hugepage介绍hugepage是在Linux2.6内核被引入的，主要提供4k的page和比较大的page的选择当我们访问内存时，首先访问”page table“，然后Linux在通过“page table”的mapping来访问真实物理内存（ram+swap）。为了提升性能，Linux在cpu中申请固定大小的buffer，被称为TLB，TLB中保存有“page table”的部分内容，这也遵循了，让数据尽可能的靠近cpu原则。在TLB中通过hugetlb来指向hugepage。这些被分配的hugepage作为内存文件系统hugetlbfs(类似tmpfs)提供给进程使用。
普通4k page
启用hugepage
hugepage特点Linux系统启动，hugepage就被分配并保留，不会pagein/pageout，除非人为干预，如改变hugepage的配置等；根据Linux内核的版本和HW的架构，hugepage的大小从2M到256M不等。因为采用大page，所以也减少TLB和page table的管理压力
为什么使用hugepage
对于大内存(&8G),hugepage对于提高在Linux上的性能是非常有帮助的&1)Larger Page Size and Less of Pages:减少了HugeTLB 的工作量&2)No Page Table Lookups：因为hugepage是不swappable的，所有就没有page table lookups。&3)No Swapping: 在Linux下，hugepage是不支持swapping&4)No 'kswapd' Operations：在Linux下进程“kswapd”是管理swap的，如果是大内存，那pages的数量就非常大，&&&&&&&&&&&&&&&&&&&&&&&&&& 那“kswapd”就会被频繁的调用，从而会影响性能。
相关资讯 & & &
& (12/03/:47)
& (08/15/:01)
& (03月08日)
& (09/06/:20)
& (04/05/:11)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款Linux HugePage 特性_Linux教程_Linux公社-Linux系统门户网站
你好，游客
Linux HugePage 特性
来源：CSDN&
作者：Robinson
HugePage，就是指的大页内存管理方式。与传统的4kb的普通页管理方式相比，HugePage为管理大内存(8GB以上)更为高效。本文描述了什么是HugePage，以及HugePage的一些特性。
1、Hugepage的引入& & 操作系统对于数据的存取直接从物理内存要比从磁盘读写数据要快的多，但是物理内存是有限的，这样就引出了物理内存与虚拟内存的概念。虚拟内存就是为了满足物理内存的不足而提出的策略，它是利用磁盘空间虚拟出的一块逻辑内存，这部分磁盘空间Windows下称之为虚拟内存，Linux下被称为交换空间(Swap Space)。
& & 对于这个大内存的管理(物理内存+虚拟内存)，大多数操作系统采用了分段或分页的方式进行管理。分段是粗粒度的管理方式，而分页则是细粒度管理方式，分页方式可以避免内存空间的浪费。相应地，也就存在内存的物理地址与虚拟地址的概念。通过前面这两种方式，CPU必须把虚拟地址转换程物理内存地址才能真正访问内存。为了提高这个转换效率，CPU会缓存最近的虚拟内存地址和物理内存地址的映射关系，并保存在一个由CPU维护的映射表中。为了尽量提高内存的访问速度，需要在映射表中保存尽量多的映射关系。
& & linux的内存管理采取的是分页存取机制，为了保证物理内存能得到充分的利用，内核会按照LRU算法在适当的时候将物理内存中不经常使用的内存页自动交换到虚拟内存中，而将经常使用的信息保留到物理内存。通常情况下，Linux默认情况下每页是4K，这就意味着如果物理内存很大，则映射表的条目将会非常多，会影响CPU的检索效率。因为内存大小是固定的，为了减少映射表的条目，可采取的办法只有增加页的尺寸。因此Hugepage便因此而来。也就是打破传统的小页面的内存管理方式，使用大页面2m,4m,16m等等。如此一来映射条目则明显减少。如果系统有大量的物理内存（大于8G），则物理32位的操作系统还是64位的，都应该使用Hugepage。
2、Hugepage的相关术语
Page Table:
& & A page table is the data structure of a virtual memory system in an operating system to store the mapping between virtual addresses and physical addresses. This means that on a virtual memory system, the memory is accessed by first accessing a page table and then accessing the actual memory location implicitly.
& & 如前所述，page table也就是一种用于内存管理的实现方式，用于物理地址到虚拟之间的映射。因此对于内存的访问，先是访问Page Table，然后根据Page Table 中的映射关系，隐式的转移到物理地址来存取数据。
& & A Translation Lookaside Buffer (TLB) is a buffer (or cache) in a CPU that contains parts of the page table. This is a fixed size buffer being used to do virtual address translation faster.
& & & CPU中的一块固定大小的cache，包含了部分page table的映射关系，用于快速实现虚拟地址到物理地址的转换。
& & This is an entry in the TLB that points to a HugePage (a large/big page larger than regular 4K and predefined in size). HugePages are implemented via hugetlb entries, i.e. we can say that a HugePage is handled by a "hugetlb page entry". The 'hugetlb" term is also (and mostly) used synonymously with a HugePage (See Note ). In this document the term "HugePage" is going to be used but keep in mind that mostly "hugetlb" refers to the same concept.
& & hugetlb 是TLB中指向HugePage的一个entry(通常大于4k或预定义页面大小)。 HugePage 通过hugetlb entries来实现，也可以理解为HugePage 是hugetlb page entry的一个句柄。
hugetlbfs:
& & This is a new in-memory filesystem like tmpfs and is presented by 2.6 kernel. Pages allocated on hugetlbfs type filesystem are allocated in HugePages.& & & 一个类似于tmpfs的新的in-memory filesystem，在2.6内核被提出。
3、常见的错误概念WRONG: HugePages is a method to be able to use large SGA on 32-bit VLM systems RIGHT: HugePages is a method to have larger pages where it is useful for working with very large memory. It is both useful in 32- and 64-bit configurations
WRONG: HugePages cannot be used without USE_INDIRECT_DATA_BUFFERS RIGHT: HugePages can be used without indirect buffers. 64-bit systems does not need to use indirect buffers to have a large buffer cache for the RDBMS instance and HugePages can be used there too.
WRONG: hugetlbfs means hugetlb RIGHT: hugetlbfs is a filesystem type **BUT** hugetlb is the mechanism employed in the back where hugetlb can be employed WITHOUT hugetlbfs
WRONG: hugetlbfs means hugepages RIGHT: hugetlbfs is a filesystem type **BUT** HugePages is the mechanism employed in the back (synonymously with hugetlb) where HugePages can be employed WITHOUT hugetlbfs.
相关资讯 & & &
& (03月04日)
& (10/26/:19)
& (10/02/:52)
& (03/27/:26)
　　　同意评论声明
　　　发表
尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任
本站管理人员有权保留或删除其管辖留言中的任意内容
本站有权在网站内转载或引用您的评论
参与本评论即表明您已经阅读并接受上述条款查看: 2554|回复: 45
请问使用HugePage性能提示明显吗?
论坛徽章:5
大内存的linux,比如64G,128G,使用HugePage和不使用对性能提升有多大呢?
现在的库都默认用的AMM,没感觉性能有多大的问题.
看到网上都说用HugePage好处多,有必要改成HugePage吗?
认证徽章论坛徽章:4
没必要，Oracle对巨页支持不好，我们优化先把它关了
论坛徽章:304
没必要，Oracle对巨页支持不好，我们优化先把它关了
你这说法，可遇上案例？
论坛徽章:116
do康解U 发表于
没必要，Oracle对巨页支持不好，我们优化先把它关了
晕…………第一次听说………
认证徽章论坛徽章:4
配置Hugepage需要先仔细阅读MOS上如下文档：
ALERT: Disable Transparent HugePages on SLES11, RHEL6, OL6 and UEK2 Kernels (Doc ID )
HugePages and Oracle Database 11g Automatic Memory Management (AMM) on Linux (Doc ID )
Hugepages Not Used when ASM is used (Doc ID )
ASM & Shared Pool (ORA-4031) (Doc ID )
Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB Configuration (Doc ID )
HugePages on Oracle Linux 64-bit (Doc ID )
如果用了RedHat 6,则要禁掉Transparent HugePages
认证徽章论坛徽章:8
嗯，linux上用到较大内存，最好用hugepage，但存在一些限制，应该注意。
论坛徽章:5
嗯，linux上用到较大内存，最好用hugepage，但存在一些限制，应该注意。
AMM岂不是废了
到底该如何取舍呢?
AMM改ASMM+hugepage对性能提升的程度使用者能明显感觉到吗??
认证徽章论坛徽章:8
AMM岂不是废了
到底该如何取舍呢?
嗯，用hugepage就别用amm了，是否有性能提升，还得看你们服务器的负载，如果负载不重，配那么大内存也是负担，不如配置小点内存，内存配置不是越大越好。
有的场景会有较大改善，有的不明显，也有更麻烦。
论坛徽章:180
本帖最后由 lfree 于
12:14 编辑
配置Hugepage需要先仔细阅读MOS上如下文档：
ALERT: Disable Transparent HugePages on SLES11, RHEL6, OL ...
》Transparent HugePages
你理解错了，rh不建议用Transparent hugepage，而不是hugepage。
Transparent 表示 透明 的意思。
透明的; 清澈的; 易识破的; 显而易见的;
论坛徽章:180
AMM岂不是废了
到底该如何取舍呢?
AMM对于大用户系统实际上问题多多，特别是你应用不绑定，抖动很厉害，
导致性能问题，我自己就遇到，
这种模式跟趋向于小用户系统。
itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有　　　　
　北京市公安局海淀分局网监中心备案编号：10　广播电视节目制作经营许可证：编号（京）字第1149号