How to Check Linux Server RAM Health — Complete NOC

I still remember getting a 3AM alert — a client’s production server started killing MySQL processes one by one. The OOM killer was going wild. Panic? Absolutely. But what annoyed me more was realizing this had been building up for days. The RAM was “sick” for a long time, but nobody noticed because nobody was checking.

Think of it like your car — you can drive it every day without servicing, but when the oil turns black and the engine starts vibrating weirdly, it will eventually break down on the highway. Server RAM is exactly the same. It can run fine at first, but if you don’t check it regularly, small symptoms pile up until it becomes a massive problem that takes down all your services.

This article isn’t written for you if your server is currently crashing and you’re panicking — it’s written for you if you want to prevent that from happening. We’ll cover how to check Linux server RAM health from basic to advanced level, complete with the commands I actually use in the field as a NOC engineer.

Why RAM Health Matters More Than You Think

Before diving into commands, let’s talk about why this is critical. Healthy RAM means your server can handle requests without bottlenecking. Sick RAM — whether from memory leaks, faulty DIMMs, or overcommit — can slow everything down, including your website that suddenly takes 10 seconds to load when it used to take 2.

In the NOC world, we have a term: “silent killer.” A server with almost-full RAM that’s still running is like a person with a fever forcing themselves to work — they look fine, but they’re about to collapse. If you manage a VPS or dedicated server, understanding how to read RAM health status is mandatory, not optional.

Reading free -h Output Correctly

The first and most commonly used command is free -h. But here’s the problem — most people misread its output. They see “used” is high and immediately panic, which isn’t necessarily a problem.

$ free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       8.2Gi       1.1Gi       512Mi       5.8Gi       6.4Gi
Swap:          2.0Gi       128Mi       1.8Gi

This is output from a server handling a WordPress multisite. At first glance, “used” at 8.2GB out of 15GB total looks high. But don’t panic yet — look at the available column: 6.4GB. This means the system still has plenty of RAM available for new processes.

Here’s what you should focus on:

• available (not free) — this is the number that actually shows how much RAM can be used
• buff/cache — RAM used for caching. Linux aggressively uses RAM for file caching, but this cache can be released anytime a process needs memory
• Swap used — if this number is high (over 50% of total swap), it means RAM is insufficient and the system is using disk as backup RAM. Disk is much slower than RAM, so performance will definitely drop

The Difference Between free and available

Real-Time RAM Monitoring with top/htop

The free command only gives you a one-time snapshot. If you want to see RAM usage in real-time — like for debugging when server performance is dropping — use htop or top.

$ htop

In htop, you’ll see the RAM bar at the top. Here’s what to look for:

• Green = RAM used by processes
• Blue = RAM used for buffers/cache
• Yellow/Orange = RAM used by the kernel

If you don’t have htop installed (common on minimal servers), use the built-in top:

$ top

In the top lines of the top output, look for the Mem line — that’s where you’ll see total, used, free, and buffers/cache. Sort processes by memory usage by pressing M (uppercase) on your keyboard.

Identifying the Most Memory-Hungry Processes

Often the problem isn’t total RAM — it’s one greedy process hogging memory all by itself. This is what I call a “cancer process” — quietly consuming resources until the server dies.

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

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql     1234  12.3 28.5 1843200 4567892 ?     Sl   Jul20  120:45 /usr/sbin/mysqld
nginx     5678   2.1  8.2  245760 1310720 ?     S    Jul20   15:23 nginx: worker
www-data  9012   1.8  6.5  524288 1048576 ?      S    Jul20   12:11 php-fpm: pool
root      3456   0.5  3.2  204800  524288 ?      Ss   Jul20    8:45 /usr/bin/node

In this example, MySQL is using 28.5% of total RAM — that’s normal for a database server handling many queries. But if you see a process that shouldn’t be using that much (like php-fpm at 40%), that’s already a sign of a problem, possibly a memory leak.

Understanding Memory Mapping with smem

The ps command shows RSS (Resident Set Size), but RSS numbers can be misleading because they include shared memory that other processes also use. For a more accurate picture, use smem:

