RE: MEMORY leakage

  • From: "Richard Ji" <Richard.Ji@xxxxxxxxxx>
  • To: <tim@xxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 9 Sep 2004 22:17:57 -0400

On Solaris, The free memory will always be very close to zero
as Tim pointed out.  vmstat from Solaris 8 and on, the "free"
column will report the number which include majority of the
file system cache.

Solaris memtool's prtmem can break out the memory.

You can download that from www.solarisinternals.com

Richard Ji

-----Original Message-----
From:   Tim Gorman [mailto:tim@xxxxxxxxxxxxx]
Sent:   Thu 9/9/2004 8:35 PM
To:     oracle-l@xxxxxxxxxxxxx
Cc:=09
Subject:        Re: MEMORY leakage=20
Dinesh,

Most likely, it is the UNIX buffer cache (UBC) for the file-systems =
which i=3D
s
making the "free" memory statistic appear low (and suspiciously =
constant).
Typically, the UBC is configured to utilize all but a small percentage =
of
memory if it needs it, but it is also designed to "give up" that memory =
upo=3D
n
request when it is needed for another purpose.  Memory needed for =
process
images are "stolen" from the UBC before the "free" memory is tapped =
into,
resulting in a consistent low amount of memory marked "free" regardless =
of
activity on the system.

I have seen reports from HPUX which break out UBC usage from process =
images
using the HP "perfview" tool.  I don't know if you can get a similar =
report
(i.e. UBC, RSS, etc) from Solaris.  Anybody?  Anybody?  Bueller?  =
Bueller?
Anybody?

In other words, what you are seeing most likely is not a problem, simply =
a
misinterpretation (an understandable one) of the meaning of the =
statistics.
To determine if this is indeed the case, what do you think the =
likelihood i=3D
s
that "free" memory would remain at 46Mb consistently, regardless of =
stuff
starting and finishing, spawning and exiting?  Is that what you are =
seeing,
or are you seeing that figure fluctuate?

Also, have you seen "page in" activity (i.e. paged out blocks being
retrieved back into resident memory)?  Since there is usually constant
proactive "page out" activity at all times, "page in" activity typically
indicates pressure on the memory resource.  If you're not seeing =
constant
"page in" activity, then the whole issue is moot anyway.

Also, check to see if the "fsflush" process is very busy -- that also =
tends
to indicate lots of UBC activity, as "fsflush" is UNIX's corollary to
Oracle's DBWR process.  A busy "fsflush" process isn't necessarily a bad
thing, it just helps explain the situation.

Hope this helps...

-Tim


on 9/8/04 9:05 PM, Seema Singh at oracledbam@xxxxxxxxxxx wrote:

> Hi,
> When I rebooted the Solaris box the memory was free 1130mb out =
1536mb(tot=3D
al
> physical memory).After 2 hrs ONLY 46mb memory is free.All oracle =
processe=3D
s
> are eating 253mb around.Wondering  how to fix it?
> Is it Solaris level problem? Solaris 5.7  and 817.0.0 are running.
> thanks
> -Dinesh
>=3D20
> _________________________________________________________________
> Don=3D92t just search. Find. Check out the new MSN Search!
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>=3D20
> --
> To unsubscribe - =
mailto:oracle-l-request@xxxxxxxxxxxxx&subject=3D3Dunsubscrib=3D
e
> To search the archives - //www.freelists.org/archives/oracle-l/

--
To unsubscribe - =
mailto:oracle-l-request@xxxxxxxxxxxxx&subject=3Dunsubscribe=20
To search the archives - //www.freelists.org/archives/oracle-l/



--
To unsubscribe - mailto:oracle-l-request@xxxxxxxxxxxxx&subject=unsubscribe 
To search the archives - //www.freelists.org/archives/oracle-l/

Other related posts: