action #23318
closedLimit gru tasks
0%
Description
We right now schedule one limit_assets and one limit_results job for every ISO posted. Which was fine when all ISOs
posted were either TW or SLES builds - i.e. rarely.
But now we see dozens of incidents posted as ISO per hour - and the GRU is not able to run them as quickly. And fact is,
the actual task is a global one, so there is no need to do this more often than once in a while. We can't really decouple
it from the actual load, but binding it to ISO posts sounds wrong too.
Just brainstorming possibly solutions:
- keep binding it to ISO post, but make sure there is only one of such job around
- only trigger the task on every Xth job created (where X could be 1000 or generally configurable)
this is mildly urgent as I'm removing 1000 gru tasks daily from the backlog
Updated by coolo over 7 years ago
One (actually independent) option is to check why limit_results is so slow :)
Updated by coolo about 7 years ago
- Target version set to Ready
for limit_results Xth job is actually the better option, but limit_assets we need to keep connected to assets posted. But possibly to Xth asset.
Updated by szarate over 6 years ago
- Related to action #18462: Move GRU tasks into Minion jobs added
Updated by szarate over 6 years ago
- Target version changed from Ready to Current Sprint
Updated by EDiGiacinto over 6 years ago
- Status changed from In Progress to Resolved
- Target version changed from Current Sprint to Done
We have now a ttl mechanism ( https://github.com/os-autoinst/openQA/pull/1637 ) to be sure that very old tasks ( 2 days ) are not executed, but with the recent optimizations by coolo and the Minion migration ( with error handling ) this became just a failsafe option as we don't have too much tasks anymore in the backlog.