db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4152) mailjdbc test database grows very fast with 10.5
Date Tue, 14 Apr 2009 18:15:15 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Mike Matrigali updated DERBY-4152:

I'm not sure what is causing the growth, the following may help understand
the problem.  It would be interesting to understand the regression vs. known
unfixed issues.

2 known issues that I would not be surprised are contributing:
1) There are definitely failed unique constraint errors in the runs I have
   looked at, which are a known problem for delayed space handling.

2) I belive the test runs inplace compress, at some interval.  But sometimes
   this can get back free pages but not return them to the OS.  The current
   algorithm only deals actively with "head" pages, not "overflow" pages.  When
   it moves a head page it does move it's associated overflow pages.  But when
   it tries to move all the rows from the end of the file toward the beginning
   it only has the ability to search through the head pages.  The root problem
   is that there are no "backward" pointers on the overflow pages so one
   can't look at an overflow page and know either it's parent in the chain or
   it' main page.

3) seems even less likely but DERBY-1193 might apply.

The following would give a better understanding of what is happening
(doing this on a 10.4 vs. 10.5 db may give interesting info):
o On a big db collect the space info on the big tables.
  Run just the online compress that does the purge phase, and rerun the
  space info.
  Now run just the move rows and shrink file phase and rerun the space info.
  Now run offline compress and run space info.

  What I would be looking for is to see if the space is being found and turned
  into free pages but just can't be given back to OS.

o It would be interesting to eliminate DERBY-4050, DERBY-4054 and DERBY-4055
  I think the existing debug flag used may print too much for this test, so
  would probably be good to temporarly change it to only print the BUG cases
  run the test.

> mailjdbc test database  grows very fast with 10.5
> -------------------------------------------------
>                 Key: DERBY-4152
>                 URL: https://issues.apache.org/jira/browse/DERBY-4152
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions:
>         Environment: java version "1.6.0"
> Java(TM) SE Runtime Environment (build pwi3260sr3-20081106_07(SR3))
> IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows 2000 x86-32 jvmwi3260-200811
> 05_25433 (JIT enabled, AOT enabled)
> J9VM - 20081105_025433_lHdSMr
> JIT  - r9_20081031_1330
> GC   - 20081027_AB)
> Windows 2000 5.00.2195 /Service pack 4
> 4 CPU 3.00GHz
>            Reporter: Kathey Marsden
>            Priority: Critical
> When I ran the mailjdbc test on RC I found that the mailsdb database grew to
16GB after two days.  On  on the same machine with the same configuration (no derby.properties)
it grew to only 1.7GB after 7 days.  Both were sane builds.
> This is with the embedded configuration:
> java org.apache.derbyTesting.system.mailjdbc.MailJdbc embedded

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

View raw message