Poll the count of running step executions #3791
Conversation
In a combination of short poll interval and large number of step executions that take a long time to run, memory consumption can go high - each step execution has its own reference to a job execution, which refers step executions for the job. This means that the job executions are different instances, resulting in creating a lot of objects. Instead, we query the database to get the number of step executions that are still running. Once all of them are finished, we then would fetch all steps and assign the same job execution that can be a shared instance.
fmbenhassine
added
in: core
pr-for: enhancement
status: waiting-for-triage
|
Is there any plan to fix this issue? |
|
Thank you for this PR! I believe this change set goes in the right direction as mentioned in #3790 (comment), which is similar to your proposal in the initial issue description. However, since 4.3 is the last minor version of v4, we cannot introduce such a change set in a patch version of 4.3.x. The earliest version to introduce such changes is 5.1.0. Moreover, there are other code changes (not related to this PR) that need to be introduced in order to fix the issue in a clean way. So I will to postpone this PR to 5.1.0 and let you know when it is a good time to rebase it on the main branch. Is that ok for you? Otherwise please let me know and I will take care of all the changes. In the meantime, the performance issue will be addressed with #4208. |
fmbenhassine
added
status: waiting-for-reporter
Could you please rebase this PR on the latest |
|
No rebase on the latest main as requested, so I am closing this PR. Thank you anyway. PS: the continuation on this matter is here: #4705 (comment) |
fmbenhassine
removed
the
status: waiting-for-reporter
In a combination of short poll interval and large number of step executions that take a long time to run, memory consumption can go high - each step execution has its own reference to a job execution, which refers step executions for the job. This means that the job executions are different instances, resulting in creating a lot of objects.
Instead, we query the database to get the number of step executions that are still running. Once all of them are finished, we then would fetch all steps and assign the same job execution that can be a shared instance.
Closes #3790