Re: DB Block Buffers - Too Much ???

Gaja,

Sunworld has a good series of articles on memory.

This one has a good explanation of ISM.

http://www.sunworld.com/swol-09-1997/swol-09-insidesolaris.html

Jared

On Thu, 22 Jun 2000, Gaja Krishna Vaidyanatha wrote:

> David,
>
> Thanks for your e-mail and your clarification. I stand
> corrected. I distinctly remember reading about this around the
> 1995 timeframe(during the Sparc 2000 days) and speaking to an
> individual an a Sun Solution Center in "The Valley" about this.
> Unfortunately, I don't remember his name, but so much for
> that...;-)
>
> He had very clearly explained to me how the algorithm touched
> the pages in the page table, so that the pages do not get paged
> out, due to the natural progression of pages to the bottom of
> the "least recently used" list of the page table.
>
> Anyhow, the important thing is correct dissemination of
> information and I appreciate you for taking the time to write to
> me about how this feature currently/correctly works. I am
> copying the list members so that they can benefit from your
> message.
>
> Thanks again,
>
> Gaja.
>
> --- David Miller <djm_at_oregon.West.Sun.COM> wrote:
> > Hi Gaja,
> >
> > Just so you know, the USE_ISM mechanism doesn't do anything to
> > "touch" pages to keep them in memory on Solaris. It actually
> > uses a different parameter to the shm_create command (see the
> > man page) to use the SHARED_MMU value.
> > The physical memory is allocated at the time the segment is
> > created and will not be paged out. (It can be all swapped
> > out, but that'll only happen under extreme memory pressure and
> > if you get there, your performance has already degraded
> > significantly).
> >
> > One other advantage of this USE_ISM parameter is that the
> > memory segments have a common physical and virtual address in
> > all processes that access them, meaning the cache on the
> > individual processors doesn't have to change when different
> > processes are executed on them. This can be a big win in
> > performance, since Oracle does so much work in the SGA and
> > this is common among all the processors.
> >
> > A final advantage is that beginning in Solaris 2.6, the pages
> > used for ISM memory are larger, i.e. 4M instead of 8K.
> > Because the Sparc processors have a page table for physical
> > pages they can access, being able to use these larger pages
> > means that fewer entries can be taken up for the
> > SGA which can also help performance, sometimes up to 20% or
> > higher.
> >
> > As you mentioned there were bugs related to this, but I
> > believe they have been> all resolved with latest bugfixes.
>
> >
> > Hope this helps.
> >
> > Dave Miller
> > Sun Microsystems, Inc.
> >
>
> --- Gaja Krishna Vaidyanatha <gajav_at_yahoo.com> wrote:
> > Sean,
> >
> > The answer to your question is yes. One can and should lock
> > the
> > SGA in memory to prevent even preemptive paging (let alone
> > swapping or process deactivation) from occuring on the pages
> > belonging to the SGA. This however should to be done, only
> > after the memory allocation for the SGA is done in a prudent
> > fashion, keeping in mind total memory, memory needed for PGAs
> > (based on sizing of sort_area_size, hash_area_size etc.), and
> > memory needed for the O-S and other applications (if
> > applicable).
> >
> > Waleed Khedr has already talked about how to do it on Solaris
> > using the USE_ISM parameter, which basically uses an algorithm
> > that "touches" the entries in the page-table periodically, to
> > basically fake usage of all memory pages. There are however a
> > number of bugs logged with respect to this feature on Solaris,
> > so use it after you have determined whether the bug is
> > relevant
> > on your version of Oracle, version of Solaris, and your
> > platform. There were some severe ISM-related bugs on the
> > E-10K
> > platform, so watch out.
> >
> > On other platforms like HP-UX, you need to grant the MLOCK
> > privilege to dba:oracle by executing the userprivgrp command
> > or
> > something to that effect ( do a man -k priv and you will see
> > the
> > command I am talking about). After granting that privilege,
> > you
> > will then need to set the MLOCK_SGA, LOCK_SGA or relevant
> > parameter in the init.ora. Please check what the actual
> > parameter is on your system - by doing a "show parameter lock"
> > or "show parameter sga" inside svrmgrl.
> >
> > On some of the systems that I have worked with, I have seen
> > paging and swapping actually drop to negligible levels after
> > locking the SGA in memory. If the memory sizing and
> > allocation
> > for a system is done right, locking the SGA in memory will
> > provide a definite boost to overall system performance.
> >
> > Hope that helps,
> >
> > Gaja.
> >
> > --- sean.hull_at_pobox.com wrote:
> > >
> > > On Wed, 21 Jun 2000, Gaja Krishna Vaidyanatha wrote:
> > >
> > > > If overallocation is done, and if a significant portion of
> > > your
> > > > SGA is getting paged/swapped out, then you will experience
> > a
> > > > system-wide degradation in performance. Goes to prove
> > that
> > > > cache hit ratios by themselves cannot validate that Oracle
> > > is
> > > > running and functioning optimally. They are just one of
> > the
> > > > indicators for performance. You really have to look at
> > the
> > > > "amount of work done" or "throughput" on the system and
> > > measure
> > > > the success of your tuning efforts.
> > >
> > > Gaja:
> > >
> > > Your comments on buffer cache hitratios vs OS statistics
> > such
> > > as swapping
> > > are excellent as usual Gaja.
> > >
> > > It brings up a question in my mind though. As I recall, one
> > > very good
> > > system administrator who I used to work with explained to me
> > > that certain
> > > segments of the SGA seemed to be marked as not-swappable by
> > > Oracle. This
> > > would certainly leave plenty of room for important
> > components
> > > of the
> > > Oracle or OS software to be swapped out of memory.
> > >
> > > The question: Can segments of shared memory be marked by an
> > > application
> > > as non-swappable, and does Oracle do this? Anybody know, or
> > > have pointers
> > > to good documents?
> > >
> > > Thanks,
> > > Sean
> > >
> > > --
> > > Author:
> > > INET: sean.hull_at_pobox.com
> > >
> > > Fat City Network Services -- (858) 538-5051 FAX: (858)
> > > 538-5051
> > > San Diego, California -- Public Internet access /
> > > Mailing Lists
> > >
> >
> --------------------------------------------------------------------
> > > To REMOVE yourself from this mailing list, send an E-Mail
> > > message
> > > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru')
> > > and in
> > > the message BODY, include a line containing: UNSUB ORACLE-L
> > > (or the name of mailing list you want to be removed from).
> > > You may
> > > also send the HELP command for other information (like
> > subscribing).
> >
> >
> > =====
> > Gaja Krishna Vaidyanatha | gajav_at_yahoo.com
> > Brio Technology | (972)-304-1170
> >
> > "Opinions and views expressed are my own and not of Brio
> > Technology"
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Send instant messages with Yahoo! Messenger.
> > http://im.yahoo.com/
> > --
> > Author: Gaja Krishna Vaidyanatha
> > INET: gajav_at_yahoo.com
>
>
> =====
> Gaja Krishna Vaidyanatha | gajav_at_yahoo.com
> Brio Technology | (972)-304-1170
>
> "Opinions and views expressed are my own and not of Brio Technology"
>
> __________________________________________________
> Do You Yahoo!?
> Get Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
> --
> Author: Gaja Krishna Vaidyanatha
> INET: gajav_at_yahoo.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
Received on Fri Jun 23 2000 - 11:53:32 CDT