set max dispatch workers to same as max forks

[kdelee]

Right now, without this, we end up with a different number for max_workers than max_forks. For example, on a control node with 16 Gi of RAM,
max_mem_capacity w/ 100 MB/fork = (16*1024)/100 --> 164
max_workers = 5 * 16 --> 80

This means we would allow that control node to control up to 164 jobs, but all jobs after the 80th job will be stuck in waiting waiting for a dispatch worker to free up to run the job.

SUMMARY

Have max_workers == max forks based on memory capacity to prevent situations where we start jobs because we believe there is enough capacity to control the job, but there are not enough dispatch workers available to actually do so. In cases where a user decides to use the "capacity adjustment" or otherwise limit how many jobs a control node can control, we

ISSUE TYPE

• Bugfix Pull Request

COMPONENT NAME

• API

AWX VERSION

ADDITIONAL INFORMATION

@jainnikhil30 noticed jobs hanging out in waiting for a long time when he was running many concurrent jobs, @AlanCoding helped identify how the max number of dispatch workers factors into that.

[jainnikhil30]

+1 tested the patch. It works. Before the patch with 16gb node only 80 jobs were running and rest all went into waiting. But with this patch I am able to run 110 jobs which is close to the max capacity.

[AlanCoding]

I'm a little bit worried about increasing the dispatcher workers in general, because this puts us closer to... well... failure. But that should be handled by our general coefficients.