db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: Have Derby Network Server having an out of memory (PermGen)
Date Wed, 21 Nov 2012 14:58:08 GMT
"Bergquist, Brett" <BBergquist@canoga.com> writes:

> 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!

On the bright side, the current early-access builds of JDK 8 don't have
a separate PermGen area. So in the not too distant future one doesn't
have to spend time figuring out how to partition the heap space.

> 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?

Nothing comes to mind. I think there are some transformations the query
optimizer isn't able to do on views, that it could do when working
directly on the tables, so the compiled plans may differ. But it
shouldn't affect how soon the generated classes can be reclaimed.

Knut Anders

View raw message