How to Fix High Memory Usage on a Linux Server

Linux server running out of memory? Learn how to diagnose and fix high memory usage with real commands — before it takes down your app.
Your app starts slowing down, the OOM killer fires, or your monitoring page turns red — and the culprit is memory. High memory usage on a Linux server is one of the most common production crises for small teams, and it's easy to misread. Linux intentionally uses most of your RAM for caching, so a server showing 95% memory used isn't necessarily in trouble. But one that's exhausting real working memory and swapping is. Here's how to tell the difference and actually fix it.

Step 1: Get a Clear Picture of What's Using Memory

Start with the basics. Run 'free -h' to see total, used, free, and available memory. Focus on the 'available' column — that's the real number. It accounts for reclaimable cache and is far more useful than 'free'.

• free -h — quick overview of RAM and swap usage
• vmstat 1 5 — five one-second snapshots; watch the 'si' and 'so' columns for swap-in and swap-out activity
• cat /proc/meminfo — full breakdown including Slab, PageTables, and AnonPages If swap is actively being used (si/so values above zero consistently), your server is genuinely memory-constrained. That's different from swap space existing but sitting idle.

Step 2: Find the Processes Eating Your RAM

Once you know memory is tight, you need to know what's consuming it. Run 'ps aux --sort=-%mem | head -20' to list the top 20 processes by memory percentage. For more detail on actual RSS (resident set size) in human-readable form:

ps -eo pid,ppid,cmd,%mem,rss --sort=-%mem | head -20
RSS is the memory a process actually holds in RAM — not virtual memory, which is often misleadingly large. Another useful tool is 'smem', which calculates PSS (proportional set size) and gives a fairer view when processes share memory libraries. Install it with 'apt install smem' or 'yum install smem', then run 'smem -r -k | head -20'.

Look for processes with unexpectedly high RSS. A Node.js app sitting at 2 GB when it should use 400 MB is a red flag. A MySQL instance using 4 GB is probably just doing its job.

Step 3: Diagnose the Root Cause
Not all memory problems are the same. Here are the most common causes and how to confirm each:

• Memory leak — process RSS grows continuously over hours or days; restart the process and watch it climb again. Use 'watch -n 5 ps -p -o rss=' to monitor a specific process.
• Misconfigured heap limits — Java apps, Node.js, or Elasticsearch configured with heap sizes too close to total available RAM. Check startup flags for -Xmx (Java) or --max-old-space-size (Node).
• Too many processes — dozens of PHP-FPM or Unicorn workers each holding memory; check your pool/worker count configuration against actual server RAM.
• Kernel slab cache — run 'slabtop' to see if kernel object caches (like dentries or inodes) are unusually large; this is common on servers handling millions of small files.

• Huge log or data buffers — apps buffering large amounts of data in memory before flushing to disk.

• Step 4: Free Memory and Reduce Pressure
  If you need to recover memory right now, here are safe options in order of preference:

• Restart the leaking or bloated process — this is usually the fastest path if you've identified a culprit.

• Drop page cache — 'echo 1 > /proc/sys/vm/drop_caches' releases cached file data Linux is holding speculatively. It's safe and the cache refills automatically. Use '2' to free dentries/inodes, '3' for both.

• Reduce worker counts — lower PHP-FPM pm.max_children, Unicorn workers, or similar settings to reflect your actual RAM budget.

• Increase swap temporarily — if you're on a VPS with no extra RAM, a swap file buys breathing room: 'fallocate -l 2G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile'. Add it to /etc/fstab to persist across reboots.

• Tune vm.swappiness — set it to 10 (echo 10 > /proc/sys/vm/swappiness) so the kernel prefers keeping processes in RAM over aggressively swapping.

Step 5: Prevent It From Happening Again

Fixing a memory spike once isn't enough. You need guardrails so the next one doesn't catch you off guard at 2 AM.

Set per-process memory limits using systemd's MemoryMax= in a service unit file, or use cgroups directly. This stops one bad process from starving everything else.

• Add alerting on available memory, not just used memory — alert when available drops below 15–20% of total RAM.
• Schedule regular restarts for known-leaky long-running processes using systemd timers or cron, as a pragmatic interim fix.
• Profile your app under realistic load before sizing your server — tools like Valgrind (C/C++), memory_profiler (Python), or clinic.js (Node.js) can catch leaks before production. If you're running multiple services and want to understand memory trends over time without manually SSHing in and running commands, this is exactly where Opservo helps — it continuously tracks per-process memory, surfaces anomalies in plain English, and can alert you before available memory hits a critical threshold.

Memory problems are almost always diagnosable if you know where to look. The key is distinguishing Linux's normal aggressive caching from genuine memory pressure, finding the process responsible, and either fixing the root cause or putting hard limits in place so one misbehaving service can't take down everything else.

Originally published on the Opservo blog — Opservo is the AI ops engineer for teams without an SRE. Free for 2 servers → https://getopservo.com/welcome