High RAM usage: quick diagnostics

Quick answer: Check free -h first and read the available column — Linux using most RAM for cache is normal and healthy. A real problem shows as low available memory plus OOM-killer lines in dmesg. Find the top consumers with ps aux --sort=-%mem | head and restart the leaking service.

Overview

Half of all "RAM is full!" alarms are false: cached memory is reclaimable and a sign the kernel is doing its job. This checklist separates healthy caching from genuine memory pressure, which kills processes and freezes servers.

Before you start

• SSH or KVM Console access.

Step-by-step guide

1. Read the real headroom:

   free -h

   Worry only if available is a small fraction of total.
2. Check whether the kernel already killed something:

   sudo dmesg -T | grep -i 'out of memory'
   sudo journalctl -k | grep -i oom

   An OOM kill explains mysteriously dead services.
3. List the heaviest processes:

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

   Typical offenders: mysqld, php-fpm pools sized too large, node apps, control panels on small plans.
4. Stabilize: restart the leaking service; long-running PHP/node workers benefit from periodic recycling (e.g. PHP-FPM pm.max_requests).
5. Add safety margin: configure swap if you have none — it turns hard OOM crashes into graceful slowdowns.
6. Recurring pressure with everything tuned = the workload needs more RAM; upgrade the plan.

Common issues

• MySQL killed nightly: classic OOM pattern on small VPS during backups — lower buffer sizes or add swap.
• PHP-FPM pool too big: pm.max_children × memory per worker must fit in RAM.
• No swap at all: one traffic spike can OOM the database; even 1–2 GB of swap absorbs spikes.

When to contact support

If memory usage is far higher than the sum of your processes, or the server freezes with plenty of available memory shown, open a ticket with free -h, the OOM excerpts and timestamps.

Frequently asked questions

Linux shows almost no free memory — is that a problem?

Usually not: Linux deliberately uses idle RAM for disk cache and releases it on demand. Judge pressure by the available column in free -h and by OOM messages, not by the free column.

How do I confirm the OOM killer terminated my service?

Search kernel messages: dmesg -T | grep -i "out of memory" or journalctl -k. The kernel logs exactly which process it killed, when, and the memory state at that moment.

Related articles

• How to troubleshoot high RAM usage
• High CPU usage: quick diagnostics
• My VPS is not responding
• How to collect logs for support

Need a hand? Contact Cloud2Y support →