$ sudo apt install smem
$ smem -t -k -s pss

  PID User     Command                         Swap      USS      PSS      RSS
 1234 mysql    /usr/sbin/mysqld                  0B    4.1G    4.1G    4.3G
 5678 nginx    nginx: worker process             0B    1.2G    1.2G    1.3G
 9012 www-data php-fpm: pool www                 0B  980.5M  985.2M    1.0G

PSS (Proportional Set Size) is the most accurate number for showing how much RAM a process truly uses, with shared memory proportionally divided. If you want to know who’s really the greediest, look at PSS, not RSS.

Verifying Physical RAM Health with dmidecode

The commands above show RAM usage by software. But what if the problem is in the hardware? Faulty RAM DIMMs can cause errors that are extremely difficult to trace because symptoms appear intermittently.

$ sudo dmidecode -t memory | grep -A 17 "Memory Device"

Memory Device
	Size: 8192 MB
	Form Factor: DIMM
	Speed: 3200 MT/s
	Manufacturer: Samsung
	Serial Number: ABCD1234
	Part Number: M391A1G43AB1-CWE
	Rank: 2
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits

Notice the line Error Information Handle: Not Provided. If there’s an error on a physical DIMM, this is usually where it’s recorded. Additionally, check edac-utils for error correction reporting:

$ sudo apt install edac-utils
$ edac-util -s
edac-util: EDAC driver is not loaded.

$ sudo modprobe edac_mce_amd  # for AMD
$ sudo modprobe amd64_edac     # for AMD alternative
$ sudo modprobe intel_edac     # for Intel
$ edac-util -s

Checking Swap and Overcommit Settings

Sometimes a server feels slow not because RAM is full, but because of overcommit. Linux has an overcommit feature — it allows memory allocation beyond what’s physically available, assuming not all allocations will be used simultaneously. Sometimes that assumption is wrong.

$ cat /proc/sys/vm/overcommit_memory
0

$ cat /proc/sys/vm/overcommit_ratio
50

This means the overcommit mode is heuristic (0) and the ratio is 50%. For production servers, I usually recommend:

$ sudo sysctl -w vm.overcommit_memory=2
$ sudo sysctl -w vm.overcommit_ratio=80

# For permanent change:
echo "vm.overcommit_memory = 2" | sudo tee -a /etc/sysctl.conf
echo "vm.overcommit_ratio = 80" | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p

Detecting Memory Leaks the Practical Way

A memory leak is like a faucet that won’t close — drop by drop, eventually it runs dry. To detect it, you need to monitor RAM usage over time, not just once.

# Install sar if not already installed
$ sudo apt install sysstat

# Enable sar
$ sudo systemctl enable sysstat
$ sudo systemctl start sysstat

# Check memory usage per hour (today)
$ sar -r -f /var/log/sysstat/sa$(date +%d)

12:00:01 AM  kbmemfree kbmemused  %memused kbbuffers  kbcached  kbswpfree kbswpused  %swpused
12:10:01 AM    1126400  14233600     92.68   1048576   6094848    1920000     128000      6.25
12:20:01 AM    1098000  14262000     92.86   1048576   6123520    1915000     133000      6.49
12:30:01 AM    1075200  14284800     93.01   1048576   6147200    1910000     138000      6.74
12:40:01 AM    1052800  14307200     93.16   1048576   6170880    1905000     143000      6.98
12:50:01 AM    1030400  14329600     93.31   1048576   6194560    1900000     148000      7.23

Notice the pattern — kbmemfree keeps dropping hour by hour? That’s a strong indicator of a memory leak. In this example, free memory drops about 24MB every 10 minutes. If left unchecked, the server will start heavy swapping within hours and performance will tank.

Checking RAM Errors in System Logs

RAM hardware errors are usually recorded in the kernel log. You can check with:

$ sudo dmesg | grep -i -E "memory|ram|mce|edac|ecc"

