On Mon, Feb 16, 2009 at 11:02 AM, Thomas Dalton <thomas.dalton(a)gmail.com> wrote: Jobs are not processed on requests. They're processed by a cron job. You can't just automatically run them at a crazy rate, because that will cause slave lag and other bad stuff. If too many are accumulating, it's probably due to a programming error that needs to be found and fixed by human inspection. (Tim just made several commits fixing things that were spewing out too many jobs.) #wikimedia-tech has enough people that regular warnings posted there would probably get noticed.

On Mon, Feb 16, 2009 at 11:33 AM, Thomas Dalton <thomas.dalton(a)gmail.com> wrote: That's correct, it doesn't. The default is really only for easier installation on shared hosting where cron might not be available (and perhaps Windows, although I imagine that has some cron equivalent).

On Mon, Feb 16, 2009 at 6:20 PM, Platonides <Platonides(a)gmail.com> wrote: Yes, because they're not a bot who a) we know is actually noting a real problem instead of subjective impressions, and who b) spams the complaint on an ongoing basis like nagios does. Part of the problem is that the measure of job queue length we really care about is "what was the last job executed?", not "how many jobs are in the queue?". If we added a job_timestamp column and put an index on it, we could replace (or supplement) the cruddy poor-quality estimate we have now with a probably more useful and certainly more accurate one.

Platonides wrote: I've been toying with some additions to the job queue so that we have some semblance about what is going on. Time stamp, actual stats of progress and if we want to get extra fancy, better view of what the job workers are doing. Just simple things to help humans analyze what is going. And if were lucky .. maybe tell us why. Now that I'm back, I'm hoping to have something ready for Brion and everyone to look at soon. --tomasz

2009/2/16 Andrew Garrett <andrew(a)epstone.net>et>: That would be a mistake, then.

On Mon, Feb 16, 2009 at 8:20 PM, Tim Starling <tstarling(a)wikimedia.org> wrote: I misunderstood the problem, evidently. I thought it was a one-off thing due to software bugs the sysadmins didn't know about. It seems it's more like a known, ongoing problem whose cause isn't understood yet, so there's no point in bugging people about it all the time, no.

Aryeh Gregor <Simetrical+wikilist(a)gmail.com> wrote: Not only for statistics, it would also provide users with an opportunity to see whether it is due to the job queue or a bug if a category membership or a link/template relationship is not updated soon after the actual edit to article. In the same way it would be nice to extend "?action=purge" to log any discrepancies it encounters between the pre- and post-purge states to ease debugging. Tim