RE: 11g AMM tmpfs vs hugepages for best overall performance

  • From: "Crisler, Jon" <Jon.Crisler@xxxxxxx>
  • To: "Tanel Poder" <tanel@xxxxxxxxxx>
  • Date: Wed, 28 Jul 2010 11:48:00 -0400

Thanks Tanel- I read your blog on the subject as well.  I thought the
bug you reported was caused by the limits.conf issue ?

 

From: Tanel Poder [mailto:tanel@xxxxxxxxxx] 
Sent: Wednesday, July 28, 2010 11:45 AM
To: Crisler, Jon
Cc: ora_kclosson@xxxxxxxxx; howard.latham@xxxxxxxxx;
oracle-l@xxxxxxxxxxxxx
Subject: Re: 11g AMM tmpfs vs hugepages for best overall performance

 

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: