db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bergquist, Brett" <BBergqu...@canoga.com>
Subject RE: Have Derby Network Server having an out of memory (PermGen)
Date Wed, 21 Nov 2012 14:53:42 GMT
I reset the statement cache size to 100 statements and set the MaxPermGen size to 256m and
reran the test querying the View which uses the table function.  Now when I run it, the loaded
classes increase along with the PermGen, and then the loaded classes are unloaded and PermGen
comes back down when it collects!    This is good!

So now I need to figure out what the MaxPermGen size needs to be for a larger statement cache.

-----Original Message-----
From: Bergquist, Brett [mailto:BBergquist@canoga.com] 
Sent: Wednesday, November 21, 2012 8:40 AM
To: derby-dev@db.apache.org
Subject: RE: Have Derby Network Server having an out of memory (PermGen)

Yes, the statement cache size has been increased to 50K statements so that might be an issue.
 Maybe the PermGen space will need to be increased because of that.  The documentation is
not clear which type of heap that the statement cache would affect, however.   As a test,
I am going to lower my statement cache size to 100 statements and see what happens.   Thanks
for the idea!

Some more info however.   It is definitely related to the View/table function mechanism (explained
in my second email).   I just did a little more testing and found that if I change the query
to use the table function directly instead of using the View that is created that uses the
table function, then the loaded classes reported by VisualVM stays stable.   Any thoughts
on why querying on a View that is created that uses the table function might be generating
and holding onto classes whereas using the same query with the View name replaced by the table
function name does not have this problem?

I much appreciate the feedback and thoughts.


-----Original Message-----
From: Knut Anders Hatlen [mailto:knut.hatlen@oracle.com]
Sent: Wednesday, November 21, 2012 8:28 AM
To: derby-dev@db.apache.org
Subject: Re: Have Derby Network Server having an out of memory (PermGen)

"Bergquist, Brett" <BBergquist@canoga.com> writes:

> I have a customer that is periodically having a problem and unknown to 
> me, they have been accessing the Derby database using a query such as 
> in the following and have been repeatedly experienced a server issue.
> I finally figured out it was an OutOfMemory error (PermGen). So I just 
> wrote a little application that performs the same query over and over 
> against a copy of the database and the Derby Network Server. In just a 
> few hours, the Derby Network Server gave up the ghost with a
> OutOfMemory(PermGen) error.
> This is running against Derby There is no other access to 
> the database from any other process during this test.
> Note that the query returns no data as there are no records in the 
> database that satisfy the query. Also, note that the table NPAResults 
> is actually a View that looks like:


> Each time I run this sample, after a few hours, the OutOfMemory 
> occurs. Any ideas on this will be greatly appreciated.

Hi Brett,

I don't see anything obvious that should cause problems in the code you posted. I tried to
run it myself, but it didn't seem to cause any leak in my environment. Of course, I didn't
run the exact same code, since I don't know exactly what your table function does. (And I
ran it with -XX:MaxPermSize=16M since I didn't want to wait for hours to see the

If you manage to come up with a full repro that others could run, it might be easier to see
what's going on.

By the way, have you changed the statement cache size, or are you running with default size?
I'm asking because the size of the statement cache will affect how soon generated classes
can be garbage collected.

Knut Anders

View raw message