db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed
Date Wed, 01 Feb 2006 13:46:08 GMT
     [ 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


Mime
View raw message