What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
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
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
A Linux VPS out-of-memory (OOM) error means available RAM, swap, or a service’s memory allowance could not satisfy an allocation. First determine whether the kernel OOM killer or systemd-oomd acted, then identify the process that consumed memory. Add swap only as emergency headroom, reduce or bound the workload, and resize the VPS when measured demand still exceeds its memory budget.
What an out-of-memory error means
Linux can run out of memory at several layers. Physical RAM may be full, swap may be exhausted, a systemd service may hit its cgroup limit, or a container may exceed its configured allowance. The visible symptom can be a terminated web worker, database, build process, container, or scheduled job rather than a complete server failure.
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 minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall
The kernel OOM killer
When the kernel cannot satisfy an allocation, it chooses a process to kill and records the decision in the kernel log. With the normal vm.panic_on_oom=0 setting, Linux generally kills a process and attempts to keep the system running. Values 1 or 2 request panic behavior for specialized failover policies, not ordinary VPS recovery.
The process named in the OOM record is your first lead. High RAM or CPU use on a VPS is normally caused by an application or kernel process running on that VPS, so investigate the named workload before treating the event as a generic Linux defect.
#1 Best Overall
- A-Tech RAM Memory compatible for select DDR4 Servers & Workstation systems only; (*WILL NOT WORK with Desktop Computers, Laptop Computers, or PCs of any kind*)
- 128GB RAM Kit (8 x 16GB Modules); DDR4 DIMM 288 Pin; Speeds up to 2133MHz PC4-17000 (PC4-2133P)
- ECC Registered RDIMM; 2Rx4 - Dual Rank x4; JEDEC DDR4 standard 1.2V
- Improves system performance, workload capacity, and reduces bottlenecks by increasing memory (RAM) resources
- Note: This memory is ECC Registered and cannot be mixed with different ECC types such as ECC Unbuffered, ECC Load Reduced, or Non-ECC Unbuffered; (Memory compatibility can vary among different system models and their installed components; please verify compatibility and follow memory channel guidelines to ensure maximum performance)
The systemd-oomd userspace killer
On systems using cgroups v2 and pressure-stall information (PSI), systemd-oomd can act before the kernel reaches a hard OOM. It watches memory pressure and swap behavior, then terminates eligible systemd units. Its logs can therefore show a unit being killed even when the kernel log has no matching “Killed process” line.
The systemd documentation highly recommends having swap because swap gives systemd-oomd time to react. With no swap, pressure can become abrupt and the daemon may not respond before the kernel is forced to kill something.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Diagnose the event before changing settings
Capture evidence while it is still available. Changing swappiness, overcommit, or service limits before identifying the consumer can hide the original failure and create a second one.
1. Read the current and previous boot logs
- For the current boot, run
journalctl -k -b. - For the boot before a reboot, run
journalctl -k -b -1. - Search the output for
oom,out of memory, andkilled process. For example:journalctl -k -b -1 | grep -iE 'oom|out of memory|killed process'. - If the kernel ring buffer is available, check timestamped messages with
dmesg -T.
Record the timestamp, process name, PID, requested allocation, and any memory-control-group path. A process killed during a deployment may point to build concurrency; the same process killed every night may indicate a scheduled job or leak.
2. Measure RAM, swap, and disk capacity
- Run
free -hto see total, used, available, and swap memory. - Run
swapon --showto list active swap devices or files. Empty output means no swap is enabled. - Inspect detailed counters with
cat /proc/meminfo, includingMemAvailable,SwapFree, and reclaimable memory. - Run
df -hon the filesystems that hold logs and a prospective swap file. A full filesystem can prevent logging and swap-file creation.
Do not equate “used” RAM in free -h with an immediate leak: Linux uses otherwise idle memory for cache. The more useful warning signs are low MemAvailable, exhausted swap, sustained reclaim or swap activity, and a process whose resident set keeps growing.
3. Find the largest resident processes
Take a point-in-time ranking with:
ps -eo pid,ppid,comm,%mem,rss --sort=-rss | head -n 20RSS is resident memory in kilobytes. Confirm the result in top or htop, because a short-lived job may disappear between samples. Identify whether the largest consumer is a database, language runtime, web worker, container, compiler, image processor, or kernel-related allocation.
For a suspected process, note its parent PID, command line, start time, and number of workers. Ten moderately sized workers can consume more memory than one large master process, and a parent process may restart a child immediately after it is killed.
4. Check the service and cgroup budget
For a systemd-managed service, replace <unit> with the actual unit name:
systemctl status <unit>
journalctl -u <unit>
systemctl show <unit> -p MemoryCurrent -p MemoryMax -p ManagedOOMSwap -p ManagedOOMMemoryPressureMemoryCurrent shows current cgroup usage, while MemoryMax reveals a configured ceiling. A service can be killed by its own cgroup even when the VPS still has free memory.
If systemd-oomd is installed, inspect its decisions with journalctl -u systemd-oomd. Run oomctl where the command is available to view monitored cgroups and pressure-related state. A systemd-oomd event identifies a policy decision; a kernel OOM event identifies failure to satisfy an allocation after reclaim and accounting rules.
Recover a VPS that is already unresponsive
Recovery should free memory without adding another large workload.
- Open a second SSH session, serial console, or provider recovery console. The existing session may be stuck because new allocations cannot be satisfied.
- Stop or restart the identified noncritical service. Prefer the service manager, such as
systemctl stop <unit>, so child processes and restart behavior are handled consistently. - Do not launch memory-heavy diagnostics, package upgrades, compilers, or recursive log searches while the host is under pressure.
- Capture kernel and service logs before restarting if the console remains usable.
- If no process can be stopped and the provider console is the only access path, reboot as a last resort. Immediately after boot, run
journalctl -k -b -1and inspect the previous boot’s service logs.
A restart policy can restore availability, but it can also create a loop: the service starts, reaches the same peak, is killed, and starts again. Treat automatic restart as containment, not a memory fix.
Add swap for emergency headroom
Swap moves less-active pages to disk, reducing abrupt allocation failure and giving systemd-oomd time to react. It is substantially slower than RAM. Under sustained pressure, heavy swapping can make a VPS painfully slow and still end in an OOM kill.
When swap is appropriate
swapon --showis empty and measured peaks briefly exceed RAM.- Existing swap is present but consistently exhausted during known jobs.
- You need reaction time for systemd-oomd while you correct the workload.
- The filesystem has enough free space and acceptable durability for a swap file.
No universal swap-size ratio is established by the documented sources. Choose a size from measured peak usage, available disk, and the latency you can tolerate; do not treat a fixed “RAM times two” rule as a guarantee.
Create and test a swap file
Use your distribution’s documented procedure and substitute a path and size appropriate to the host. A common Linux sequence is:
- Confirm free space with
df -h. - Create a file of the required size using the distribution-supported method, for example
fallocate -l 2G /swapfile. If your filesystem does not support suitable allocated swap files, use its documented alternative. - Restrict access:
chmod 600 /swapfile. - Format it:
mkswap /swapfile. - Enable it:
swapon /swapfile. - Verify both views:
swapon --showandfree -h. - Only after the live test succeeds, add a matching
/swapfile none swap sw 0 0entry to/etc/fstab, then test the configuration during a planned maintenance window.
Monitor latency and swap-in/out after enabling it. Swap should absorb short peaks, not conceal a workload that remains above physical capacity for hours.
Rank #3
- OWC 64GB UPGRADE: Consists of 2pcs of 32GB DDR4 3200MHz PC4-25600 CL22 2RX8 ECC Unbuffered DIMM 1.2V 288-pin Memory Modules
- 100% COMPLIANT: With JEDEC Standard Specifications, ROHS Compliant, Warranty Safe Upgrade. Designed and Tested to Meet or Exceed all Manufacturer OEM Specs
- Compatible with Micron MTA18ADF4G72AZ-3G2B3 MTA18ASF4G72AZ-3G2B1 MTA18ASF4G72AZ-3G2F1Z MTA18ADF4G72AZ-3G2, Samsung M391A4G43BB1-CWE M391A4G43AB1-CWE, Hynix HMAA4GU7AJR8N-XN
- INDUSTRY LEADING: Consumer Friendly Advanced Replacement Program and Limited Lifetime Warranty, which Includes Free Tech Support by Other World Computing
- Works with Desktop, Workstation and Servers like: PowerEdge, Precision, StoreEasy, ProLiant, Apollo, ThinkServer, ThinkStation, ThinkSystem, System X and more
Fix the workload that exhausted memory
Use the OOM record’s process name and PID as the starting point, then compare its normal and peak behavior with your service configuration.
Web and application workers
Lower worker or thread counts when each worker has a substantial resident footprint. Measure one warm worker, multiply by the maximum concurrency, and leave room for the operating system, caches, logging, and other services. Apply changes through the application’s supported configuration and restart during a controlled window.
Recommended Free Tools
Databases
Database caches and connection pools are deliberate memory consumers. Reduce cache or buffer settings and connection concurrency only after checking query and latency impact. A database that is killed during imports may need a smaller import batch or a scheduled maintenance window rather than a permanently lower cache.
Builds, migrations, and scheduled jobs
Bound compiler parallelism, reduce build workers, and stagger jobs that currently overlap. Large migrations and imports should be tested at realistic data volume, with batch sizes that fit the VPS. A cron job that starts again before the previous run ends can create an unnoticed accumulation of processes.
Containers
Inspect container-level memory limits and usage. Set a limit that protects the host while leaving enough room for the application’s peak, and define an application-aware restart or failure policy. A container limit can trigger a cgroup kill even when host RAM appears available; conversely, unlimited containers can consume the entire VPS.
Memory leaks
If resident memory grows after each request, queue item, or scheduled cycle and does not return, capture application-level heap or allocation data and fix the leak. Restarting on a timer may reduce the blast radius temporarily, but it does not correct the retaining object, unbounded cache, or unreleased buffer.
Contain the blast radius with systemd and cgroups
Use a systemd drop-in rather than editing a vendor unit file. First measure normal and peak usage, then set a limit with enough headroom for legitimate bursts.
Set a tested memory ceiling
- Create a drop-in directory:
sudo systemctl edit <unit>. - Add a
[Service]section and a tested value such asMemoryMax=with the unit appropriate for your workload. - Save the drop-in, run
sudo systemctl daemon-reload, and restart the service during a controlled window. - Verify with
systemctl show <unit> -p MemoryMax -p MemoryCurrent. - Exercise the largest expected request or job and watch the service journal for cgroup termination.
Ubuntu’s resource-control documentation describes invoking an OOM killer inside the unit when memory cannot be contained under its limit. A limit that is too small creates a predictable restart loop, so lower it gradually rather than guessing.
Rank #4
- ECC REGISTERED UPGRADE: This type of memory is used in Workstations and Servers. It will NOT be compatible with standard desktop computers. Also, it cannot be mixed with UNBUFFERED memory.
- OWC 128GB UPGRADE: Consists of 8pcs of 16GB DDR4 3200MHz PC4-25600 CL22 2RX4 ECC Registered RDIMM 1.2V 288-pin Memory Modules
- 100% COMPLIANT: With JEDEC Standard Specifications, ROHS Compliant, Warranty Safe Upgrade. Designed and Tested to Meet or Exceed all Manufacturer OEM Specs
- MAXIMIZE YOUR SERVER: With OWC's ECC Registered Server Memory, Our RAM upgrades will extend the life of your old infrastructure or save money when building a new one
- INDUSTRY LEADING: Consumer Friendly Advanced Replacement Program and Limited Lifetime Warranty, which Includes Free Tech Support by Other World Computing
Choose managed OOM behavior deliberately
Where supported and appropriate, ManagedOOMSwap=kill or ManagedOOMMemoryPressure=kill can let systemd manage units under swap exhaustion or sustained memory pressure. Inspect the effective values with systemctl show, test the policy under load, and ensure the selected unit is less harmful to terminate than unrelated system services.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →| Remedy | Recovery speed | Kill or data-loss risk | Performance impact | Survives reboot | What it changes |
|---|---|---|---|---|---|
| Stop a noncritical service | Immediate | Possible in-flight request loss | Removes that service’s work | No | Frees demand temporarily |
| Add swap | Minutes to configure | Lower abrupt-failure risk, but workload may still be killed | Can cause severe latency under sustained pressure | Only with a tested /etc/fstab entry |
Adds disk-backed headroom |
| Reduce workers or cache | After a controlled restart | Usually low; capacity or throughput may fall | May increase queueing or database latency | Yes, if configuration is persistent | Reduces workload demand |
Set MemoryMax= |
After daemon reload and restart | Unit can be killed at the cap | Protects other services; may cause restarts | Yes, through the drop-in | Limits one cgroup’s blast radius |
| Resize the VPS | Provider-dependent | Migration or reboot risk | More RAM; recurring hosting cost | Yes | Adds physical capacity |
Change kernel memory settings only for a measured workload
Sysctl values alter allocation and reclaim policy; they do not manufacture RAM. Save current values with sysctl -a or by reading the relevant /proc/sys/vm/* files, change one setting at a time, and document the rollback value.
vm.overcommit_memory
0uses heuristic overcommit accounting.1always permits overcommit.2uses strict accounting. Its commit limit is calculated from RAM, swap, and either the overcommit ratio or configured kilobytes.
Strict accounting can make allocation failures occur earlier and more predictably; always-overcommit can defer failure until pages are actually needed. Select a mode because the workload requires it, not because an OOM message appeared once.
vm.swappiness
vm.swappiness influences how readily the kernel swaps pages. It is a workload-specific trade-off: less swapping can preserve latency for some services but leave less reclaimable headroom, while more swapping can avoid immediate kills at the cost of I/O latency. Change it only after observing swap activity and application performance.
vm.oom_kill_allocating_task and panic_on_oom
oom_kill_allocating_task changes victim-selection behavior. It does not reduce memory consumption. Do not set panic_on_oom=1 or 2 on an ordinary VPS: those values request kernel panic behavior intended for specialized failover arrangements and can turn a recoverable process kill into a full outage.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsPrevent the next OOM event
- Alert before swap is exhausted, not after the first service has been killed.
- Retain kernel and service logs across reboots so a previous-boot diagnosis is possible.
- Graph RSS, available RAM, swap-in/out, and cgroup memory pressure for each important service.
- Review scheduled jobs, deployment concurrency, queue batch sizes, and overlapping maintenance tasks.
- Test the largest expected request, import, build, and migration in a staging-sized environment.
- Encode known memory ceilings in systemd units or container configuration and alert before those ceilings are reached.
- Track restarts alongside memory graphs; repeated restarts often reveal a leak or an undersized limit.
Set alert thresholds from observed peaks and the time needed to stop work or resize the instance. A single VPS-wide percentage is less useful than a service-level alert tied to the process or cgroup that actually fails.
When resizing is the right fix
Resize or migrate when measured peak demand remains above physical RAM plus acceptable swap headroom after reducing concurrency, correcting leaks, and applying sensible service limits. Capacity expansion should follow diagnosis, not replace it: an oversized database cache, runaway worker count, or overlapping build can consume a larger VPS just as quickly.
Before changing plans, record peak RSS, swap usage, cgroup pressure, and the workload that produced them. A higher-memory plan is a hosting-provider decision; confirm the provider’s current size, pricing, migration behavior, and reboot requirements at the time you act.
Quick Recap
A practical decision sequence
- Identify the actor. Kernel log entries indicate the kernel OOM killer; systemd-oomd journal entries indicate a userspace policy decision; a unit’s cgroup status can reveal a local limit.
- Preserve evidence. Save current and previous-boot logs, process rankings, memory counters, and disk capacity.
- Recover safely. Stop the least critical identified consumer from a second session or provider console.
- Add temporary headroom. Enable tested swap when disk and latency constraints permit, then verify it.
- Reduce demand. Lower workers, caches, batch sizes, or build parallelism; fix leaks and overlapping jobs.
- Contain failures. Apply a measured systemd or container memory limit and test the resulting behavior.
- Tune only with evidence. Change overcommit, swappiness, or victim-selection settings one at a time and keep rollback values.
- Expand capacity. Resize when corrected, bounded demand still exceeds the VPS’s sustainable memory budget.
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.
