Bug 768886

Summary: RfE run "vacuum full" after bundle deletion
Product: [Other] RHQ Project Reporter: Heiko W. Rupp <hrupp>
Component: Core ServerAssignee: RHQ Project Maintainer <rhq-maint>
Status: NEW --- QA Contact: Mike Foley <mfoley>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 4.2CC: hrupp
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
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:
Cloudforms Team: ---

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