Closed Bug 766524 Opened 9 years ago Closed 9 years ago

runs_logs table getting huge on production

Categories

(Tree Management Graveyard :: TBPL, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: scabral, Unassigned)

References

Details

Is there a data expiration strategy for runs_logs? https://bugzilla.mozilla.org/show_bug.cgi?id=703967 refers to the builders table, but on production, the runs_logs table is 100G right now.
Bug 703967 is about both the runs table and the builders table.

runs_logs uses |REFERENCES runs(buildbot_id) ON DELETE CASCADE| so should be resolved by that I presume?

(http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/file/tip/schema.sql)
Depends on: 703967
Hrm, the problem is that DROP PARTITION isn't a delete, so there would be orphaned rows.

It probably makes more sense to not bother with partitioning on the runs table....but to put an index on (endtime) and then the delete won't be so slow. We will need to defragment the tables to reclaim space.
Can we do this soon, please? the runs_logs table is 102G. 

Is this something we can do - put the index on, so the delete isn't so slow? and can we schedule a time when we can defragment the table, to free up space? Maybe July 4?
(In reply to Sheeri Cabral [:sheeri] from comment #3)
> Can we do this soon, please? 

We're happy for this to happen as soon as possible, however it's not anything we can do ourselves - we were waiting on bug 703967.
moving to that bug.
Fixed by bug 703967
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Product: Webtools → Tree Management
Product: Tree Management → Tree Management Graveyard
You need to log in before you can comment on or make changes to this bug.