You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "John H. Embretsen (JIRA)" <de...@db.apache.org> on 2006/02/01 14:46:08 UTC
[jira] Updated: (DERBY-210) Network Server will leak prepared
statements if not explicitly closed by the user until the connection is
closed
[ 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
Re: [jira] Updated: (DERBY-210) Network Server will leak prepared
statements if not explicitly closed by the user until the connection is closed
Posted by John Embretsen <Jo...@Sun.COM>.
John Embretsen wrote:
> I suspect there will be other issues that are uncovered by running the
> DOTS test case (or variations of it) with various configurations, but
> they may or may not be related to this particular issue. I will
> certainly let you know as soon as possible if I notice any memory leaks.
> I will run the test against a patched Derby trunk for a while longer,
> and see how it goes.
Here's an update:
I was running the DOTS test case (unmodified) this weekend using a
maximum number of 20 concurrent db connections. The Network Server threw
an "OutOfMemoryError: PermGen space" about 55 hours into the test run,
with same heap size as earlier (128 MB heap, 64 MB PermSpace).
So it seems that the patch does not completely eliminate the problem
associated with that particular test case. However, I do not believe
this test failure is a showstopper for the patch. More testing is needed
in order to determine if the failure is caused by
* lack of explicitly closing all statements
* using/compiling too many different statements (i.e., more than the
current heap size can handle)
* something else
* a combination of the above
--
John
Re: [jira] Updated: (DERBY-210) Network Server will leak prepared
statements if not explicitly closed by the user until the connection is closed
Posted by John Embretsen <Jo...@Sun.COM>.
Bryan Pendleton wrote:
> This is *excellent* news!
>
> Can you tell, at this point, whether there is a secondary leak that
> we must additionally pursue? That is, does it seem as though, if we
> are able to incorporate the DERBY-210 fixes into the base product, we
> will be able to run DOTS without memory exhaustion errors?
I am not sure at this point, I will have to run more (and longer) tests
to increase the confidence level.
> I guess what I'm asking is: what duration of test, with the patch
> applied, would be enough to satisfy us that there are no additional
> memory leaks exposed by this test?
That is a very hard question. Does anyone with previous experience from
slow memory leaks have any comments on this?
I suspect there will be other issues that are uncovered by running the
DOTS test case (or variations of it) with various configurations, but
they may or may not be related to this particular issue. I will
certainly let you know as soon as possible if I notice any memory leaks.
I will run the test against a patched Derby trunk for a while longer,
and see how it goes.
--
John
Re: [jira] Updated: (DERBY-210) Network Server will leak prepared
statements if not explicitly closed by the user until the connection is closed
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> 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.
This is *excellent* news!
Can you tell, at this point, whether there is a secondary leak
that we must additionally pursue? That is, does it seem as though,
if we are able to incorporate the DERBY-210 fixes into the base
product, we will be able to run DOTS without memory exhaustion errors?
I guess what I'm asking is: what duration of test, with the patch
applied, would be enough to satisfy us that there are no additional
memory leaks exposed by this test?
thanks,
bryan
Re: [jira] Updated: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed
Posted by Deepa Remesh <dr...@gmail.com>.
> I hope this patch gets (re-)committed once the current issues are resolved.
Thanks John for running tests with the patch and posting results.
I have been trying to create a repro for the sporadic problem which
occured after commiting this patch. After few unsuccessful attempts, I
put it on hold and got side-tracked into working on another bug. I
plan to continue work on it this week. If tests pass, I will submit an
updated patch for review in couple of days.
Thanks,
Deepa