1a4c599a4d
* This patch removes the approach with DB polling needed to determine if a "join" task is ready to run. Instead of running a periodic scheduled job, each task completion now runs the algorithm that finds all potentially affected join tasks and schedules just one job (instead of a periodic job) to check their readiness. This solves a problem of system cascaded overloading in case of having many very large joins (when a workflow has many joins with many dependencies each). Previously, in such case Mistral created too many periodic jobs that just didn't let the workflow progress well, i.e. most CPU was used by scheduler to run those periodic jobs that very rarely switched "join" tasks to the RUNNING state. Change-Id: I5ebc44c7a3f95c868d653689dc5cea689c788cd0 Closes-Bug: #1799356
10 lines
385 B
YAML
10 lines
385 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Removed DB polling from the logic that checks readiness of a "join" task
|
|
which leads to situations when CPU was mostly occupied by scheduler that
|
|
runs corresponding periodic jobs and that doesn't let the workflow move
|
|
forward with a proper speed. That happens in case if a workflow has lots
|
|
of "join" tasks with many dependencies. It's fixed now.
|
|
|