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

From: Mark Bobak <Mark.Bobak@xxxxxxxxxxxx>
To: Tanel Poder <tanel@xxxxxxxxxxxxxx>
Date: Fri, 18 Apr 2014 07:56:33 +0000

Thanks for the explanation, Tanel.  That makes sense.  I was pretty stumped 
when I initially saw those memory segments in /dev/shm, but that makes a lot of 
sense.

And yes, I was aware that ASM would use non-hugepage shared memory and create 
segments in /dev/shm by default.  ASM instances are the one exception to my 
mantra, "If you're not using hugepages, you're doing it wrong!". :-)

Thanks!

-Mark

From: Tanel Poder <tanel@xxxxxxxxxxxxxx<mailto:tanel@xxxxxxxxxxxxxx>>
Date: Friday, April 18, 2014 at 3:42 AM
To: Mark Bobak <Mark.Bobak@xxxxxxxxxxxx<mailto:Mark.Bobak@xxxxxxxxxxxx>>
Cc: "oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>" 
<oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>>
Subject: Re: Question about hugepages, shared memory, and /dev/shm....

If you are wondering why the heck Oracle needs such files at all - it was 
already hinted in a different reply - the JOX files are related to in-database 
JVM JIT compilation (JOX is the java module name prefix in Oracle kernel).

So it's not SGA, it's just how Oracle executes the JIT compiled stuff. The 
reason for these files is that if you compile something to native code and want 
to let the CPU to natively execute that binary code, you will need to map that 
code into a memory segment in that process, with proper permission bits 
(usually r-x for that shared mem segment).

So the Java JIT compiler in a process will generate the binary code, save it 
into a (JOX..) file and mmap it into its own address space for execution, 
somewhat like a dynamic library...


Btw, another (simple) reason why /dev/shm files may show up when you've 
disabled it for your database instance is the ASM instance... but in this case 
you'd see /dev/shm/ora_+ASM_* files not the JOX ones...

--
Tanel Poder
Enkitec (The Exadata Experts)
Services<http://enkitec.com> | Training<http://blog.tanelpoder.com/seminar/> | 
Troubleshooting<http://blog.tanelpoder.com/> | Exadata 
Book<http://www.amazon.com/Expert-Oracle-Exadata-Apress/dp/1430233923>



On Wed, Apr 16, 2014 at 10:47 AM, Mark Bobak 
<Mark.Bobak@xxxxxxxxxxxx<mailto:Mark.Bobak@xxxxxxxxxxxx>> wrote:
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.

References:
- Question about hugepages, shared memory, and /dev/shm....
  - From: Mark Bobak
- Re: Question about hugepages, shared memory, and /dev/shm....
  - From: Tanel Poder

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

Other related posts: