Page MenuHomePhabricator

Handle large bursts of jobs more elegantly
Closed, DeclinedPublic

Description

The job queue is way more awesome than it was 2 years ago. With the improved code + redis architecture, it's incredibly reliable and we're doing way more jobs than ever before.

We tend to keep up with the small day-to-day jobs perfectly. Most queues are near empty on enwiki most of the time, or in the case of cirrus/htmlCache/linksUpdate jobs, maybe a few hundred/thousand at a time. No big deal.

What we do *not* handle well is a large burst of jobs. Someone edits a super high use template, we reindex all of enwiki or commons in Cirrus, anything. We end up with millions of jobs and it takes weeks to clear the backlog without manual intervention.

It would be nice to do something better in this case. I have no clue what this better thing may be.


Version: 1.23.0
Severity: normal

Details

Reference
bz60348

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:56 AM
bzimport set Reference to bz60348.
bzimport added a subscriber: Unknown Object (MLST).

Putting giant bulk operations onto their own subqueues and interleaving them with other actions might be good.

Aklapper lowered the priority of this task from Medium to Low.Apr 9 2015, 12:36 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Deskana added subscribers: EBernhardson, Deskana.

This is a little stale now. @EBernhardson says there are no real problems with bursts of jobs any more, and we tend not to end up with millions of jobs unless there's a job queue problem. Declining.