Calculate maximum concurrent processes supportable given CPU and memory constraints.
Every process occupies a PID slot, and Linux caps the total addressable PID space via kernel.pid_max (default 32768 on 32-bit-compatible configs, up to 4194304 on 64-bit systems with the wider PID namespace enabled) — summing every process state (running R, sleeping S/D, stopped T, zombie Z) against that ceiling shows real headroom before fork() calls start failing with EAGAIN, a failure mode that surfaces suddenly and system-wide rather than gracefully per-application.
Total processes and usage
total = running + sleeping + stopped + zombie; usage% = total / pid_max × 100
`sysctl -w kernel.pid_max=4194304` raises it immediately (up to the 64-bit-supported maximum), and adding it to /etc/sysctl.conf or a drop-in under /etc/sysctl.d/ makes it persist across reboots. Note some very old tooling assumes PIDs fit in a 16-bit range, though this is rare on modern systems.
Yes — a zombie retains its PID and a minimal task_struct entry (just enough to report its exit status to the parent via wait()) until the parent reaps it, so a large buildup of unreaped zombies does consume PID space and can contribute to hitting pid_max, even though zombies use essentially no CPU or memory otherwise.
S (interruptible sleep) processes are waiting on an event (like a timer or a signal) and can be woken by signals; D (uninterruptible sleep) processes are waiting specifically on I/O completion (typically disk) and cannot be interrupted by signals, including SIGKILL — a large, persistent count of D-state processes usually indicates a storage bottleneck.