# My VPS is using too much memory. What's wrong?
Source: https://vpsdime.com/knowledgebase/troubleshooting/vps-using-too-much-memory
Last reviewed: 2026-07-04
Summary: It probably isn't. Linux deliberately uses idle RAM as disk cache and releases it on demand, so "used" memory looks high by design. How to read free -h correctly (the available column), what real memory pressure looks like, and what to do about it.

## 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](https://www.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](https://vpsdime.com/knowledgebase/client-area/services/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](https://vpsdime.com/knowledgebase/client-area/support/vps-troubleshooter)**, 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](https://vpsdime.com/knowledgebase/client-area/services/upgrade-downgrade), on Linux VPS it's live and instant with no downtime. And no, [adding swap](https://vpsdime.com/knowledgebase/technical-questions/swap-on-linux-vps) isn't the answer.

## Still need help?

You can [open a support ticket](https://vpsdime.com/open-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?"