db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4360) Avoid memory exhaustion when running UpgradeTrajectoryTest w/-DderbyTesting.allTrajectories=true
Date Tue, 15 Sep 2009 15:57:57 GMT

    [ 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.


Mime
View raw message