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

  • From: Chris Taylor <christopherdtaylor1994@xxxxxxxxx>
  • To: exriscer@xxxxxxxxx
  • Date: Wed, 16 Apr 2014 12:50:24 -0500

You can however cross reference the files - each file ends in a number -
that number maps to shmid:

ipcs -ma
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 1867776    oracle     640        4096       0
0x00000000 1900545    oracle     640        4096       0
0x58538854 1933314    oracle     640        4096       0
0x00000000 2064388    oracle     640        4096       0
0x00000000 2097157    oracle     640        4096       0
0x90459e34 2129926    oracle     640        4096       0


Those shmids will map to your JOX files - so you can string together a list
like this:

(The numbers that I'm excluding in the egrep -v match the shmids above)

ls -la /dev/shm | egrep -v "1867776|1900545|1933314|2064388|2097157|2129926"

If any files are returned they should be orphaned and not in use.

I think Cheng hit the nail on the head - those may be non-asm related files
in this case.

Regards,
Chris


On Wed, Apr 16, 2014 at 12:42 PM, Ls Cheng <exriscer@xxxxxxxxx> wrote:

> By the way my customer DBA was removing these JOX files manually using rm
> in Solaris and he had to reboot the instance because whent hose files are
> removed when the instance is online all java calls in the database failed
> with core dump so dont try to remove them manually!
>
>
>
>
> On Wed, Apr 16, 2014 at 7:38 PM, Ls Cheng <exriscer@xxxxxxxxx> wrote:
>
>> Hi
>>
>> I have seen those files in Solaris but in /tmp. It wass generated by JIT,
>> Java In Time Compiler in my case, not sure if it applies in your case.
>> Seems like it can be PL/SQL native compiled as well, since your are using
>> EBS it might be the case? It has nothing to do with AMM or ASMM
>>
>> But look these notes
>>
>> /dev/shm Filled Up With Files In Format JOXSHM_EXT_xxx_SID_xxx (Doc ID
>> 752899.1)
>>
>> Stale Native Code Files Are Being Cached with File Names Such as:
>> JOXSHM_EXT*, PESHM_EXT*, PESLD* or SHMDJOXSHM_EXT* (Doc ID 1120143.1)
>> Ora-7445 [Ioc_pin_shared_executable_object()] (Doc ID 1316906.1)
>>
>> Regards
>>
>> On Wed, Apr 16, 2014 at 5:47 PM, Mark Bobak <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.
>>>
>>>  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
>>>
>>
>>
>

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 04-2014