Re: see higher CPU usage after increase SGA

Thanks Janathan,
    The following is some data from the statspack 9-15pm report.
    I am not sure whether it should be like that CPU usage should rise, or
it is just some kind of fluctuation.

[oracle@main-db1**biddb]$grep "table scans (short tables)" *.lst --it does
increase, but I am not sure how much cpu increase it can cause. Have no
idear how to measure it.
10gb.lst:table scans (short tables)               1,132,629         52.4
0.7
11gb.lst:table scans (short tables)               1,301,091         60.3
0.8

[oracle@main-db1**biddb]$grep "CR blocks created" *.lst
10gb.lst:CR blocks created                          202,232          9.4
0.1
11gb.lst:CR blocks created                          181,607          8.4
0.1

[oracle@main-db1**biddb]$ grep "table scans (long" *.lst
10gb.lst:table scans (long tables)                        5          0.0
0.0
11gb.lst:table scans (long tables)                        5          0.0
0.0

Thanks.
Zhu Chao.

----- Original Message ----- 
From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Wednesday, June 09, 2004 11:01 PM
Subject: Re: see higher CPU usage after increase SGA


>
> A couple of thoughts:
>
> Increasing the db_cache_size means you may have
> sufficient space to keep more clones of CR blocks,
> which means that the number of clones checked for
> the correct SCN could have increased  - this would
> use more CPU directly (checking the next clone) and
> indirectly (holding the latch longer for the check causes
> others to spin for longer).
>
> Increasing the db_cache_size will also increase the
> size of a 'small table', so more tablescans would go into
> the middle of the LRU rather than the end.  This could
> have some effect on CPU usage if you previous has a
> number of tablescans which just fell short of 'small'.
>
> I can't see where the 1.5% drop in logical I/O would
> come from - but it's small enough to be noise - I think.
>
> These are ideas are just conjecture, of course, and may
> have nothing to do with the real reason for your increased
> CPU.
>
>
> Regards
>
> Jonathan Lewis
>
> http://www.jlcomp.demon.co.uk
>
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
> The Co-operative Oracle Users' FAQ
>
> http://www.jlcomp.demon.co.uk/seminar.html
> Optimising Oracle Seminar - schedule updated May 1st
>
>
> ----- Original Message ----- 
> From: "zhu chao" <chao_ping@xxxxxxxxxxx>
> To: <oracle-l@xxxxxxxxxxxxx>
> Sent: Wednesday, June 09, 2004 2:31 PM
> Subject: see higher CPU usage after increase SGA
>
>
> : Hi,
> :     I once saw Jonathan said at metalink that huge SGA does not help in
> many
> : case, But no further discuss at that topic later.  Last night we added
1Gb
> : to oracle sga and we see fewer disk read but higher CPU usage.
> :
> :     Fewer disk read of course cut CPU usage, but larger buffer cache
> : management in unix and oracle, seems caused higher CPU usage. Has
someone
> : also have similar experience? How to explain the higher CPU usage?
> :
> :     We have a 16GB memory sun 880 with 10G data cache. As disk read get
> : higher and higher , and not much SQL to tune we deciede to increase data
> : buffer from 10G to 11GB, as there is still 1.5G free memory on the host.
> :
> :     We expect to see some CPU usage drop, as disk read drop by 30%. But
> : after 1 day's run, we saw higher CPU usage then before we increase the
> SGA.
> :
>
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
>

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: