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

From: Mark Bobak <Mark.Bobak_at_proquest.com>
Date: Wed, 16 Apr 2014 15:47:29 +0000
Message-ID: <CF741D9C.57E89%Mark.Bobak_at_ProQuest.com>



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 recommended.
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 configuration.

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)

http://pastebin.com/7w2V2jEa

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

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?

Thanks,

-Mark

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Apr 16 2014 - 17:47:29 CEST

Original text of this message