Re: Fighting Words? Shared Pool Size

Hi Steve and Ross,

My 'subheap thrashing' was observed within a Tuxedo environment, which i I have mentioned before. What we were seeing, was the 'session memory' portion of the Shared Pool (which holds the PGA in a Tuxedo / MTS environment) was growing excessively and was starving the 'sql area' and 'library cache' portions of the Shared Pool. We also saw the 'free memory' value go negative, as part of this system (Not sure what a minus 97K of 'free memory' actually means though).

I don't think that this will cause a problem, without Tuxedo or MTS, since the PGA will be held on the client or in the shadow process on Unix in these circumstances.

BTW - I have never looked in to the x$kghlu or x$ksmlru.

Andrew

Steve Adams wrote:

> Hi Ross,
>
> In my opinion x$ksmlru is scarcely worth the bytes it is stored in. If you
> have ever tried to correlate flushes in x$kghlu with x$ksmlru you will know
> what I mean. Most flushes are missed by x$ksmlru entirely. In fact it is only
> guaranteed that the 9th row represents the single largest load requiring a
> flush. You can say nothing else definitive about the other rows, so they may
> as well not be there. Also you cannot use x$ksmlru as an input to a keep
> script because it does not give you the address of the object handle, only
> its hash value.
>
> I am also waiting to hear what Andrew has to say about what I would call
> subheap thrashing (because the term namespace should be reserved for the
> library cache). From my understanding of how shared pool management works
> (such as it is at the moment) I am sceptical that anything that Andrew has
> observed in this regard can be anything more than coincidental. But, who
> knows ...
>
> Regards,
> Steve Adams
>
> ----------
> In article <7fjh4d$8q1_at_sjx-ixn5.ix.netcom.com>,
> "Ross Mohan" <postmaster_at_127.0.0.1> wrote:
> > Glad i didn't have to cross light sabers with you, Obi Wan. <g>
> >
> > The only icing i could add to this is to develop a nightly, dynamic pin
> > script
> > based on loads, footprint, etc. from x$ksmlru ( ?think i got that right?)
> > and
> > row cache, shared pool, and library cache latch activity. I'd love to learn
> > more about the latch parent/child behavior, but don't know quite where to
> > dip the stick in the river....also liked Andrew Babb's comments about
> > (what i'll dub) namespace thrashing and i will be taking a look at that.
> >
> > thanks all.
> >
> > Steve Adams wrote in message <7fhvdv$ioh$1_at_nnrp1.dejanews.com>...
> > >Hi Guys,
> > >
> > >I believe that Ross is on the right track here. I've fought this battle
> > >several times. We have a 1400 connected (300 active) user system that only
> > >needs 50M of shared pool. Most shared pool latch contention comes down to
> > >long lists of chunks on the first and second free list buckets, and most
> > >library cache latch contention comes down to long collision chains hanging
> > >off the hash table. I'd go so far as to say, keep everything of value and
> > >flush the pool routinely.
> > >
> > >Regards,
> > >Steve Adams
> > >
> > >----------
> > >In article <7fh5ee$et3_at_dfw-ixnews12.ix.netcom.com>,
> > > "Ross Mohan" <postmaster_at_127.0.0.1> wrote:
> > >> >cursor_space_for_time will nearly always end up with a large shared
> > >> >pool.
> > >>
> > >> || I guess i was making the point that the pool was fixed, and too
> > large.
> > >> and that CSFT wasn't helping things by forcing additional pool mgmt
> > >>
> > >> As to what defines a large shared pool depends heavily on the
> > >> >number of applications that the instance has to support. After sizing
> > >> >exercises, I've ended up with Shared Pools ranging from about 20Mb's
> > >> >upto about 400Mb's. Both were about the correct size for the job they
> > >> >were being asked to perform.
> > >>
> > >> || Number of apps and users, plus considerations of pinning, reuse,
> > >> bindvars
> > >> versus not. I haven't ever seen the need ( up to, say, about 500
> > >> concurrent, busy
> > >> thin-client users, multiple apps ) to have a pool larger than 150MB.
> > On
> > >> your
> > >> machine with the 400MB pool, how many users did you have, and was it
> > >> something like an AR/AP or GL setup?
> > >>
> > >> >
> > >> >I think the important thing is that you don't see to much stealing of
> > >> >space from one object class (library cache, dictionary cache, sql area)
> > >> >to fund another. Keep an eye on the v$sgastat output over the course of
> > >> >time.
> > >>
> > >> || This is interesting. Have you experimented at all with monitoring
> > space
> > >> swapping between namespaces in the lib cache, and did you see
> > anything
> > >> there? Thinking about this will be useful, i believe....thanks for
> > >> the thoughts Andrew
> > >>
> > >>
> > >
> > >-----------== Posted via Deja News, The Discussion Network ==----------
> > >http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
> >
> >
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Received on Wed Apr 21 1999 - 08:08:58 CDT