VPS out of RAM: causes, diagnosis and fixes

When your VPS runs out of RAM, the Linux kernel activates the OOM Killer (Out-Of-Memory Killer) and starts terminating processes to free memory, which can take down your site or application without any warning. The first step is always to identify which process is consuming the memory before taking any action.

Symptoms of RAM exhaustion on a Linux VPS

Memory exhaustion does not always cause an immediate crash. The most common symptoms are:

The server becomes very slow or stops responding entirely.
The website returns 500 or 503 errors.
Apache/Nginx logs show messages like "worker_connections are not enough".
/var/log/syslog or /var/log/messages records Out of memory: Kill process entries.
Running free -h shows available memory near zero.

Confirming the problem takes less than a minute with the right commands.

Step-by-step diagnosis

Check current memory usage

free -h

The available column (not just free) is what matters: it shows how much memory the system can hand to new applications without touching swap. If it is below 10% of your total RAM, you are in the danger zone.

Identify the top memory consumers

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

This lists the 20 highest memory-consuming processes. The %MEM column shows the percentage of total RAM, while VSZ/RSS show virtual and real usage respectively.

For a live, auto-refreshing view:

top -o %MEM

Press M inside top to sort by memory usage.

Check the OOM Killer in the logs

grep -i "out of memory\|oom_kill" /var/log/syslog | tail -30

If the OOM Killer has already acted, you will see which process was terminated and how much memory it had. This reveals the history of the problem, not just the current state.

Check swap

swapon --show

If there is no output, you have no swap configured. If it appears but is at 100%, the system has been using disk as a RAM substitute for a while, which slows everything down dramatically.

Most common causes of VPS RAM exhaustion

Cause	Characteristic sign	Quick fix
PHP-FPM with too many workers	Dozens of `php-fpm` processes in `ps aux`	Lower `pm.max_children` in the pool config
MySQL/MariaDB with large buffers	`mysqld` alone consumes 40-60% of RAM	Tune `innodb_buffer_pool_size`
Memory leak in application	One process grows over time until RAM is gone	Restart the process; review the code
Unexpected traffic spike	RAM was normal until that moment	Page cache (Varnish, OPcache, Redis)
Undersized VPS plan	RAM constantly at 90%+ even at rest	Upgrade the VPS plan

Solutions to recover from and prevent RAM exhaustion

1. Free memory immediately (emergency measure)

If the server is still responding and you need to buy time without rebooting, you can flush the kernel page cache (safe — it refills automatically):

sync && echo 3 > /proc/sys/vm/drop_caches

You can also restart only the offending service instead of the entire server:

systemctl restart php-fpm
systemctl restart mysql

2. Configure or expand swap

Swap acts as a pressure-relief valve. It does not replace RAM, but it prevents the OOM Killer from terminating processes during the first traffic spike. To create a 2 GB swap file:

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Also tune swappiness so the kernel prefers RAM over swap:

echo 'vm.swappiness=10' >> /etc/sysctl.conf
sysctl -p

3. Optimize PHP-FPM

PHP-FPM in dynamic mode can spawn many concurrent workers. A conservative formula for pm.max_children:

RAM available for PHP ÷ Average memory per PHP process

If you have 1 GB for PHP and each process uses ~50 MB, the limit is 20 workers. Edit /etc/php-fpm.d/www.conf:

pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10

4. Tune MariaDB/MySQL buffers

The most impactful parameter is innodb_buffer_pool_size. For a 2 GB VPS where the database is not the only service, a safe value is 256-512 MB:

[mysqld]
innodb_buffer_pool_size = 256M
query_cache_size = 0
query_cache_type = 0

5. Enable OPcache for PHP

OPcache stores compiled PHP bytecode in shared memory, reducing CPU time and the number of active workers needed concurrently:

opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000

If the VPS is still hitting its limit after optimization, the current plan is likely insufficient for the actual load. Check out the VPS server options to find a plan with more resources that fits your project.

Proactive monitoring to avoid surprises

The best solution is to detect the problem before it causes downtime:

Install Netdata or Munin for historical RAM and swap graphs.
Set up an email alert when available RAM drops below 15%.
Review the OOM Killer log weekly: if it appears, you have a recurring problem to address.

For mission-critical projects that cannot afford downtime, consider a managed VPS with expert support at elenlace.com, where the technical team monitors resources and intervenes before problems reach your users.

Key takeaways

Use free -h and ps aux --sort=-%mem as your first diagnostic step.
Check OOM Killer logs to understand the problem history, not just the current state.
Swap does not replace RAM, but it prevents abrupt crashes during traffic spikes.
PHP-FPM and MySQL are the biggest RAM consumers on most PHP/WordPress VPS setups.
OPcache and PHP-FPM worker limits offer the best effort-to-impact ratio.
If the VPS remains at its limit after tuning, it is time to upgrade the plan.

FAQ

Is it safe to run drop_caches on a production server?

Yes, it is safe. The kernel only clears page caches, dentries, and inodes that it does not need to keep hot immediately. Active process data is not touched. The only side effect is slightly slower disk operations for a few minutes while the kernel warms up the cache again.

How much swap should I create on my VPS?

A practical rule: if you have 1-2 GB of RAM, create 2 GB of swap. If you have 4-8 GB of RAM, 4 GB of swap is usually enough. On production VPS servers, do not rely on swap as a permanent solution — use it as a safety net.

Can a WordPress plugin exhaust server RAM?

Yes. Plugins with background operations (backups, SEO indexing, misconfigured caching) can spawn PHP processes that accumulate. Deactivate plugins one by one under load and monitor ps aux to identify the culprit.

Can RAM exhaustion damage the database?

If the OOM Killer abruptly terminates the MySQL process, it can leave the InnoDB engine in an inconsistent state. On restart, InnoDB automatically runs crash recovery, but in extreme cases a table can become corrupted. This is why regular backups are essential — make sure you have a solid backup strategy in place for your VPS.

Prefer it done for you? El Enlace handles hosting and professional web development.

Compare providers

Other providers and guides worth comparing: