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

  • From: Ls Cheng <exriscer@xxxxxxxxx>
  • To: mcunningham@xxxxxxxxxxxxxx
  • Date: Wed, 16 Apr 2014 19:53:43 +0200

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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxx]
> *Sent:* Wednesday, April 16, 2014 10:20 AM
>
> *To:* Cunningham, Mike; Chris.Ruel@xxxxxxx; oracle-l@xxxxxxxxxxxxx
> *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@xxxxxxxxxxxxxx>
> *Date: *Wednesday, April 16, 2014 at 1:13 PM
> *To: *"Chris.Ruel@xxxxxxx" <Chris.Ruel@xxxxxxx>, Mark Bobak <
> Mark.Bobak@xxxxxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx
> >
> *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@xxxxxxxxxxxxx [
> mailto:oracle-l-bounce@xxxxxxxxxxxxx <oracle-l-bounce@xxxxxxxxxxxxx>] *On
> Behalf Of *Ruel, Chris
> *Sent:* Wednesday, April 16, 2014 8:59 AM
> *To:* Mark.Bobak@xxxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
> *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@xxxxxxx * Desk:317.759.2172 * Cell 317.523.8482
>
>
>
> *From:*oracle-l-bounce@xxxxxxxxxxxxx 
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx<oracle-l-bounce@xxxxxxxxxxxxx>]
> *On Behalf Of *Mark Bobak
> *Sent:* Wednesday, April 16, 2014 11:47 AM
> *To:* oracle-l@xxxxxxxxxxxxx
> *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.
>

Other related posts:

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