知識庫

When a Linux server runs out of available RAM, the kernel's OOM (Out of Memory) killer forcibly terminates processes to keep the system running — often killing exactly the application you needed. This guide covers diagnosing and preventing OOM events.

Step 1 — Confirm an OOM Kill Actually Occurred

sudo dmesg | grep -i "out of memory"

Or check the kernel log:

sudo journalctl -k | grep -i "killed process"

This confirms both that OOM occurred and exactly which process was terminated.

Step 2 — Check Current Memory Usage

free -h

Note the available column specifically — low available memory combined with active swap usage is a strong warning sign before the next OOM event.

Step 3 — Identify the Top Memory Consumers

ps aux --sort=-%mem | head -10

Common Causes

A Memory Leak in an Application

If a specific process's memory usage grows continuously over time without stabilizing, that's a memory leak — check for application updates addressing known leaks, or restart the service on a schedule as a temporary mitigation while investigating.

Database Buffer Pool Set Too Large

If MySQL/MariaDB's innodb_buffer_pool_size is set close to or exceeding available RAM, it can starve the rest of the system — see How to Tune MySQL/MariaDB Performance for a VPS.

Too Many Services Running on an Undersized VPS

Running a web server, database, and multiple application processes together on a 1–2 GB VPS is a common cause of chronic memory pressure — see How to Choose the Right VPS Plan for Your Workload.

No Swap Configured as a Safety Buffer

free -h

If Swap shows 0, see How to Enable and Configure Swap on a Linux VPS — swap won't prevent OOM under sustained pressure, but provides a buffer against short-lived spikes.

Step 4 — Immediate Mitigation

Restart the killed service:

sudo systemctl restart your-service

If the same process keeps getting killed repeatedly, address the underlying memory usage before simply restarting again.

Step 5 — Set Memory Limits to Protect Critical Services

For Docker containers:

services:
  web:
    deploy:
      resources:
        limits:
          memory: 512M

For systemd services:

[Service]
MemoryMax=512M

This prevents one runaway service from consuming all system memory and triggering an OOM kill of unrelated processes.

Step 6 — Adjust OOM Killer Priority (Advanced)

You can make the kernel less likely to kill a specific critical process:

echo -500 | sudo tee /proc/PID/oom_score_adj

Use cautiously — this only shifts risk toward other processes, it doesn't solve an underlying memory shortage.

Long-Term Solutions

• Upgrade to a VPS plan with more RAM if consistently near capacity
• Fix identified memory leaks at the application level
• Add swap as a buffer against short spikes
• Set per-service memory limits to contain any single runaway process

Common Errors

Same process gets OOM-killed repeatedly — a genuine memory leak or undersized VPS for the workload; restarting alone won't fix the root cause.

Related Articles

• How to Enable and Configure Swap on a Linux VPS
• How to Check VPS Resource Usage (CPU, RAM & Disk)
• How to Tune MySQL/MariaDB Performance for a VPS