Bug 768886 - RfE run "vacuum full" after bundle deletion
RfE run "vacuum full" after bundle deletion
Status: NEW
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
4.2
Unspecified Unspecified
medium Severity unspecified (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-19 05:15 EST by Heiko W. Rupp
Modified: 2013-09-10 03:50 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Heiko W. Rupp 2011-12-19 05:15:47 EST
> I previously then asked how the actual bits of the bundles are cleaned
> (or are they), because the database size on disk keeps growing
> constantly. I was then informed that vacuuming should release the actual
> disk space.

When you update or delete a row in postgres, this row is marked as invalid and in
case of update a new row is appended.

Now vacuum with the standard options is going through the table and finding all
those rows that are marked as invalid and is setting them to "fresh" so that subsequent
inserts can re-use those rows so that the table size is indeed not growing indefinitely.

So what you were seeing here is that a pure vacuum (which runs automatically
in postgres when certain assumptions are met and which the JBossON server is
running in default settings every hour) is just going through the database and is 
marking those rows as fresh. It does not try to compact any database files.

There is an option 'full' to vacuum that tries indeed to reclaim the disk space
of the unused rows. This option is not enabled by default, because 
- it acquires an exclusive lock on the table and thus prevents access by the JBossON server
- in cases where there will be new rows added immediately, shrinking the file (that backs a table) 
 and extending it directly afterwards is more expensive than just re-using the file.

So what you can do it to manually trigger a "vacuum full" on the database when there is no load
(or only on the bundle tables, when you know noone is accessing them).


-----

The new operation vacuum_full  would be by default for postgres and a no-op for other databases - until we find out how we can help them how to reclaim the space.
Comment 1 Charles Crouch 2012-02-13 22:22:46 EST
Putting this as a "soft" target for 3.1
We can see if there are some procedures that can be determined to help alleviate the issue of "empty" table bloat, e.g. create a lot bundles, delete them all, DB size doesn't decrease.
e.g.
1) Put all JON servers in maintenance mode
2) Push the "do a full vacuum on content/bundle tables". 
3) Wait for success message
3) Put all JON servers in normal mode
Comment 2 Mike Foley 2012-02-27 12:13:08 EST
triage 2/27/2012 mfoley, asantos, crouch, loleary

Note You need to log in before you can comment on or make changes to this bug.