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 "Rick Hillegas (JIRA)" <ji...@apache.org> on 2009/09/15 17:57:57 UTC

[jira] Commented: (DERBY-4360) Avoid memory exhaustion when running UpgradeTrajectoryTest w/-DderbyTesting.allTrajectories=true

    [ https://issues.apache.org/jira/browse/DERBY-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755545#action_12755545 ] 

Rick Hillegas commented on DERBY-4360:
--------------------------------------

Just a little more information: I instrumented Version.addClassLoader() to report every time that a class loader was added to the cache of class loaders. Then I started a run against all trajectories involving the 16 versions of Derby on my laptop. All of the class loaders were created during the very first test of the very first trajectory, which tested the upgrade through all of the versions from first to last. After that, new class loaders were not created for subsequent trajectories. So the leak isn't caused by inadvertently creating new class loaders for each test.

Since the class loaders hang around, however, we are slowly accumulating new generated classes for the queries which verify that the virgin and upgraded databases are identical. Perhaps this contributes significantly to the leak. A possible solution might be:

1) Shutdown the engines at the end of very test.

2) After some number of tests, empty the class loader cache so that the vm can garbage-collect the class loaders along with their accumulating generated classes.

> Avoid memory exhaustion when running UpgradeTrajectoryTest w/-DderbyTesting.allTrajectories=true
> ------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-4360
>                 URL: https://issues.apache.org/jira/browse/DERBY-4360
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Test
>    Affects Versions: 10.6.0.0
>         Environment: JVM:
> Sun Microsystems Inc.
> java version "1.5.0_14"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03)
> Java HotSpot(TM) Server VM (build 1.5.0_14-b03 mixed mode 32-bit)
>            Reporter: Ole Solberg
>
> When run with  -XX:MaxPermSize=1024m -Xmx1024m  -DderbyTesting.allTrajectories=true we get 'Exception in thread "main" java.lang.OutOfMemoryError: Java heap space' after ~435 out of 4083 trajectories.
> When increasing to XX:MaxPermSize=1024m -Xmx2048m we reach ~930 out of 4083 trajectories,
> without OOM but with extreme upgrade times:
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.1.2.1 -> 10.1.3.1 -> 10.2.1.6 -> 10.2.2.0 -> 10.3.1.4 -> 10.3.3.0 -> 10.4.1.3 -> 10.4.2.0 -> 10.5.1.1 -> 10.5.3.0 ( hard, hard, hard, hard, hard, hard, hard, hard, hard, hard, hard, hard )
> used 10809 ms .
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.1.2.1 -> 10.1.3.1 -> 10.2.1.6 -> 10.2.2.0 -> 10.3.1.4 -> 10.3.3.0 -> 10.4.1.3 -> 10.4.2.0 -> 10.5.1.1 ( hard, hard, hard, hard, hard, hard, hard, hard, hard, hard, hard )
> used 3871 ms .
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.1.2.1 -> 10.1.3.1 -> 10.2.1.6 -> 10.2.2.0 -> 10.3.1.4 -> 10.3.3.0 -> 10.4.1.3 -> 10.4.2.0 -> 10.5.3.0 ( hard, hard, hard, hard, hard, hard, hard, hard, hard, hard, hard )
> used 3049 ms .
> .
> .
> .
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.2.2.0 -> 10.3.1.4 ( hard, hard, hard, hard )
> used 95779 ms .
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.2.2.0 -> 10.3.3.0 -> 10.4.1.3 -> 10.4.2.0 -> 10.5.1.1 -> 10.5.3.0 ( hard, hard, hard, hard, hard, hard, hard, hard )
> used 167768 ms .
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.2.2.0 -> 10.3.3.0 -> 10.4.1.3 -> 10.4.2.0 -> 10.5.1.1 ( hard, hard, hard, hard, hard, hard, hard )
> used 148693 ms .
> testTrajectory DEBUG: Testing trajectory: 10.0.2.1 -> 10.1.1.0 -> 10.2.2.0 -> 10.3.3.0 -> 10.4.1.3 -> 10.4.2.0 -> 10.5.3.0 ( hard, hard, hard, hard, hard, hard, hard )

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.