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

From: Mark Bobak <Mark.Bobak_at_proquest.com>
Date: Fri, 18 Apr 2014 07:56:33 +0000
Message-ID: <CF765211.580DC%Mark.Bobak_at_ProQuest.com>

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_at_tanelpoder.com<mailto:tanel_at_tanelpoder.com>> Date: Friday, April 18, 2014 at 3:42 AM
To: Mark Bobak <Mark.Bobak_at_ProQuest.com<mailto:Mark.Bobak_at_ProQuest.com>> Cc: "oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org>" <oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org>> 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_at_proquest.com<mailto:Mark.Bobak_at_proquest.com>> 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.

--

http://www.freelists.org/webpage/oracle-l Received on Fri Apr 18 2014 - 09:56:33 CEST