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

10g uses ASMM not AMM (not to be confused with ASSM or ASM!) :)

11g can use either ASMM or AMM.

Chris

On Wed, Apr 16, 2014 at 12: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.
>

--
http://www.freelists.org/webpage/oracle-l