Re: 11g AMM tmpfs vs hugepages for best overall performance
- From: Tanel Poder <tanel@xxxxxxxxxx>
- To: Jon.Crisler@xxxxxxx
- Date: Wed, 28 Jul 2010 23:45:00 +0800
I'd sure go with hugepages and disable the AMM. I'm guessing that AMM /
MEMORY_TARGET was introduced so that Oracle could compete with MS SQL server
in the "ease of use" part, but I think this feature is useless for
production systems, especially on Linux.
1) Make sure that you configure OS for hugepages properly
a) set vm.nr_hugepages kernel parameter so it would be able to hold all
the SGAs in the server
b) use proper memory locking allowance for oracle user
(/etc/security/limits.conf)
c) make sure you're not hitting the bug "9251136 INSTANCE WILL NOT USE
HUGEPAGE IF STARTED BY SRVCTL"
2) Make sure that your instance actually uses / reserves hugepages when
starting it up
grep Hugepages /proc/meminfo (before and after startup if multiple
instances in the server)
Using hugepages should give you smaller kernel memory usage (especially if
you have lots of processes) and more efficient CPU usage too as you should
have less TLB misses and the trap handling CPU overhead following that.
Unfortunately on Linux there's no trivial way for measuring that (like
prstat -m on Solaris), this also depends on the workload, YMMV...
--
Tanel Poder
http://tech.e2sn.com
http://blog.tanelpoder.com
On Wed, Jul 28, 2010 at 10:18 PM, Crisler, Jon <Jon.Crisler@xxxxxxx> wrote:
> Kevin, I read all of your blog entries, and my take on it was that you
> did not have a clear opinion on the performance advantage of 11g AMM vs.
> Linux hugepages, especially for large systems. In my case, I am working
> with RAC servers that have 96 gb of memory, dedicated to running a single
> db. The SGA and PGA combined could easily be 64gb or higher. What we plan
> to do is have a large /dev/shm (tmpfs) so we can change between hugepages
> and AMM if a direction becomes clear. In speaking with some internal folks
> at Oracle, for really large systems there seems to be a feeling that
> hugepages might have the edge. Their stance is basically that people tend
> to mess up hugepages allocations frequently, causing far worse performance
> and a support headache, while AMM is far easier to manage and has less
> chance of allowing people to shoot themselves in the foot. But if the dba
> knows how to manage hugepages, it might have a performance edge. At this
> point I don’t know what the benchmark or performance testing plan is, other
> than perhaps Swingbench against the app.
>
>
>
Other related posts:
