I've done this by hand in the past but it would be nice to track the larger wikis via a script out of cron once a month.
In cases where jobs are re-run manually there will be issues with times, but the rest of the data will be nice to have around for planning.
This came up again because the enwiki meta history bz2 dumps completed quicker this round than I expected, even after a service interruption.
Change 444603 had a related patch set uploaded (by ArielGlenn; owner: ArielGlenn):
[operations/dumps@master] quick script to show runtimes of dump jobs
Change 444603 merged by ArielGlenn:
[operations/dumps@master] quick script to show runtimes of dump jobs
Change 446894 had a related patch set uploaded (by ArielGlenn; owner: ArielGlenn):
[operations/puppet@production] Collect run times for certain dump steps on the big wikis
Change 446894 merged by ArielGlenn:
[operations/puppet@production] Collect run times for certain dump steps on the big wikis
I'll get a report on the longer running jobs for enwiki, wikidatawiki and the 'big wikis' for now. This should run tomorrow before the 20th dump jobs kick off.
I should add one more job that gives me the slowest 40, say, page-meta-history bz2 content dumps on all wikis, so i can track those. Next time.
Change 446970 had a related patch set uploaded (by ArielGlenn; owner: ArielGlenn):
[operations/puppet@production] Collect slowest revision history content dump runs
Change 446970 merged by ArielGlenn:
[operations/puppet@production] Collect slowest revision history content dump runs
Well, 'next time' turned out to be 5 minutes later, too twitchy to leave it for tomorrow. Run should happen tomorrow morning so I'll check the results then.