This is expected behavior as the first preference of assigning the threads is to the JOB instance which takes the job run.
Typically, local work item threads on an Application Server process all work items for a job before those work items can be distributed to other Application Servers. However, if all local work item threads are already processing work items, the Application Server distributes work items to other Application Servers that have idle work item threads.
Thanks for the explanation !
any job routing rules in place for this job ?
this is a graph of used WIT ? were other jobs running on the green appserver? because if not i'd expect to see the peak at 50 wit, not 100 right ?
Yeah good point.
We just have one big Job-Routing Rule called "All Jobs" , which lets us take AppServers out of the processing in case of maintenance is required.
The graph shows this value from the Memory Monitor: Used Work Item Threads: 3/100
As far as i can tell there was no other "big" job with a larger number of targets running at the same time.
It nearly seems as if the 50 in parallel is not taken into account ?!
you sure you had the parallelism set to 50 on that job? because it looks like no. how quickly does one target take for this job ?
Yeah, 100% sure !
The job will run again tonight.
The snapshot of a component takes around 1 minutes on average.