You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 26, 2024. It is now read-only.
The table "timeline_events" is never cleared. There does not appear to be a rake task to do this. It would make sense if the task reports:prune would also clear the stale data from that table.
In our case, this table had ~4 million rows.
mysql> select count(id) from timeline_events;
+-----------+
| count(id) |
+-----------+
| 4599693 |
+-----------+
1 row in set (30.01 sec)
Whereas if we delete the obsolete rows (we prune weekly);
mysql> delete from timeline_events where created_at <= DATE_SUB(now(), INTERVAL 1 WEEK );
Query OK, 4511928 rows affected (4 min 29.87 sec)
That leaves around ~80.000 rows left, which significantly speeds things up.
The text was updated successfully, but these errors were encountered:
First step along the way: view recent events rake task: 6aebde7
~/puppet-dashboard $ bundle exec rake timeline:view
2014-01-25 04:31 UTC Node unprisoned.tetrachordon.org was updated by
2014-01-25 04:31 UTC Node unprisoned.tetrachordon.org was created by
2014-01-25 04:31 UTC Node unconjunctive.tetrachordon.org was updated by
2014-01-25 04:31 UTC Node unconjunctive.tetrachordon.org was created by
2014-01-25 04:31 UTC Node twirligig.tetrachordon.org was updated by
2014-01-25 04:31 UTC Node twirligig.tetrachordon.org was created by
2014-01-25 04:31 UTC Node tuberiform.tetrachordon.org was updated by
2014-01-25 04:31 UTC Node tuberiform.tetrachordon.org was created by
2014-01-25 04:31 UTC Node ticktacker.tetrachordon.org was updated by
2014-01-25 04:31 UTC Node ticktacker.tetrachordon.org was created by
ref.: http://weblog.etherized.com/posts/189.html
The table "timeline_events" is never cleared. There does not appear to be a rake task to do this. It would make sense if the task reports:prune would also clear the stale data from that table.
In our case, this table had ~4 million rows.
Whereas if we delete the obsolete rows (we prune weekly);
That leaves around ~80.000 rows left, which significantly speeds things up.
The text was updated successfully, but these errors were encountered: