在Linux 64位系统下使用hugepage

最新推荐文章于 2025-08-26 10:38:06 发布

转载最新推荐文章于 2025-08-26 10:38:06 发布 · 154 阅读

本文探讨了在Linux环境下如何通过使用HugePage解决Oracle数据库因内存交换导致的性能问题。介绍了HugePage的基本原理及其对提升内存访问速度的作用，并提供了详细的配置步骤。

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

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

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

但是

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

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

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

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

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

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