Calculate process fork rate per second and its impact on system overhead.
/proc/stat's 'processes' line is a cumulative counter of every fork/clone-based process creation since boot (not the current count of live processes — that's a separate figure); sampling it twice and dividing by elapsed time gives forks per second, a useful process-churn metric independent of how many processes happen to be alive at any instant. A sustained fork rate above roughly 1000/sec is unusual for typical server workloads and often points to something worth investigating — a genuine fork bomb, a misbehaving supervisor restarting a crashing process in a tight loop, or a request-per-process architecture (like traditional CGI) under heavy load.
Fork rate
forks_per_sec = (processes_t1 − processes_t0) / interval_seconds
No — it's a cumulative, ever-increasing counter of total fork/clone calls since boot, not a live count. The current live process count instead comes from counting entries under /proc/ or from `ps -e | wc -l`; you need this cumulative counter specifically to compute a creation rate over time.
Common causes include a genuine fork bomb (a process recursively spawning copies of itself, sometimes malicious or accidental via a shell script bug), a supervisor (systemd, a custom watchdog) rapidly restarting a crash-looping service, or architectures that spawn a fresh process per unit of work (classic CGI scripts, or scripts calling external commands in a tight loop) under high load.
Each fork/exec cycle has real overhead — copying (or COW-mapping) the parent's memory layout, setting up a new address space, and kernel bookkeeping — that adds up as pure overhead separate from the actual useful work being done, and can also accelerate PID/thread-count exhaustion even when other resources look fine.