[ http://issues.apache.org/jira/browse/DERBY-210?page=all ]
John H. Embretsen updated DERBY-210:
------------------------------------
Attachment: DOTS_ATCJ2_Derby-noPatch.png
DOTS_ATCJ2_Derby-withPatch.png
Uploaded graphs showing the Sun 1.5 JVM's utilization of Permanent Generation
space in the Java heap (i.e., the JVM running the Derby Network Server) when
running the DOTS test case ATCJ2 using Derby @ SVN 373478 (Jan 30 2006), with
and without the derby-210.diff patch uploaded by Deepa. Statistics were
obtained by using the "jstat" monitoring tool.
The heap size was fixed at 128 MB, and the Permanent Generation Space was fixed
at 64 MB. The attached graphs show the PermSpace because that was the part of
the heap that was having the most trouble during the DOTS test run.
* DOTS_ATCJ2_Derby-noPatch.png
shows PermSpace utilization on the server side _without_ the patch, the first
20 hours (72k seconds) of the test run. The Server JVM threw an
"OutOfMemoryError: PermGen space" after approximately 3 hours.
* DOTS_ATCJ2_Derby-withPatch.png
shows PermSpace utilization on the server side _with_ the patch, the first 20
hours of the test run. No OutOfMemoryErrors were thrown within this time period.
In other words, the patch seems to provide significant improvement to Derby
robustness with regards to cases where statements are not always explicitly
closed by the application using the Derby client. The garbage collector is able
to collect much more garbage with the patch than without.
For details on the DOTS test case and results obtained by running it, please
refer to the following thread on the derby-user mailing list:
http://www.nabble.com/OutOfMemoryErrors-when-testing-Derby-with-DOTS-t1010027.html
When it comes to GC performance, it seems that _with_ the patch, the garbage
collector spends less time doing (fewer) major (full) GCs, but more time doing
(more) minor GCs. Minor GC is a lot cheaper than major GC, since only the
"young" generations are garbage collected, not the entire heap (young + tenured
+ permanent space).
I hope this patch gets (re-)committed once the current issues are resolved.
Thanks, Deepa!
> Network Server will leak prepared statements if not explicitly closed by the
> user until the connection is closed
> ----------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-210
> URL: http://issues.apache.org/jira/browse/DERBY-210
> Project: Derby
> Type: Bug
> Components: Network Client
> Reporter: Kathey Marsden
> Assignee: Deepa Remesh
> Attachments: DOTS_ATCJ2_Derby-noPatch.png, DOTS_ATCJ2_Derby-withPatch.png,
> derby-210.diff, derby-210.status, derbyStress.java
>
> Network server will not garbage collect prepared statements that are not
> explicitly closed by the user. So a loop like this will leak.
> ...
> PreparedStatement ps;
> for (int i = 0 ; i < numPs; i++)
> {
> ps = conn.prepareStatement(selTabSql);
> rs =ps.executeQuery();
> while (rs.next())
> {
> rs.getString(1);
> }
> rs.close();
> // I'm a sloppy java programmer
> //ps.close();
> }
>
> To reproduce run the attached program
> java derbyStress
> Both client and server will grow until the connection is closed.
>
> It is likely that the fix for this will have to be in the client. The client
> does not send protocol to close the prepared statement, but rather reuses the
> PKGNAMCSN on the PRPSQLSTT request once the prepared statement has been
> closed. This is how the server knows to close the old statement and create a
> new one.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
