If your VPS feels sluggish, applications are crashing unexpectedly, or your monitoring dashboard keeps flashing memory warnings, you’re likely dealing with high memory usage. This guide walks through a clear troubleshooting workflow: check memory pressure, identify the process responsible, determine the cause, apply the right fix, and verify it actually worked.
Is High Memory Usage Always a Problem?
Not necessarily. Linux intentionally uses available RAM for disk caching to speed up file access, so seeing 90% memory “used” doesn’t automatically mean something is wrong. That cached memory is released instantly the moment an application needs it.
The more meaningful indicators are:
- Available memory – how much RAM can actually be reclaimed for new processes
- Swap activity – frequent, sustained swapping usually signals real pressure
- Application behavior – slow responses, timeouts, or crashes
- OOM events – processes being terminated because the system couldn’t satisfy a memory request
If these signs are present, you have genuine memory pressure worth fixing. If not, high usage alone may simply reflect healthy caching.
Step 1: Check Actual Memory Pressure
Start with:
free -h
Look at the available column rather than used. Also check swap: if swap usage is high and climbing, that’s a stronger signal of pressure than the raw RAM percentage.
Step 2: Find the Process Using the Most Memory
ps aux –sort=-%mem | head -20
or, for a live view:
top
htop
This narrows the problem down to a specific process rather than “the server is slow.”
Step 3: Identify the Cause
Once you know which process is involved, match it against common patterns:
|
Process seen |
Likely cause |
|
php-fpm |
PHP workers handling application traffic |
|
mysqld / mariadbd |
Database workload or configuration |
|
node |
Node.js application |
|
python |
Python application or script |
|
apache2 / nginx |
Web server worker processes |
|
dockerd / containers |
Container workload |
It also matters whether the spike is temporary or persistent:
- Temporary — often caused by a traffic spike, a backup job, a database import/export, a cron task, or a deployment. Usually resolves on its own.
- Persistent — often points to excessive worker processes, a memory leak, an unnecessary service left running, poor database configuration, or genuinely insufficient RAM for the workload.
This distinction matters because it prevents unnecessary upgrades: a one-off spike from a backup job doesn’t mean you need more RAM.
How to Fix High Memory Usage
PHP-FPM Consuming Excessive Memory
PHP-FPM creates multiple worker processes, and each one consumes memory independently. A high worker limit can cause RAM usage to climb quickly during concurrent traffic. Rather than setting pm.max_children to an arbitrary number, measure typical per-worker memory usage first, then size the limit to what your available RAM can actually support.
Database Memory Configuration
For MySQL/MariaDB, check whether innodb_buffer_pool_size is set appropriately for your VPS’s total RAM rather than left at a generic default, which can overcommit memory on smaller plans.
Caching Tools Without Limits
Redis and Memcached are useful but can grow unchecked without a configured limit:
maxmemory 256mb
maxmemory-policy allkeys-lru
Unnecessary Services and Processes
Review what’s actually running with systemctl list-units –type=service and disable anything non-essential, including duplicate application instances or forgotten background jobs.
Suspected Memory Leaks
If a process’s memory usage keeps climbing even while the workload stays roughly the same, that’s the signature of a memory leak or another resource-management issue. Confirm it by monitoring the process over time and comparing memory growth against actual traffic or workload — steady growth with flat workload is the key signal. Check application logs and recent deployments or config changes, since leaks often appear right after an update.
Restarting a Service
Restarting a problematic service is a legitimate short-term step, but treat it as a symptom clearer, not a fix. If memory returns to normal after a restart but climbs again over hours or days, the underlying cause — usually a leak — hasn’t actually been addressed and still needs investigation.
Swap Space
Swap gives the system headroom so processes aren’t killed outright during brief memory spikes, but it isn’t a substitute for sufficient RAM and shouldn’t be relied on as a long-term fix. For setup instructions, see our dedicated guide on how to [Configure Swap Memory].
Containerized Workloads
If your VPS runs Docker or other containers, also check container-level memory limits. A container can hit its own configured limit and start failing even while the host still has RAM available.
When Memory Exhaustion Gets Severe
If memory pressure becomes severe enough, Linux may invoke the OOM killer and terminate one or more processes to protect system stability. If you’re seeing processes disappear unexpectedly, check dmesg | grep -i “out of memory” to confirm, and see our dedicated OOM Killer guide for how Linux selects processes and how to investigate an OOM event in detail.
Verifying the Fix
Don’t assume a fix worked immediately — monitor for 24–48 hours and re-check:
free -h
Confirm that:
- Available memory stays consistently healthy, not just briefly after a restart
- No new OOM events appear in system logs
- Application response times return to normal
If usage climbs steadily again over that window rather than staying stable, you’re likely still dealing with an unresolved leak or misconfiguration. For ongoing visibility so you catch the next spike early, our VPS Monitoring Guide covers setting up automated alerts.
When Should You Increase VPS RAM?
Consider upgrading when:
- Memory stays consistently constrained even after optimization
- Workload or traffic has genuinely grown over time
- Application concurrency can’t reasonably be reduced further
- You’ve already reviewed worker limits and database configuration
Hold off on upgrading when:
- One specific process is consuming an abnormal share of RAM
- A memory leak is suspected but not yet confirmed or fixed
- An unnecessary service is still running in the background
- The spike was tied to a one-off event like a backup or deployment
Upgrading is a legitimate fix when the workload has outgrown the plan — but it should follow diagnosis, not replace it.
Preventing High Memory Usage
- Set up monitoring and alerts so rising usage is caught before it becomes critical
- Re-check application and database configuration after any significant traffic increase
- Schedule periodic restarts only as a stopgap for known, unfixed leaks — not as routine maintenance
- Reassess VPS plan sizing periodically as your site or application grows
Conclusion
High memory usage on a VPS is almost always traceable to a specific, identifiable cause — a misconfigured service, a memory leak, an unnecessary process, or a workload that has outgrown the current plan. Working through a clear sequence — check memory pressure, identify the process, determine whether it’s temporary or persistent, apply the right fix, and verify — turns a stressful troubleshooting session into a repeatable process. Keeping memory usage healthy is core to overall VPS performance, and it’s worth solving properly rather than papering over with a quick restart.
Frequently Asked Questions
Most often it’s a misconfigured service, an unmonitored caching tool, too many background processes, or a memory leak in an application. Genuine traffic growth can also be the cause.
Run ps aux –sort=-%mem | head -20 or use top/htop for a live view. This shows exactly which process to investigate first.
It can be. Linux uses spare RAM for disk caching, which shows up as “used” memory but is released instantly when needed. Available memory and swap activity are better indicators of a real problem.
Yes. Each PHP-FPM worker consumes memory independently, so a high worker limit combined with concurrent traffic can drive RAM usage up quickly. Measure per-worker usage before adjusting limits.
After you’ve diagnosed the cause and ruled out leaks, unnecessary services, and misconfiguration — if usage still stays consistently high, an upgrade is the appropriate next step.