Determine the optimal forks setting for Ansible based on control node resources.
The forks setting controls how many hosts Ansible connects to and runs tasks against simultaneously. Setting it too low under-utilizes the control node and slows runs; setting it too high can exhaust CPU or memory on the control node, or overload the network/SSH capacity of target hosts. This calculator picks the largest safe value: the smaller of your total host count, a CPU-based ceiling (2× cores, since fork processes are largely I/O-bound waiting on SSH), and a memory-based ceiling (available memory ÷ per-fork footprint).
optimal_forks = min(hosts, cpu_cores × 2, available_memory_MB / per_fork_MB)
Ansible forks spend most of their time waiting on network I/O (SSH round trips) rather than burning CPU continuously, so a control node can support more concurrent forks than raw core count without CPU becoming the bottleneck — 2× is a conservative multiplier for this I/O-bound pattern.
There's no benefit — Ansible can never run more concurrent connections than there are hosts in the current batch, so forks beyond your host count simply go unused.
It varies with module complexity and fact size, but 40-80MB per fork process is a reasonable planning number for typical playbooks; modules that gather large facts or process big data structures can use more.
Yes, for a baseline — most teams set a global default in `ansible.cfg` sized for their typical control node, then override with `--forks` for unusually large or resource-constrained runs.