db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "De Meyer Tim" <Tim.DeMe...@cegeka.be>
Subject Derby eating up disk space + how to trigger ReclaimSpace elegantly
Date Mon, 08 Aug 2011 07:12:08 GMT

We're working on a java webapp and using a derby database (v10.5) in embedded mode.
The first version of the application went live about 2 months ago.
The application gets used for making invoices and we also store the XML of an invoice document
in the derby DB (input data for generating a PDF against a template).
Today, the database is about 1,7GB on disk.

During these 2 months, we've released some minor upgrades, including database migration scripts
(like extra tables for new functionality).
Now we've noticed that, when we ran our latest upgrade, the database has suddenly shrunk to
a size of 600MB.
This latest upgrade contained a migration script that dropped a no longer needed timestamp
column on practically every table.
It's after executing this script that the shrink happened.
You can see about practically every .dat file getting touched (or rebuilt) and this shrinks
the seg0 folder.
We did some debugging and hit suspend when the disk size started shrinking, it lead us to
a Derby class called "ReclaimSpace".

We're afraid the database will start using up unnecessary space again soon, and of course,
we're not going to have a similar migration script in every upgrade.
Why is derby so greedy with disk space (in our configuration)?
I'm also not sure what made the database grow in the first place. Was is just using the DB
or was it the migration scripts from the previous releases, I don't know.
Is there an elegant way to configure derby to do this cleaning continuously, or to let our
webapp instruct derby to do some cleaning?
We're launching the webapp from within a small java webstart app (we launch a Jetty and attach
our war file), so it's even OK for us to write some java code to do it programmatically.

We've found this, but it's on a per table basis :-(

By the way, as a comparison, we're running about 10 of these webapps on different desktop
Each webapp synchronizes its data to a server running a postgresql 9 database.
This means that this postgres database accumulates all the data of these 10 webapps (some
data is shared, so it's not times ten).
The size of this postgres DB is less than 1GB, which sounds OK against the 600MB of one of
those webapps, but not against 1,7GB for one webapp.

Any help on all of this would be more than welcome.

Kind regards,

Tim De Meyer

View raw message