Last modified: 2014-09-23 21:32:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T73073, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 71073 - JobQueue does not respect --maxtime
JobQueue does not respect --maxtime
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
JobQueue (Other open bugs)
1.24rc
All All
: Unprioritized major (vote)
: 1.24.0 release
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 39480
  Show dependency treegraph
 
Reported: 2014-09-19 22:20 UTC by Niklas Laxström
Modified: 2014-09-23 21:32 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Niklas Laxström 2014-09-19 22:20:22 UTC
translatewiki.net suffered degraded service today after changes to Template:Identical caused a huge amount of jobs generated.

The issue was that I had 10+ parallel runJobs.php running for many minutes. First I thought that --exclusive should have prevented this, but on further inspection that never stayed in: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/73198

Then my second thought was that --maxtime=50 should prevent this, but it didn't. It looks like $sTime is correctly set at the beginning, but then it is overwritten again for each job, which means it actually functions like "stop if the last job took longer than maxtime":
// Run the job...
wfProfileIn( __METHOD__ . '-' . get_class( $job ) );
$sTime = microtime( true );

My CRON entry is:
* * * * * betawiki nice php /www/translatewiki.net/w/maintenance/runJobs.php --exclusive --maxtime=50 --procs=1 --memory-limit=250M >> /www/translatewiki.net/w/logs/jobqueue 2> /dev/null

For now I have disabled the CRON entry and running jobqueue manually until it drains.
Comment 1 Gerrit Notification Bot 2014-09-19 22:27:28 UTC
Change 161618 had a related patch set uploaded by Aaron Schulz:
Fixed --maxtime handling by JobRunner

https://gerrit.wikimedia.org/r/161618
Comment 2 Gerrit Notification Bot 2014-09-19 22:32:18 UTC
Change 161621 had a related patch set uploaded by Aaron Schulz:
Fixed --maxtime handling by JobRunner

https://gerrit.wikimedia.org/r/161621
Comment 3 Gerrit Notification Bot 2014-09-19 22:46:02 UTC
Change 161618 had a related patch set uploaded by Nikerabbit:
Fixed --maxtime handling by JobRunner

https://gerrit.wikimedia.org/r/161618
Comment 4 Gerrit Notification Bot 2014-09-19 22:57:48 UTC
Change 161618 merged by jenkins-bot:
Fixed --maxtime handling by JobRunner

https://gerrit.wikimedia.org/r/161618
Comment 5 Gerrit Notification Bot 2014-09-19 23:19:41 UTC
Change 161626 had a related patch set uploaded by Legoktm:
Fixed --maxtime handling by JobRunner

https://gerrit.wikimedia.org/r/161626
Comment 6 Kunal Mehta (Legoktm) 2014-09-19 23:22:20 UTC
Marking as fixed, Niklas said it worked on twn. I backported it to REL1_24.
Comment 7 Gerrit Notification Bot 2014-09-19 23:26:58 UTC
Change 161626 merged by jenkins-bot:
Fixed --maxtime handling by JobRunner

https://gerrit.wikimedia.org/r/161626
Comment 8 Gerrit Notification Bot 2014-09-23 21:32:55 UTC
Change 161621 merged by jenkins-bot:
Fixed --maxtime handling by JobRunner

https://gerrit.wikimedia.org/r/161621

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links