Question about hugepages, shared memory, and /dev/shm....

  • From: Mark Bobak <Mark.Bobak@xxxxxxxxxxxx>
  • To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 16 Apr 2014 15:47:29 +0000

Hi All,

So, I thought I really understood this stuff, but I'm a little baffled here, 
and I wonder if anyone can offer me a clue?

Here's what I (think I) know:
1.)  AMM (setting memory_target) is *not* compatible with a hugepages 
configuration.  Any attempt to use hugepages will lock out the memory allocated 
to hugepages and AMM will only use non-hugepage memory allocations, the effect 
of which would be like removing the huge page allocated memory from the system.
2.)  ASMM (setting sga_target and pga_aggregate_target) and MMM (manually 
setting db_cache_size and pool sizes) *are* compatible with a hugepages 
configuration, and for any non-trivially sized SGA, hugepages is strongly 
3.)  If hugepages are *not* configured, and AMM is used, memory segments will 
be mapped in /dev/shm.
4.)  If hugepages *are* used, no memory segments will be visible in /dev/shm.

So, that's what I think is true about memory configuration and hugepages 

That seems to be consistent throughout our environment, which mostly has ASMM 
or MMM and hugepages configuration.

However, and this is where my confusion comes in, we have several eBS 
environments, which seem to have a valid and active hugepages configuration, 
are using ASMM (not AMM), and *still* I can see memory segments allocated in 
/dev/shm??  Any idea how this is possible?

Here's an example from our preprod environment:
(Content was too long for Oracle-L, so here's a paste bin URL)

So, I'm a little baffled here.  I thought these were mutually exclusive 

Note also that the timestamps on the /dev/shm segments is *after* instance 
startup time, so, I don't think these are "orphan" memory segments....

Anyone out there can clue me in?



Other related posts: