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 - 07:06:34 CDT
