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

From: Chris Taylor <christopherdtaylor1994_at_gmail.com>
Date: Wed, 16 Apr 2014 12:50:24 -0500
Message-ID: <CAP79kiRHO1wB-E4dLn0xAOAFK9mOp24EwEpNtaZTuDtDE_qr3w_at_mail.gmail.com>

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_at_gmail.com> 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_at_gmail.com> 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_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.
>>>
>>> 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 - 19:50:24 CEST