Free tools Windows power users keep installed
One-click scans. No signup required.
A 2 GB VPS does not give Apache 2 GB to itself. Apache shares that memory with the Linux kernel, filesystem cache, PHP-FPM or another application runtime, the database, and every other service. When the service becomes inactive, the cause may be an out-of-memory kill, a configuration error, a crashed module, an intentional restart, or another process stopping it. The reliable fix is to identify which event occurred before changing limits.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Start with systemctl status apache2 (or httpd), then read the service and kernel journals, inspect Apache’s error log, and run apachectl configtest before restarting. Once the event is classified, tune memory, repair configuration, or investigate the process that requested the stop.
As an Amazon Associate I earn from qualifying purchases.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11What an inactive Apache service actually tells you
inactive, failed, or a process that disappears from ps describes the outcome, not the reason. Systemd can report a clean stop requested by an administrator, a failed start after a deployment, or a process terminated by a signal. Apache can also remain running while PHP, the database, or another dependency is killed, making the website appear broken even though Apache itself was not the victim.
On a small virtual machine, memory pressure is a shared-resource problem. A request handled by Apache may create an Apache child or thread, invoke PHP, query a database, and allocate kernel and filesystem-cache memory at the same time. The Linux out-of-memory (OOM) killer chooses a process when the kernel cannot satisfy an allocation; it does not necessarily choose Apache. The first task is therefore to establish the event time and match it with log evidence.
Five-minute triage: capture evidence before restarting
Record the approximate time users saw the outage. Include the timezone if logs from several systems will be compared. Then run the commands below as root or with sudo; replace apache2 with httpd on distributions that use that service name.
- Check the unit state and recent exit result.
sudo systemctl status apache2
Note whether systemd says the unit is inactive, failed, exited with a status code, or was killed by a signal. The output often includes the last few log lines and the main-process PID. - Read the boot’s service journal.
sudo journalctl -u apache2 -b --no-pager
This shows starts, stops, restart attempts, watchdog messages, and errors emitted through systemd. By default, service stdout and stderr are directed to the systemd journal, so this record can contain messages that are not in Apache’s own file log. - Read kernel messages for the same boot.
sudo journalctl -k -b --no-pager
Search the output forout of memory,Killed process,oom-kill, or a systemd-oomd event. Also note segmentation faults and filesystem or permission errors. - Inspect Apache’s error log around the event.
Debian-family systems normally use/var/log/apache2/error.log; Red Hat-family systems normally use/var/log/httpd/error_log. Read the lines before and after the timestamp, not just the final line in the file. - Validate configuration before any restart.
sudo apachectl configtest
A successful result means the parser accepted the configuration; it does not prove that a certificate exists, a port is available, or a module is compatible. If the test reports an error, fix that first and run the test again.
Do not repeatedly run systemctl restart while the cause is unknown. Each attempt can overwrite useful context, trigger another deployment hook, or make an intermittent crash harder to correlate with the original event.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsClassify the stop from the evidence
Intentional stop or restart
A clean “Stopping” followed by “Stopped” or a successful start usually means another actor requested the action. Check administrator history, deployment and configuration-management logs, scheduled jobs, package updates, log-rotation actions, and watchdog settings for the recorded time. If Apache’s parent exits cleanly and no fatal error appears, investigate the requester rather than changing worker limits.
Configuration, module, or listener failure
Syntax errors, missing modules, invalid certificate paths, permission failures, duplicate listeners, and occupied ports normally produce deterministic messages. The service may have worked until a file was edited or a package changed, then fail every time it starts. The exact first error in systemctl status, the journal, or the error log is more useful than the final “failed” summary. Correct one reported problem, rerun apachectl configtest, and only then attempt a start.
OOM termination
Kernel or oomd records are the deciding evidence. Look for phrases such as “out of memory,” “Killed process,” or “oom-kill,” and identify the PID and command name. If the record names PHP-FPM, a database, or another service, Apache may only be the component users noticed. systemd-oomd can also record kills caused by memory-used or memory-pressure; those entries belong in the same timeline.
Crash or segmentation fault
A segmentation fault, an abrupt signal-based exit, or a core-dump record points to a crash rather than a normal stop. Correlate the Apache error log, kernel journal, package or deployment history, and any available core-dump record. An incompatible or newly loaded module is a common place to investigate, but do not blame a module without matching the crash time and process information.
When Linux memory pressure kills something
On a 2 GB VPS, the usable budget is lower than 2 GB. The kernel, filesystem cache, Apache parent and workers, PHP-FPM or another runtime, the database, monitoring agents, and control-plane processes all draw from the same physical allocation. A traffic spike, slow upstream request, large database operation, or a deployment can push the combined working set beyond that allocation.
The OOM killer acts when the kernel cannot satisfy a memory request. Its victim is selected by process characteristics and current pressure, so an OOM event does not prove Apache was killed. Confirm the named PID, then check whether the surviving service is healthy. If PHP or the database was killed, Apache may continue accepting connections but return gateway errors or serve incomplete responses.
Immediate actions after confirmed OOM
- Reduce simultaneous Apache work so fewer processes or threads can allocate memory at once.
- Measure and reduce application-runtime memory, such as PHP-FPM worker counts or per-worker limits, and review database buffers and connection counts.
- Stop unused daemons and remove memory-consuming jobs that do not belong on the VPS.
- Verify that swap exists and is not exhausted. Swap can absorb short-lived peaks, but it is slower than RAM and does not make an oversized workload efficient.
- Repeat the observation under representative traffic. A single quiet
free -hreading cannot prove that the peak workload fits.
If the measured workload still exceeds the available budget after these changes, adding RAM is the durable fix. A larger VPS costs more, but it removes the structural constraint instead of merely moving the point at which the OOM killer acts.
Choosing MaxRequestWorkers without guessing
Apache defines MaxRequestWorkers as “the limit on the number of simultaneous requests that will be served.” Its meaning depends on the active multi-processing module (MPM): in prefork it is the maximum number of child processes; in worker and event it limits total threads. It is both a concurrency ceiling and a memory-protection control.
| MPM | What the limit represents | Documented defaults | Why the default is not a 2 GB recommendation |
|---|---|---|---|
| prefork | Maximum Apache child processes | MaxRequestWorkers default: 256 |
Each process has its own resident memory, and PHP modules are commonly loaded into those processes. |
| worker | Total worker threads across children | Defaults are derived from thread settings | Threads share a process address space, but each active request still consumes stack and application memory. |
| event | Total request-serving threads, with keep-alive handling designed for event-driven operation | Defaults are derived from thread settings | Connection efficiency does not remove memory consumed by active application work. |
For worker and event configurations, the documented relationship of ServerLimit 16 and ThreadsPerChild 25 yields 400 threads where those settings apply. These figures describe Apache’s defaults, not a safe capacity for a particular VPS. Apache warns that setting ServerLimit or MaxRequestWorkers above what the machine can handle can prevent startup or destabilize the host.
A measurement-based sizing method
- Identify the active MPM. Use the loaded-module list for your distribution, such as
apachectl -M, and find the line formpm_prefork,mpm_worker, ormpm_event. Do not apply prefork arithmetic to a threaded MPM. - Measure representative worker memory. Observe Apache during normal and busy periods. On a prefork installation, a command such as
ps -o pid,rss,cmd -C apache2(or-C httpd) shows resident-set size in kilobytes for each process. Measure PHP-FPM and database processes separately; their memory is not included in Apache’s RSS. - Reserve memory for everything else. Set aside a deliberate budget for the kernel, filesystem cache, the database, PHP or another runtime, monitoring, and short-lived spikes. The remainder is the maximum Apache budget, not a target to consume continuously.
- Divide the Apache budget by measured per-worker memory. For an illustrative calculation only, if 1,200 MB is genuinely available for Apache and a representative prefork child uses 90 MB RSS, the arithmetic ceiling is 13 children (1,200 ÷ 90, rounded down). Re-measure under your own workload; this example is not a universal setting.
- Apply one change at a time. Lower or raise
MaxRequestWorkersin the MPM configuration, validate withapachectl configtest, and restart through the service wrapper. Then watchfree -h,vmstat, response latency, and the journal during representative traffic.
The prefork manual’s rule is the right constraint: the value must be large enough for expected concurrency but small enough to leave physical RAM for every process. A log line saying “server reached MaxRequestWorkers” does not automatically mean the value should be increased. It can indicate genuine overload, slow upstream work, or a memory-safe ceiling that is already doing its job.
What happens when the value is too low or too high
- Too low: requests wait in Apache’s queue, so latency rises and clients may time out during bursts. Memory use is usually safer, and the change is quickly reversible.
- Too high: more requests can execute concurrently, but the combined Apache, runtime, and database footprint can trigger swapping, OOM kills, or an unstable host. Excessive
ServerLimitvalues can also cause Apache to reject startup. - Changed without measuring: the result is unpredictable because worker size varies with enabled modules, code paths, request payloads, and upstream behavior.
Fixing configuration, module, and port errors
Syntax or directive mistakes
Run apachectl configtest and fix the first file and line it names. Common examples include a misspelled directive, an unmatched section, a directive unavailable in the active MPM, or a site file enabled with invalid syntax. Do not mask the first error by deleting unrelated configuration; validate after each correction.
Missing modules and invalid paths
A configuration can parse on one server and fail on another when a required module is not installed or enabled. The error log identifies the module or directive. Certificate, key, document-root, include, and log paths must exist and be readable by the account Apache uses. Correct ownership or permissions carefully; broadening permissions indiscriminately creates a security problem while leaving the startup failure unresolved.
Duplicate listeners and occupied ports
If another process already owns the configured address and port, Apache reports a bind or “address already in use” error. Identify the owning service, decide which daemon should listen there, and remove the duplicate listener or change the intended binding. Restarting Apache repeatedly cannot free a port held by a different process.
Crashes, deployments, and external restarts
A segmentation fault or abrupt signal-based exit requires a different path from OOM tuning. Match the exact timestamp in the Apache error log with the kernel journal and package history. If the crash began after a module, runtime, or library update, temporarily isolate that change in a maintenance window and verify the result. Preserve the relevant logs and core-dump metadata before repeatedly restarting.
Clean exits point toward an external actor: an administrator command, deployment hook, package update, log-rotation action, watchdog, or scheduled job. Review those systems’ records for the same minute. If a health checker restarts Apache whenever a dependency fails, fix the dependency or the check’s threshold rather than treating every restart as an Apache crash.
Compare remedies by evidence, impact, and durability
| Remedy | Use when the evidence shows | Memory reclaimed or protected | Concurrency and latency effect | Durability |
|---|---|---|---|---|
Lower MaxRequestWorkers |
Apache concurrency is exhausting the shared budget | Caps simultaneous Apache processes or threads | Can queue requests and increase latency during peaks | Quick, reversible protection; does not reduce per-request memory |
| Reduce PHP or application memory | Runtime workers are the largest consumers or are OOM victims | Reduces memory per worker or the number of workers | May slow application throughput if undersized | Often durable, but requires application and runtime changes |
| Reduce database memory or connections | The database is consuming the shared budget | Returns RAM to the whole host | Can increase query latency or connection wait time | Durable when aligned with actual query load |
| Add or enlarge swap | Short-lived peaks cause abrupt kills and RAM headroom is close | Provides slower overflow capacity | Heavy swapping can make requests very slow | Useful safety margin, not a substitute for sufficient RAM |
| Upgrade VPS memory | Measured peak workload cannot fit after tuning | Increases physical headroom for every service | Preserves concurrency and reduces pressure | Most durable, with recurring cost |
| Repair configuration or remove duplicate listener | Startup fails deterministically | Does not change memory; restores valid startup | No intentional concurrency change | Durable once the offending change is corrected |
A controlled recovery and tuning procedure
- Preserve the incident record. Save the relevant
systemctl status, service journal, kernel journal, and Apache error-log lines with timestamps. - Classify before editing. Mark the event as intentional restart, configuration or listener failure, crash, or OOM. If evidence is mixed, keep investigating rather than applying several fixes at once.
- Restore service safely. For a configuration issue, run
apachectl configtestuntil it succeeds, then usesudo systemctl start apache2or the appropriate service name. For OOM, first stop nonessential jobs or reduce load so the restart does not immediately recreate the pressure. - Change the narrowest control. Lower
MaxRequestWorkersfor Apache concurrency pressure; adjust PHP, database, or application settings when those processes dominate; repair the named file or module for deterministic startup errors. - Observe the busy period. Use
free -hfor available memory and swap,vmstatfor paging and run-queue behavior, and the journals for new OOM or crash entries. Compare these readings with request latency and error rates. - Document the chosen ceiling. Record the active MPM, measured worker memory, reserved non-Apache budget, resulting calculation, and the date of the change. Recalculate after enabling modules, changing PHP code, adding a database, or moving to a different traffic pattern.
Preventing the next unexplained stop
- Keep Apache, PHP or the application runtime, and the database under the same memory review; a single-service dashboard is incomplete.
- Alert on low available memory, swap activity, rising request queues, and repeated systemd restarts before the OOM killer is invoked.
- Retain enough journal and Apache error-log history to correlate a stop with deployments, package updates, and log rotation.
- Validate configuration in deployment automation with
apachectl configtestbefore asking systemd to reload or restart. - Review the active MPM and its
ServerLimit,ThreadsPerChild, andMaxRequestWorkersvalues after every architecture change. - Treat “reached MaxRequestWorkers” as a capacity signal. Investigate slow upstream requests and memory use before raising the ceiling.
Bottom line
Apache stopping on a 2 GB VPS is a symptom, not a diagnosis. The service and kernel journals, Apache error log, and a configuration test distinguish an OOM kill from a rejected configuration, crash, or intentional restart. There is no universally safe MaxRequestWorkers value for every 2 GB server: measure the actual stack, reserve memory for the operating system and other services, and choose a limit that leaves headroom.
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.
