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

From: Andrew Kerber <andrew.kerber_at_gmail.com>
Date: Thu, 17 Apr 2014 16:16:08 -0500
Message-ID: <CAJvnOJYtxajV6djVaDXdR5sVwDVdvbamJz+Vt93Fiu=hDD5U8A_at_mail.gmail.com>



The usage is the same with regard to amm/asmm i dont know about the /dev/shm issue.

On Thu, Apr 17, 2014 at 4:11 PM, Saad Khan <saad4u_at_gmail.com> wrote:

> Nice thread but how about AIX where we've "large pages"?
>
>
> On Wed, Apr 16, 2014 at 5:56 PM, Cunningham, Mike <
> mcunningham_at_thedoctors.com> wrote:
>
>> Thanks guys. This is very educational (and enjoyable) for the OP and
>> the rest. Any day something new can be learned is a great day.
>>
>>
>>
>> *Michael Cunningham*
>> *Senior Database Administrator*
>> *The Doctors' Company*
>> 707.226.0221 - desk
>> 707.337.0184 - cell
>>
>>
>>
>> *From:* Ls Cheng [mailto:exriscer_at_gmail.com]
>> *Sent:* Wednesday, April 16, 2014 10:54 AM
>> *To:* Cunningham, Mike
>> *Cc:* Mark Bobak; Chris.Ruel_at_lfg.com; oracle-l_at_freelists.org
>>
>> *Subject:* Re: Question about hugepages, shared memory, and /dev/shm....
>>
>>
>>
>> Hi
>>
>> sga_target is compatible with hugepages, no matter 10g or 11g. I have
>> been using it since 10g
>>
>> Regards
>>
>>
>>
>> On Wed, Apr 16, 2014 at 7:49 PM, Cunningham, Mike <
>> mcunningham_at_thedoctors.com> wrote:
>>
>> Hi Mark, thanks for explanation. Now I’m really confused and once again
>> faced with questioning my understanding. I could have sworn I read that
>> 10g AMM was not compatible with huge pages, but I can’t find my notes with
>> a quick glance. Looks like I have another reading assignment.
>>
>>
>>
>> *Michael Cunningham*
>> *Senior Database Administrator*
>> *The Doctors' Company*
>> 707.226.0221 - desk
>> 707.337.0184 - cell
>>
>>
>>
>> *From:* Mark Bobak [mailto:Mark.Bobak_at_proquest.com]
>> *Sent:* Wednesday, April 16, 2014 10:20 AM
>>
>>
>> *To:* Cunningham, Mike; Chris.Ruel_at_lfg.com; oracle-l_at_freelists.org
>>
>> *Subject:* Re: Question about hugepages, shared memory, and /dev/shm....
>>
>>
>>
>> Hi Mike,
>>
>>
>>
>> AMM (Automatic Memory Management), which is setting memory_target and
>> letting Oracle manage both SGA and PGA from that chunk of memory, is only
>> available in 11g, and *not* compatible with hugepages.
>>
>> ASMM (Automatic Shared Memory Mangement), which is setting sga_target and
>> pga_aggregate_target, is available in 10g, and is compatible with hugepages.
>>
>>
>>
>> My understanding was that /dev/shm segments and hugepages were mutually
>> exclusive…but perhaps not?
>>
>>
>>
>> Anyhow, I’m seeing ASMM + hugepages + segments in /dev/shm, which I
>> thought wasn’t possible.
>>
>>
>>
>> -Mark
>>
>>
>>
>> *From: *<Cunningham>, Mike <mcunningham_at_thedoctors.com>
>> *Date: *Wednesday, April 16, 2014 at 1:13 PM
>> *To: *"Chris.Ruel_at_lfg.com" <Chris.Ruel_at_lfg.com>, Mark Bobak <
>> Mark.Bobak_at_ProQuest.com>, "oracle-l_at_freelists.org" <
>> oracle-l_at_freelists.org>
>> *Subject: *RE: Question about hugepages, shared memory, and /dev/shm....
>>
>>
>>
>> For what it’s worth. While using AMM with huge pages the instance in my
>> environment crashed on occasion during memory resizing. That was on
>> version 10.2.0.3 with Linux 5.7 (x86_64).
>>
>>
>>
>> I did not pay attention to the /dev/shm so I can’t offer anything there.
>> Also, learning from my past errors, I have never tried AMM in 11g with huge
>> pages.
>>
>>
>>
>> *Michael Cunningham*
>> *Senior Database Administrator*
>> *The Doctors' Company*
>> 707.226.0221 - desk
>> 707.337.0184 - cell
>>
>>
>>
>> *From:* oracle-l-bounce_at_freelists.org [
>> mailto:oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org>] *On
>> Behalf Of *Ruel, Chris
>> *Sent:* Wednesday, April 16, 2014 8:59 AM
>> *To:* Mark.Bobak_at_proquest.com; oracle-l_at_freelists.org
>> *Subject:* RE: Question about hugepages, shared memory, and /dev/shm....
>>
>>
>>
>> I don’t know if you have come across this MOS doc yet but it’s pretty
>> good at explaining some things relating to HP’s:
>>
>>
>>
>> Oracle Support Document 361323.1 (HugePages on Linux: What It Is... and
>> What It Is Not...) can be found at:
>> https://support.oracle.com/epmos/faces/DocumentDisplay?id=361323.1
>>
>> I would also add that depending on the version of Linux, you need to
>> disable Transparent Huge pages for OEL6...at least we did. Look at the
>> referenced documents at the bottom and there is an article on this. If you
>> don’t disable THP’s, it can cause problems in RAC environments.
>>
>>
>>
>> For your questions below, your understanding correct for #1 and #2. I *
>> *think** you are correct on #3 and #4 but I have not dove in that far
>> myself...have left it up to sysadmins to make sure it works...
>>
>>
>>
>> Chris..
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Chris Ruel * Oracle Database Administrator
>>
>> cruel_at_lfg.com * Desk:317.759.2172 * Cell 317.523.8482
>>
>>
>>
>> *From:*oracle-l-bounce_at_freelists.org [
>> mailto:oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org>] *On
>> Behalf Of *Mark Bobak
>> *Sent:* Wednesday, April 16, 2014 11:47 AM
>> *To:* oracle-l_at_freelists.org
>> *Subject:* Question about hugepages, shared memory, and /dev/shm....
>>
>>
>>
>> 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
>>
>> Notice of Confidentiality: **This E-mail and any of its attachments may
>> contain
>> Lincoln National Corporation proprietary information, which is
>> privileged, confidential,
>> or subject to copyright belonging to the Lincoln National Corporation
>> family of
>> companies. This E-mail is intended solely for the use of the individual
>> or entity to
>> which it is addressed. If you are not the intended recipient of this
>> E-mail, you are
>> hereby notified that any dissemination, distribution, copying, or action
>> taken in
>> relation to the contents of and attachments to this E-mail is strictly
>> prohibited
>> and may be unlawful. If you have received this E-mail in error, please
>> notify the
>> sender immediately and permanently delete the original and any copy of
>> this E-mail
>> and any printout. Thank You.**
>>
>>
>>
>> *Confidentiality Notice*: This message and any attachments hereto may
>> contain confidential and privileged communications or information and/or
>> attorney client communications or work-product protected by law. The
>> information contained herein is transmitted for the sole use of the
>> intended recipient(s). If you are not the intended recipient or designated
>> agent of the recipient of such information, you are hereby notified that
>> any use, dissemination, copying or retention of this e-mail or the
>> information contained herein is strictly prohibited and may subject you to
>> penalties under federal and/or state law. If you received this e-mail in
>> error, please notify the sender immediately and permanently delete this
>> e-mail.
>>
>>
>>
>> *Confidentiality Notice*: This message and any attachments hereto may
>> contain confidential and privileged communications or information and/or
>> attorney client communications or work-product protected by law. The
>> information contained herein is transmitted for the sole use of the
>> intended recipient(s). If you are not the intended recipient or designated
>> agent of the recipient of such information, you are hereby notified that
>> any use, dissemination, copying or retention of this e-mail or the
>> information contained herein is strictly prohibited and may subject you to
>> penalties under federal and/or state law. If you received this e-mail in
>> error, please notify the sender immediately and permanently delete this
>> e-mail.
>>
>>
>>
>>
>>
>> *Confidentiality Notice*: This message and any attachments hereto may
>> contain confidential and privileged communications or information and/or
>> attorney client communications or work-product protected by law. The
>> information contained herein is transmitted for the sole use of the
>> intended recipient(s). If you are not the intended recipient or designated
>> agent of the recipient of such information, you are hereby notified that
>> any use, dissemination, copying or retention of this e-mail or the
>> information contained herein is strictly prohibited and may subject you to
>> penalties under federal and/or state law. If you received this e-mail in
>> error, please notify the sender immediately and permanently delete this
>> e-mail.
>>
>
>

-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Apr 17 2014 - 23:16:08 CEST

Original text of this message