RE: SGA Free memory
- From: "Hameed, Amir" <Amir.Hameed@xxxxxxxxx>
- To: <jonathan@xxxxxxxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 9 Feb 2006 14:44:29 -0500
Thanks Jonathan for the correction and explanation. However, how do one
determine how much shared pool flushing rate is bad? Steve Adams has
stated in his book about the transient versus recurrent chunks ratio to
determine whether the shared pool size is appropriate or not. Any
comments on this?
Thanks
Amir
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Jonathan Lewis
Sent: Thursday, February 09, 2006 2:32 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: SGA Free memory
Amir,
This is not entirely normal - the scale of the flush is a little
extreme, and ties in with your earlier question about "session param
values".
The reply you got about increasing the reserved shared pool was correct,
and is probably relevant in this case as well.
The sequence of events for allocating memory from the shared pool is:
Request chunk in shared pool
if no available free chunks large enough
if chunksize > 'reserved pool min alloc' (ca. 4400 bytes)
search reserved pool for large enough free chunk
if space available,
allocate in reserved pool
return
endif
end if
-- get here if
(a) reserved pool has no free space
(b) reserved pool was not checked
loop
detach some items from end of library cache LRU
distribute items to shared pool free list - coalescing where
possible
check for large enough chunk on free list
return if allocation succeeds
end loop
There may be a limit on the number of times round the loop -
but I've seen highly concurrent OLTP systems flush several
hundred megabytes from the library cache - hammering the
library cache and shared pool latches to death for seconds
at a time doing this.
You can get problems on well-designed systems with large numbers of
users because (a) the free memory eventually degrades into lots of very
small pieces, (b) the session param values is about 22 KB and
(c) the default of 5% for the reserved pool may not be enough.
As a rough guide line, if you are seeing catastrophic memory thrashing,
check that your shared_pool_reserved is about 25KB * sessions plus a few
MB. (A query against x$ksmspr will tell you how much of the memory is
used for things other than session parameters), and that's at least the
size you need for the "few MB extra").
select sum(KSMCHSIZ) from x$ksmspr
where ksmchcom not in ('free memory','session param valu')
(Don't try this against x$ksmsp, the shared pool, it could cripple your
system for anything up to a couple of minutes if it's a system with a
large shared pool and lots of users).
(the session parameter component has a couple of changes in its name
across Oracle versions).
You could also check to see how many of your session's have got their
parameters into the reserved pool - this is quite a nice query, and not
too aggressive as a more general check:
select ksmchcom,count(*),sum(ksmchsiz)
from x$ksmspr
group by ksmchcom;
(again - DON'T run it against x$ksmsp).
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html
Cost Based Oracle: Fundamentals
http://www.jlcomp.demon.co.uk/appearances.html
Public Appearances - schedule updated 2nd Feb 2006
----- Original Message -----
From: "Hameed, Amir" <Amir.Hameed@xxxxxxxxx>
To: <genegurevich@xxxxxxxxxxxxxxxxxxxxx>; <oracle-l@xxxxxxxxxxxxx>
Sent: Wednesday, February 08, 2006 5:38 PM
Subject: RE: SGA Free memory
This is normal behavior as chunks are flushed from and added to the
shared pool, the memory fluctuates. As long as you are not seeing
ORA-04031 error or contention on the shared pool latch is not too high,
you are fine. What RDBMS version are you on?
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of
genegurevich@xxxxxxxxxxxxxxxxxxxxx
Sent: Wednesday, February 08, 2006 12:28 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: SGA Free memory
Hi all:
I am watching the usage of the SGA on my database via the following
command:
select to_char(sysdate,'mm-dd-yyyy hh24:mi:ss'), name, bytes/(1024*1024)
from v$sgastat, dual
where pool like '%shared%' and name = 'free memory' order by bytes asc
;
I am running it every 10 seconds. Recently I saw the free memory going
from
25M to 145M over the course
of 10 sec. I'm wondering what could have caused it. Would appreciate any
suggestions
thank you
Gene Gurevich
Oracle Engineering
224-405-4079
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