[    0.000000] Memory: 16106120K/16777216K available (8192K kernel code, 1234K rw-data, 3456K ro-data, 2048K init, 1234K bss, 670096K reserved, 670096K cma-reserved)
[    0.123456] MCE: Memory controller reporting 1 error
[    2.345678] EDAC MC0: 1 CE error, label: DIMM_A1, row: 0, grain: 1
[    5.678901] MCE: Hardware Error: CPU 0, Bank 5: 8a00000000401151
[   10.234567] EDAC MC0: 1 UE error, label: DIMM_B2, row: 1, grain: 1

Explanation of the logs above:

• CE (Correctable Error) — An error that ECC can fix automatically. A few CEs are tolerable, but if the frequency is high, the DIMM is starting to fail
• UE (Uncorrectable Error) — An error that CANNOT be fixed. This is dangerous — it can cause data corruption or kernel panic. If you see UE, replace the DIMM immediately
• MCE (Machine Check Exception) — Hardware error reporting from the CPU. Could be RAM, could also be CPU or motherboard

Stress Testing Your RAM

Want to know the maximum threshold of your server’s RAM before it starts having issues? Run a stress test. But be careful — don’t do this on a production server handling normal traffic.

# Install stress
$ sudo apt install stress

# Stress test using 80% of RAM for 5 minutes
$ stress --vm 2 --vm-bytes 80% --vm-keep --timeout 300s

# Or more accurately with memtester
$ sudo apt install memtester
$ sudo memtester 4G 1

memtester version 4.6.5 (64-bit)
Copyright (c) 2010-2022 by Charles Cazabon.

Looping 1 time through 4G of memory.

Stuck Address       : ok
	Random Value      : ok
	Compare XOR        : ok
	Compare SUB        : ok
	Compare MUL        : ok
	Compare DIV        : ok
	Logical OR         : ok
	Logical AND        : ok
	Block Compare      : ok
	Checkerboard       : ok
	Bit Spread         : ok
	Bit Flip           : ok
	Walking Ones       : ok
	Walking Zeroes     : ok
	8-bit Writes       : ok
	16-bit Writes      : ok

Automated RAM Monitoring Script

As a NOC engineer, I can’t be logged into servers 24/7 to manually check RAM. What I do instead is create a simple script that sends alerts when RAM reaches a certain threshold.

#!/bin/bash
# ram-monitor.sh — Save to /usr/local/bin/

THRESHOLD=85
HOSTNAME=$(hostname)
DATE=$(date '+%Y-%m-%d %H:%M:%S')

# Get used RAM percentage (excluding cache)
RAM_USED=$(free | awk '/Mem:/ {printf "%.0f", ($3-$7)/$2 * 100}')

if [ "$RAM_USED" -gt "$THRESHOLD" ]; then
    TOP_PROCS=$(ps aux --sort=-%mem | head -5 | awk '{printf "%s (%s%%)n", $11, $4}')
    
    echo -e "Subject: [WARNING] RAM Usage on $HOSTNAME is ${RAM_USED}%nn"
echo -e "RAM Usage: ${RAM_USED}%nTop processes:n${TOP_PROCS}nn"
echo -e "Timestamp: $DATE" | mail -s "[WARNING] RAM Alert: $HOSTNAME" admin@syslogsolutions.net
fi

Run this script every 5 minutes with cron:

# Open crontab
$ crontab -e

# Add this line:
*/5 * * * * /usr/local/bin/ram-monitor.sh

Related Issues

• How to Check Linux Server CPU Health
• Fixing Disk Full on VPS
• Understanding Linux OOM Killer
• Linux Server Monitoring Guide for NOC
• Linux Server Performance Optimization

Conclusion

Checking Linux server RAM health isn’t complicated — the hard part is being disciplined enough to do it regularly. The commands we covered above are actually very easy to run, and you can even set up an automated script so you don’t have to check manually.

The most important takeaway: don’t only check when there’s a problem. Make it a routine, just like servicing your car before it breaks down, not after. If you’re managing more than one server, consider using monitoring tools like Grafana + Prometheus or Netdata that can give you automated alerts.