I didnt miss the "Fen Shui" part :-P
I was just wondering if a parameter default value configured 15 years ago
still applies for modern CPUs.
Regarding my second question anyone know? Getting a CPU twice as fast than
the old one would we be able to reduce CPU time by alf?
Regards
Alex
On 9/4/06, Stephane Faroult <sfaroult@xxxxxxxxxxxx> wrote:
>
> Alex,
>
> I am afraid you have missed the "feng shui" part (which made me
> broadly smile) from Tim's answer. In plain English, playing with this
> type of parameter is very dangerous; I doubt that the Oracle support
> often recommends to do it (unless they are very desperate). It affects
> all your Oracle system and nobody can predict what the result will be.
> If you have latching issues (and you didn't say you had any), you will
> get much better results trying to understand why your applications are
> having this type of problem. Sometimes the solution is as simple as
> changing a job schedule. If you have big performance problems, look at
> the code that is running first.
>
> Hope that helps
>
> Stéphane Faroult
> RoughSea Ltd
>
>
> amonte wrote:
> > Hi Tim
> >
> > Thanks very much foor the reply.
> >
> > Since spin_count is just a numbe rof loops, if we have a faster CPU
> > shouldnt we increase the value? I mean running 2000 loops in a 3GHZ
> > CPU is definitely not the same as running in a 500MHz CPU. In fact i
> > recall, Guy Harrison wrote a latch related paper mentioning that since
>
> > 2000 for spin_count has been used since Oracle 7, that is 10 - 13
> > years ago a higher value for modern CPU wouldnt surprise.
> >
> > Regarding the CPU usage, if with 8 500MHz CPU I consume 30000 seconds
> > CPU in 1 hour, if I replace those with 1GHZ CPU would I reduce my CPU
> > time/usage to half?
> >
> >
> > TIA
> >
> > Alex
> >
> >
> >
> > On 9/4/06, *Tim Gorman* < tim@xxxxxxxxx <mailto:tim@xxxxxxxxx>> wrote:
> >
> > Spin count has little to do with CPU cycles, and everything to do
> with
> > the duration of non-pre-emptive waits on latches ( i.e. column
> > SPIN_GETS
> > on V$LATCH). It is literally the count in a loop that Oracle
> spins
> > while waiting non-pre-emptively ( i.e. without losing the CPU) for
> a
> > latch. Really, really bad feng-shui to mess with spin count.
> >
> > Oracle cannot record if your CPU is working "efficiently" or
> not. All
> > it can do is report on how much CPU time was consumed. If you do
> the
> > math, 3 million centi-seconds is 30,000 seconds. An hour has
> 3,600
> > seconds, so eight CPUs can use 28,800 seconds in an hour. It
> pretty
> > much adds up to Oracle consuming all the CPU on your server, which
> > is OK
> > if it is the only thing on the server. As far as the discrepency
> > between 28,800 and 30,000, don't expect too much accuracy from a
> > mechanism that is constantly rounding or truncating micro-seconds
> > to the
> > nearest centi-second...
> >
> >
> > amonte wrote:
> > > Hi
> > >
> > > I was wondering if anyone know how is spin_count measured? In
> > CPU CYCLES?
> > >
> > > I havea doubt with CPU usage as well, I undersstand that in
> > v$sysstat
> > > it is using centiseconds to measure CPU usage. I wonder how can
> we
> > > determine 1 centisecond is equivalent to how many CPU cycles?
> For
> > > example I have a server with 8 PA-RISC 1200 MHz CPU, in 1 hour
> it
> > > reports 3 million centiseconds usage, am I using fully?
> > Basically is
> > > how do you know how efficiently is your CPU working from Oracle
> > > Statistics.
> > >
> > > TIA
> > >
> > > Alex
> > >
> >
> > --
> > --
> > -Tim Gorman
> > consultant - Evergreen Database Technologies, Inc.
> >
> > website = http://www.evdbt.com
> > email = tim@xxxxxxxxx <mailto:tim@xxxxxxxxx>
> > mobile = +1-303-885-4526
> > fax = +1-303-484-3608
> >
> > --
> > //www.freelists.org/webpage/oracle-l
> >
> >
> >
>
>
