[
https://issues.apache.org/jira/browse/DERBY-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532952#comment-16532952
]
Rick Hillegas commented on DERBY-7001:
--------------------------------------
Every iteration of the inner loop...
{noformat}
for (int j = 0; j < 1000; j++) {
for (int i = 0; i < 200; i++) {
dbHelper.preparedStatementQuery("Select * from
TABLE" + i);
}
}
{noformat}
...will compile a unique statement. Each statement is compiled into a separate
generated class. Derby will fill up the statement cache with these generated
classes. The size of the statement cache is set by the
derby.language.statementCacheSize system/database property. The default value
of that property is 100. That is, Derby will cache the generated classes for
the last 100 unique statements which were compiled/executed. Derby is supposed
to release the generated classes of statements which are expelled from the
statement cache. See the Derby Reference Manual section on
derby.language.statementCacheSize:
http://db.apache.org/derby/docs/10.14/ref/rrefproperstatementcachesize.html
At the very least, this experiment will thrash the statement cache and cause a
lot of garbage collection activity. You have tripped across a bug if you are
seeing more than derby.language.statementCacheSize generated classes
accumulating. What is the setting of derby.language.statementCacheSize and are
generated classes NOT being garbage collected once they are expelled from the
statement cache?
You are using the embedded driver, so this generation of classes happens in the
same JVM as your test program.
Thanks.
> Derby JDBC driver classs loader leak
> ------------------------------------
>
> Key: DERBY-7001
> URL: https://issues.apache.org/jira/browse/DERBY-7001
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.12.1.1
> Reporter: Leo Peng
> Priority: Major
> Attachments: DerbyProfile.png, DerbyTest.zip, MySqlProfile .png
>
>
> We had a customer facing Metaspace out of memory issue. After investigation.
> I found that the Derby JDBC driver may have a class loader leak problem. The
> reason is that I use same code doing the same thing with Derby and MySql,
> however, the statistics showed that there is a lot of difference. What I did
> was using Derby or MySql to create some tables and then do 200k queries on
> those tables. and collect some statistics from them.
> When using Derby as the data source, it is very easy to run out of Metaspace.
> Derby loads a large number of classes and committed Metaspace keeps
> increasing until full, at the same time, the GC operations are very frequent.
> On the contrary, when using MySql as the data source, it uses steady
> Metaspace during the process and no extra class loaded to JVM and no GCs.
> Another thing I found was that it took Derby more than 10 minutes to run 200k
> queries while it only costs MySql less than a second.
> Please see the attached screenshot profiles for more details.
> The JVM arguments I was using:
> {noformat}
> -XX:MaxMetaspaceSize=96m
> -XX:+HeapDumpOnOutOfMemoryError
> -XX:HeapDumpPath=C:/heapdump
> -verbose:gc
> -verbose:class
> {noformat}
> Some GCs when using Derby
> {noformat}
> [GC (Allocation Failure) 134632K->12584K(245760K), 0.0063202 secs]
> [GC (Metadata GC Threshold) 32171K->12432K(241152K), 0.0045418 secs]
> [Full GC (Metadata GC Threshold) 12432K->8691K(238592K), 0.0405280 secs]
> [GC (Allocation Failure) 128499K->12435K(237056K), 0.0074788 secs]
> [GC (Metadata GC Threshold) 38054K->12531K(234496K), 0.0053295 secs]
> [Full GC (Metadata GC Threshold) 12531K->8719K(232448K), 0.0366468 secs]
> [GC (Allocation Failure) 122895K->12271K(229376K), 0.0087422 secs]
> [GC (Metadata GC Threshold) 43475K->12799K(224768K), 0.0055041 secs]
> [Full GC (Metadata GC Threshold) 12799K->8738K(223744K), 0.0333892 secs]
> [GC (Allocation Failure) 117794K->12258K(223232K), 0.0060031 secs]
> [GC (Metadata GC Threshold) 48433K->12674K(221184K), 0.0050477 secs]
> [Full GC (Metadata GC Threshold) 12674K->8759K(219136K), 0.0339425 secs]
> [GC (Allocation Failure) 112695K->12183K(216064K), 0.0066411 secs]
> [GC (Metadata GC Threshold) 54733K->12623K(212992K), 0.0052730 secs]
> [Full GC (Metadata GC Threshold) 12623K->8778K(210432K), 0.0387252 secs]
> {noformat}
> I also attached the Java testing project for your reference.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
