Details
-
Improvement
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
Jenkins 2.332.3
Plugins are as recent as possible
Description
We have some labels assigned to various nodes and we run certain things in a relatively complex build process involving a shared Jenkins library. There it happens quite often that the pipeline has multiple nested 'node' steps running with exactly the same labels.
node('mylabel') { for (int i = 0; i < 1000; i++) { node('mylabel') { sleep(10) } } }
Jenkins ends up switching the node all the time, causing quite a bit of lock contention on the Queue processing. In this case the node step should have some kind of a mechanism to know that it is already on a suitable node and no node switch is required.
Imagine this scenario with a 100 jobs with around 20 parallel stages each, the builds grind to a halt. This should be more scalable.
Attachments
Issue Links
- relates to
-
JENKINS-69025 Massive build slowdown with scripted pipeline (and some plugins?) and many builds in queue
-
- Open
-
Activity
Edgars Batna
created issue -
Edgars Batna
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Priority | Minor [ 4 ] | Major [ 3 ] |
Edgars Batna
made changes -
| Issue Type | Bug [ 1 ] | Improvement [ 4 ] |
Edgars Batna
made changes -
| Link | This issue relates to JENKINS-69025 [ JENKINS-69025 ] |
Edgars Batna
made changes -
| Description |
We have some labels assigned to various nodes and we run certain things in a relatively complex build process involving a shared Jenkins library. There it happens quite often that the pipeline has multiple nested 'node' steps running with exactly the same labels.
{code:java} node('mylabel') { for (int i = 0; i < 1000; i++) { node('mylabel') { sleep(10) } } } {code} Jenkins ends up switching the node all the time, causing quite a bit of lock contention on the Queue processing. In this case the node step should have some kind of a mechanism to know that it is already on a suitable node and no node switch is required. Imagine this scenario with a 100 jobs with around 20 paralllel stages each, the builds grind to a halt. This should be more scalable. |
We have some labels assigned to various nodes and we run certain things in a relatively complex build process involving a shared Jenkins library. There it happens quite often that the pipeline has multiple nested 'node' steps running with exactly the same labels.
{code:java} node('mylabel') { for (int i = 0; i < 1000; i++) { node('mylabel') { sleep(10) } } } {code} Jenkins ends up switching the node all the time, causing quite a bit of lock contention on the Queue processing. In this case the node step should have some kind of a mechanism to know that it is already on a suitable node and no node switch is required. Imagine this scenario with a 100 jobs with around 20 parallel stages each, the builds grind to a halt. This should be more scalable. |