My VPS is using too much memory. What's wrong?

What this is#

Your monitoring, htop, or free shows memory nearly full and it looks alarming. In most cases nothing is wrong: Linux deliberately uses RAM that would otherwise sit idle as disk cache, because cached reads are enormously faster than disk reads. The moment your applications need that memory, Linux hands it back. Full-looking RAM is Linux doing its job well, the classic explainer is linuxatemyram.com.

How to read the numbers#

Run free -h and look at the available column, not "used" or "free":

• available is what your applications can actually claim right now (free memory plus reclaimable cache). If it's comfortable, you have no memory problem, whatever "used" says.
• Your control panel's memory graph reads your VPS the same way, so the Graphs tab reflects real usage accurately.

cgroup counters count cache as used#

There's a second family of memory numbers that inflates the same way for a different reason: cgroups (control groups) counters. The cgroup v2 memory.current value (and v1's memory.usage_in_bytes) is the kernel's total charge for the group, and it includes the page cache, not just what your applications allocated. Anything that reports from these counters inherits that behavior:

• docker stats and container dashboards,
• systemctl status <service> / systemd's MemoryCurrent,
• anything reading memory.current from /sys/fs/cgroup/... directly.

So a service or container can show hundreds of MB "used" when its processes hold a fraction of that, the rest is cache for the files it touched, reclaimable like any other cache. To see the split, read the group's memory.stat and compare anon (real application memory) with file (cache). And since a Linux VPS is itself a container, a tool that reads the VPS's own cgroup counter directly will show cache as used for the whole VPS, free -h's available remains the number that tells the truth about pressure.

What real memory pressure looks like#

• available in free -h staying near zero during normal operation.
• Processes being killed by the OOM killer. Platform note: on Linux VPS these kills are not visible inside your VPS, they won't appear in your own logs or dmesg; run My VPS is Down, which reports recent OOM kills for your VPS. On Premium VPS (full KVM), dmesg | grep -i "out of memory" shows them as usual. (Our Linux VPS run without swap, memory is fully dedicated, so when RAM is truly exhausted the kernel kills the biggest consumer rather than grinding into slow disk-swap.)
• Services (databases especially) restarting or dying under load for no visible reason.

If you genuinely need more#

First check what's eating it (ps aux --sort=-%mem | head), a leaking app or an oversized database buffer setting is cheaper to fix than more RAM. If the workload has simply outgrown the plan, upgrade, on Linux VPS it's live and instant with no downtime. And no, adding swap isn't the answer.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP,
• the output of free -h,
• whether anything is actually misbehaving (kills, restarts, slowness) or the number just looks high.

Related questions#

• "Why does my VPS show almost all memory used?"
• "Is high memory usage on Linux a problem?"
• "How do I read free -h properly?"
• "How do I know if I really need more RAM?"
• "What is the OOM killer and why did it kill my process?"
• "Why does docker stats show so much memory used?"
• "Why is memory.current higher than what my processes use?"
• "Why does systemctl status show a huge memory number for my service?"