RE: Statspack (shared pool) memory leak

  • From: "Henry Poras" <henry@xxxxxxxxxxxxxxx>
  • To: <daniel.wittry@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 21 Dec 2004 16:59:45 -0500

I just ran this script on a 10.1.0.2 database on Linux. Most loops lost =
41K
of memory, but about every 5th to 10th loop, a large chunk of memory was
added. If I have a chance I'll look a bit more carefully.

Loop 55: (16:49:55) from    6,864,908 to    7,177,944 (loss of   =
-313,036)

Loop 56: (16:49:55) from    7,177,944 to    7,136,184 (loss of     =
41,760)

Loop 57: (16:49:55) from    7,136,184 to    7,094,412 (loss of     =
41,772)

Loop 58: (16:49:55) from    7,094,412 to    7,052,652 (loss of     =
41,760)

Loop 59: (16:49:55) from    7,052,652 to    7,010,892 (loss of     =
41,760)

Loop 60: (16:49:55) from    7,010,892 to    6,969,132 (loss of     =
41,760)

Loop 61: (16:49:55) from    6,969,132 to    6,927,372 (loss of     =
41,760)

Loop 62: (16:49:55) from    6,927,372 to    7,235,508 (loss of   =
-308,136)

Loop 63: (16:49:55) from    7,235,508 to    7,193,748 (loss of     =
41,760)

Loop 64: (16:49:55) from    7,193,748 to    7,151,972 (loss of     =
41,776)

Loop 65: (16:49:55) from    7,151,972 to    7,110,212 (loss of     =
41,760)

Loop 66: (16:49:55) from    7,110,212 to    7,068,452 (loss of     =
41,760)

Loop 67: (16:49:55) from    7,068,452 to    7,026,692 (loss of     =
41,760)

Loop 68: (16:49:55) from    7,026,692 to    6,984,932 (loss of     =
41,760)

Loop 69: (16:49:55) from    6,984,932 to    6,943,172 (loss of     =
41,760)

Loop 70: (16:49:55) from    6,943,172 to    7,259,208 (loss of   =
-316,036)

Loop 71: (16:49:55) from    7,259,208 to    7,217,448 (loss of     =
41,760)

Loop 72: (16:49:55) from    7,217,448 to    7,175,688 (loss of     =
41,760)

Loop 73: (16:49:55) from    7,175,688 to    7,133,928 (loss of     =
41,760)

Loop 74: (16:49:55) from    7,133,928 to    7,092,168 (loss of     =
41,760)

Loop 75: (16:49:55) from    7,092,168 to    7,050,408 (loss of     =
41,760)

Loop 76: (16:49:55) from    7,050,408 to    7,008,632 (loss of     =
41,776)

Loop 77: (16:49:55) from    7,008,632 to    6,966,872 (loss of     =
41,760)

Loop 78: (16:49:55) from    6,966,872 to    6,925,112 (loss of     =
41,760)

Loop 79: (16:49:55) from    6,925,112 to    7,238,044 (loss of   =
-312,932)

Henry

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx =
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Daniel Wittry
Sent: Tuesday, December 21, 2004 4:43 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Statspack (shared pool) memory leak


Oracle claims to have fixed the leak in 9.2.0.4 and 10g (Bug #3519807).
(Mark - you're running 9205 and you confirmed the leak)  I reOpened my =
iTAR
and will press them harder this time for a fix. Is anyone on OraDev =
reading
this?

Interesting enough, we traced ADDM and it does not use the x$ksolsfts
structure, yet creates a horizontal structure for segment statistics =
that is
deallocated when ADDM exits. Maybe OraDev knows it leaks?

The long and short of it seems to be:  when select * from
v$segment_statistics is typed, 1400 bytes of shared pool goes poof! That
smells bad.  Granted, there are cases where we can run the query in a =
test
loop and not leak memory, but it is unpredictable, even on the same =
instance
(and usually does leak).

__that's our findings



-----Original Message-----
From: Powell, Mark D [mailto:mark.powell@xxxxxxx]=3D20
Sent: Tuesday, December 21, 2004 12:57 PM
To: Daniel Wittry; oracle-l@xxxxxxxxxxxxx
Subject: RE: Statspack (shared pool) memory leak

I ran your script a dozen times or so (9.2.0.5 64 bit RAC on AIX 5.2) =
and
sure enough 04031 errors starting poping up.  Unfortunately I do not =
have
any more time to look at this, but perhaps one of the board guru's will
look.  I was wondering if you have brought this issue to Oracle support
attention?

--
//www.freelists.org/webpage/oracle-l

--
//www.freelists.org/webpage/oracle-l

Other related posts: