summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorYorhel <git@yorhel.nl>2014-09-25 07:49:57 +0200
committerYorhel <git@yorhel.nl>2014-09-25 07:50:01 +0200
commitf409a38aa0594145141dc6b46f99d58f22418227 (patch)
tree898628209ba4701fa4ba4419570881125d8c320c
parentf24522cea27c66b5e217c168d1f780f22fa3ef63 (diff)
Multi: Update maintenance timings + disable usercache
The usercache maintenance cron is causing significant downtime each month, so I've disabled it for now.
-rw-r--r--lib/Multi/Maintenance.pm24
1 files changed, 14 insertions, 10 deletions
diff --git a/lib/Multi/Maintenance.pm b/lib/Multi/Maintenance.pm
index 32af16ae..81e9aacb 100644
--- a/lib/Multi/Maintenance.pm
+++ b/lib/Multi/Maintenance.pm
@@ -102,8 +102,8 @@ sub log_stats { # num, res, action, time
sub vncache_inc {
- # takes about 50ms to 1s to complete, depending on how many
- # releases have been released within the past 5 days
+ # takes about 500ms to 5s to complete, depending on how many releases have
+ # been released within the past 5 days
$_[KERNEL]->post(pg => do => q|
SELECT update_vncache(id)
FROM (
@@ -119,25 +119,25 @@ sub vncache_inc {
sub tagcache {
- # takes about 5 seconds max, still OK
+ # takes about 9 seconds max, still OK
$_[KERNEL]->post(pg => do => 'SELECT tag_vn_calc()', undef, 'log_stats', 'tagcache');
}
sub traitcache {
- # still takes less than a second
+ # takes about 90 seconds, might want to optimize or split up
$_[KERNEL]->post(pg => do => 'SELECT traits_chars_calc()', undef, 'log_stats', 'traitcache');
}
sub vnpopularity {
- # takes a bit more than 8 seconds, meh...
+ # takes about 30 seconds
$_[KERNEL]->post(pg => do => 'SELECT update_vnpopularity()', undef, 'log_stats', 'vnpopularity');
}
sub vnrating {
- # takes less than a second, but can be performed in ranges as well when necessary
+ # takes about 25 seconds, can be performed in ranges as well when necessary
$_[KERNEL]->post(pg => do => q|
UPDATE vn SET
c_rating = (SELECT (
@@ -195,15 +195,19 @@ sub cleanthrottle {
sub vncache_full {
- # this takes more than a minute to complete, and should only be necessary in the
+ # This takes about 4 to 5 minutes to complete, and should only be necessary in the
# event that the daily vncache_inc cron hasn't been running for 5 subsequent days.
$_[KERNEL]->post(pg => do => 'SELECT update_vncache(id) FROM vn', undef, 'log_stats', 'vncache_full');
}
sub usercache {
- # Shouldn't really be necessary, except c_changes could be slightly off when hiding/unhiding DB items
- # Currently takes about 25 seconds to complete.
+ # Shouldn't really be necessary, except c_changes could be slightly off when
+ # hiding/unhiding DB items.
+ # This query takes almost two hours to complete and tends to bring the entire
+ # site down with it, so it's been disabled for now. Can be performed in
+ # ranges though.
+ return;
$_[KERNEL]->post(pg => do => q|UPDATE users SET
c_votes = COALESCE(
(SELECT COUNT(vid)
@@ -229,7 +233,7 @@ sub usercache {
sub statscache {
# Shouldn't really be necessary, the triggers in PgSQL should keep these up-to-date nicely.
- # But it takes less than 100ms to complete, anyway
+ # But it takes less a second to complete, anyway.
$_[KERNEL]->post(pg => do => $_) for(
q|UPDATE stats_cache SET count = (SELECT COUNT(*) FROM users)-1 WHERE section = 'users'|,
q|UPDATE stats_cache SET count = (SELECT COUNT(*) FROM vn WHERE hidden = FALSE) WHERE section = 'vn'|,