Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Apache usually creates child processes because its active Multi-Processing Module (MPM) is maintaining enough capacity for current and expected requests. A rising process count is not automatically a fault: it may indicate genuine concurrency, a deliberate spare-capacity setting, a threaded MPM’s process arithmetic, or old workers finishing a graceful restart. It becomes a problem when the configured ceiling exceeds available memory, workers remain stuck in graceful shutdown, or request capacity is exhausted.
The safe remedy is to identify the active MPM, correlate the process list with Apache’s error log and mod_status, then change one capacity setting at a time. Do not raise MaxRequestWorkers or ServerLimit simply because the process list looks large.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What Apache child processes do
The parent Apache process accepts control signals and manages a pool of children. Depending on the MPM, a child is either a process that handles requests itself or a process containing request-serving threads. Apache starts enough children to provide immediate capacity, creates more when spare capacity falls short, and retires excess or obsolete children.
That means “too many” has two different meanings. You may be seeing a healthy pool sized for traffic, or you may be seeing capacity that your host cannot afford. The same process count can be normal under one MPM and wasteful under another, so identify the architecture before changing limits.
#1 Best Overall
Prefork: one request-serving process per child
With the prefork MPM, each child is a separate process and normally handles one request at a time. In this mode, MaxRequestWorkers is both the maximum number of simultaneous requests and the maximum number of request-serving child processes. The current Apache documentation lists 256 as the prefork default; going above that value requires a suitable ServerLimit.
Separate processes provide strong isolation and work with modules that are not thread-safe, but each process carries its own Apache, TLS, and application-library memory. A high prefork count can therefore consume RAM quickly.
Worker and event: threads inside child processes
Worker and event are hybrid MPMs. Apache starts child processes, and each child contains multiple request-serving threads. Here, MaxRequestWorkers counts threads, not processes. The approximate process requirement is:
child processes = ceil(MaxRequestWorkers / ThreadsPerChild)
The result is bounded by ServerLimit. For example, 400 workers with 25 threads per child require about 16 child processes, provided ServerLimit permits that many. A process list that looks small can still represent a large request capacity, while a configuration with many processes may simply use fewer threads per process.
Rank #2
- Used Book in Good Condition
Threaded MPMs can serve the same concurrency with fewer processes than prefork, reducing duplicated process memory in many deployments. They also require thread-safe modules and have different behavior during graceful restarts, so lower process count alone is not a reason to switch.
Why Apache creates more children
Spare-capacity directives
Apache maintains idle capacity so a burst does not have to wait for a process or thread to be created. In prefork, StartServers sets the initial child count, MinSpareServers expresses the minimum idle-process target, and MaxSpareServers limits how many idle processes Apache keeps. MaxRequestWorkers remains the hard request and process ceiling.
When idle children fall below MinSpareServers, the parent creates more. Under a sustained shortage, prefork increases creation exponentially rather than starting every missing process at once. Apache describes the sequence this way: “It will spawn one, wait a second, then spawn two, wait a second, then spawn four.” This can make a busy server’s process count rise rapidly even though Apache is following its capacity policy.
Worker and event use the corresponding thread-oriented spare settings, MinSpareThreads and MaxSpareThreads. Their children are still processes, but the spare target is measured in available threads.
Real concurrent traffic
A busy site can legitimately approach its configured worker limit. Slow application responses, large downloads, TLS work, and clients holding keep-alive connections all occupy capacity for different lengths of time. If traffic rises above the available workers, additional children or threads are created until the configured limits are reached. Once MaxRequestWorkers is full, further connection attempts are normally queued.
High spare settings
A high MinSpareServers or MinSpareThreads intentionally keeps more idle capacity. That can reduce latency during bursts but increases baseline memory use. Repeated traffic peaks and troughs can also make creation and retirement visible as a fluctuating process count.
When the count really is excessive
Configured limits exceed the machine’s capacity
ServerLimit is the upper bound on active child processes. It is not a performance target. Setting it or MaxRequestWorkers above what the host can sustain can prevent Apache from starting correctly or destabilize the entire machine through memory pressure and swapping.
Size limits from measured concurrency and memory, not from a large value copied from another server. Leave room for the operating system, filesystem cache, TLS libraries, Apache’s parent process, the application runtime, database clients, monitoring agents, and short-lived command-line work.
Graceful restarts leave old children behind
A graceful reload lets existing children finish open connections before they exit. During that interval, new children serve new work while old-generation children remain in a Graceful or stopping state. Slow clients, long keep-alive connections, downloads, and requests that do not finish promptly can delay their exit.
Free tools Windows power users keep installed
One-click scans. No signup required.
Frequent reloads can therefore produce several generations at once: new children doing work, older children waiting for connections to close, and still older children about to exit. The total process count may look abnormally high even though each generation is temporary. Repeated graceful restarts, rather than a low ServerLimit, are the first thing to investigate when the status page shows many old or Graceful processes.
Threaded-MPM arithmetic is inconsistent
For worker and event, ServerLimit must provide enough processes for MaxRequestWorkers at the selected ThreadsPerChild value. If the numbers do not line up, Apache may be unable to reach the intended worker count, or administrators may raise the process limit unnecessarily. Treat the worker total, thread count, and process limit as one calculation rather than independent knobs.
Diagnose before changing a directive
- Identify the active MPM and Apache version. On systems using Apache HTTP Server, run the distribution’s module-list command, such as
apachectl -Morapache2ctl -M, and look for a loadedmpm_module. On systems using thehttpdbinary, the equivalent is commonlyhttpd -M. Record the version shown by the local binary because defaults and available directives depend on the release. - Read the error log at the time of the spike. Search for
MaxRequestWorkers, scoreboard warnings, child-exit messages, graceful-restart notices, and messages about failing to create a process or thread. A limit warning points to saturation; repeated graceful messages point to restart or connection-lifetime issues. - Inspect
mod_status. Use the server-status endpoint only where it is access-controlled. Compare busy and idle workers, process IDs, child-generation or Graceful states, and the connection or keep-alive columns. A large idle pool suggests spare settings; mostly busy workers suggest real concurrency; many old-generation entries suggest graceful shutdown is waiting. - Record every capacity directive. Capture
StartServers,MinSpareServers,MaxSpareServers,MinSpareThreads,MaxSpareThreads,ThreadsPerChild,MaxRequestWorkers,ServerLimit, and anyMaxConnectionsPerChild. Record values from the effective configuration, not only from a sample file that may be overridden elsewhere. - Measure resident memory. Observe several representative Apache children during normal and peak traffic. Prefork measurements should include the process resident set; for threaded MPMs, account for the shared process footprint and thread-related memory. Measure the application runtime and database clients as well, because Apache’s apparent free RAM may already be committed elsewhere.
- Change one control and observe. Apply a single adjustment, reload gracefully, and watch request queueing, memory pressure, swapping, busy and idle workers, and the number of Graceful processes. Keep a before-and-after record so a change that improves one symptom does not hide another.
Choose the fix that matches the symptom
Prefork is below its spare target during genuine demand
If status data shows real traffic and idle children repeatedly fall below MinSpareServers, keep a modest spare pool proportional to the measured burst. A higher minimum can reduce process-creation latency, but it also commits memory even when traffic is quiet. Do not raise MaxRequestWorkers until the memory calculation shows that the host can support the additional processes.
MaxRequestWorkers is reached and memory remains available
When the log and status page show all workers busy, requests queue, and the host still has measured headroom, increase MaxRequestWorkers cautiously. In prefork, raise ServerLimit as required by the Apache documentation when the new worker ceiling exceeds the current process limit. Recheck file-descriptor capacity and downstream application limits before assuming Apache is the only bottleneck.
Memory pressure or swapping appears
Reduce MaxRequestWorkers and the spare-process or spare-thread limits to keep concurrency inside the memory budget. Also reduce the per-request application cost, move application execution to an appropriately sized separate process manager where that architecture fits, and investigate leaks or unusually large responses. Lowering the worker ceiling may increase queueing, but swapping usually creates a larger outage than a controlled queue.
Event shows many Graceful or old-generation children
Do not immediately increase ServerLimit. Find out why old children cannot exit: check restart frequency, slow clients, long keep-alive periods, downloads, and requests that remain open. Correct the restart schedule or connection behavior first. A larger process ceiling can conceal the buildup while consuming more memory.
Best Value
- Used Book in Good Condition
Worker or event values do not divide cleanly
Choose a ThreadsPerChild value appropriate for the module set and make MaxRequestWorkers an appropriate multiple of it. Then ensure ServerLimit can accommodate the required process count. For example, with 25 threads per child, a 400-thread ceiling maps cleanly to 16 processes; a 410-thread ceiling needs 17 processes if Apache is to provide the full configured capacity.
Children churn continuously
Some turnover is expected as traffic changes. If children are repeatedly created and killed at steady load, correlate the timing with spare limits, graceful reloads, child-exit errors, crashes, and MaxConnectionsPerChild. That directive can intentionally recycle children after a configured number of connections, which may limit leaks but will also create regular replacement activity. Change it only when the reason for recycling is understood.
How the main directives fit together
| Directive | Prefork meaning | Worker/event meaning | What to watch |
|---|---|---|---|
StartServers |
Initial child processes | Initial child processes, subject to the MPM | Startup burst and baseline memory |
MinSpareServers |
Minimum idle processes | Not the normal threaded spare control | Process creation when idle capacity falls short |
MaxSpareServers |
Maximum idle processes retained | Not the normal threaded spare control | Idle memory and process retirement |
MinSpareThreads |
Not the normal prefork control | Minimum idle threads | Thread creation during bursts |
MaxSpareThreads |
Not the normal prefork control | Maximum idle threads retained | Idle thread capacity and churn |
ThreadsPerChild |
Not applicable | Threads in each child process | Process-count arithmetic and module behavior |
MaxRequestWorkers |
Maximum simultaneous requests and child processes | Maximum simultaneous request-serving threads | Queueing and saturation |
ServerLimit |
Upper child-process limit; required when prefork workers exceed the documented default ceiling | Upper child-process limit for the thread calculation | Memory, startup validity, and achievable capacity |
MaxConnectionsPerChild |
Optional child recycling after a connection count | Optional child recycling after a connection count | Leak mitigation versus intentional churn |
The Apache documentation lists a 20,000 ServerLimit ceiling for worker and event and 200,000 for prefork in Apache 2.4 documentation. Those are hard upper bounds documented by Apache, not recommended operating values. A host may become unstable long before reaching either number.
Memory sizing that avoids a self-inflicted outage
Start with memory that is actually available to Apache, not total installed RAM. Reserve headroom for the operating system and every other service. Then multiply the measured incremental cost of concurrency by the intended worker count.
- For prefork, use the resident memory of representative children, including the application modules they load.
- For worker or event, account for the shared process footprint, thread stacks, loaded modules, and any per-connection buffers; do not multiply a whole process resident set by every thread.
- Include TLS buffers, logging, proxy or CGI components, database clients, and the application runtime.
- Check file-descriptor limits as well as RAM. A larger worker ceiling can require more sockets, log files, pipes, and upstream connections.
- Leave enough margin for traffic bursts rather than sizing to a single quiet sample.
If the calculation is uncertain, choose the lower ceiling, observe under a controlled peak, and increase only after memory and latency remain healthy. Apache’s queueing behavior is measurable; swapping and an out-of-memory kill are much harder to recover from.
Understanding process counts in server-status
The operating-system process list is only one view. mod_status connects PIDs and workers to Apache’s scoreboard, allowing you to distinguish idle capacity from useful work. A prefork display with many idle children and few busy entries points toward spare settings. A display dominated by busy workers points toward traffic, slow requests, or a saturated downstream service. Worker and event displays require counting threads as well as processes.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsLook specifically for children marked Graceful, stopping, or belonging to an older generation. Those entries explain why a graceful reload can temporarily increase the total even when the new generation is correctly sized. If the same PIDs remain for an unusually long period, inspect the connections attached to them instead of raising global limits.
A practical change-and-rollback method
- Save the effective configuration and current status output.
- Define the symptom in measurable terms: peak busy workers, queued requests, resident memory, swap activity, or Graceful-process age.
- Select one directive family: spare settings, the worker ceiling, thread arithmetic, or restart/connection behavior.
- Validate the configuration before reloading it with the platform’s Apache configuration-test command.
- Reload gracefully so active requests are not abruptly terminated, unless an emergency requires a different operational procedure.
- Watch logs, status, memory, swap, latency, and process generations through a representative traffic period.
- Roll back if memory pressure, queueing, error rates, or old-generation buildup worsens.
Preventing the problem from returning
- Keep a record of the active MPM and every capacity directive after upgrades or configuration changes.
- Alert on sustained
MaxRequestWorkerssaturation, rising swap, and a growing population of Graceful children. - Review restart automation; a reload loop can look like a capacity problem.
- Track busy versus idle workers rather than process count alone.
- Re-measure after changing application modules, TLS settings, PHP or other runtimes, proxying, or database connection pools.
- Protect the server-status endpoint and expose only the operational data administrators need.
Bottom line
Apache spawns child processes to maintain request capacity. In prefork, the process count directly represents the possible simultaneous requests; in worker and event, threads determine request capacity and processes are the containers for those threads. A high count can be normal, deliberately retained spare capacity, or old children completing a graceful restart. Identify the MPM, inspect the error log and scoreboard, measure memory, and tune the smallest relevant control. The correct setting is the one that meets measured concurrency without exceeding the host’s memory and file-descriptor budget.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
