Linux Server Memory Usage Troubleshooting: Find Swap and OOM Problems

Linux server memory usage troubleshooting starts with evidence, not a guess that the server needs more RAM. Linux uses available memory for applications and file caches, so a high percentage can look alarming even when the system remains healthy. The useful question is whether applications lack memory, swap activity is slowing work, or a single process is consuming resources unexpectedly.

This guide shows a safe sequence for inspecting RAM, swap, caches, processes, and kernel messages. It also explains when configuration changes may help and when a hardware upgrade deserves consideration.

What Linux memory numbers actually mean

Linux divides physical RAM among running programs, the kernel, buffers, and caches. A cache holds recently used file data so the system can serve it quickly. The kernel can usually reclaim much of that cache when an application needs memory.

For that reason, the used number in a basic monitoring panel does not tell the whole story. Focus on available memory instead. This value estimates how much RAM applications can use without immediately forcing heavy swap activity. This distinction is central to Linux server memory usage troubleshooting.

• Total: Physical memory visible to the operating system.
• Used: Memory assigned to programs, the kernel, and some reclaimable areas.
• Free: Completely unused memory, which Linux often keeps relatively low.
• Buffers and cache: Memory used to speed file and block-device access.
• Available: A practical estimate of memory still available to applications.

Start with a read-only overview:

free -h

The -h option displays easier-to-read units. Record the output during the reported problem, then compare it with a normal period. One snapshot can miss a short memory spike.

Inspect RAM, cache, and swap together

The free command provides a useful first view, but it does not show how memory changes over time. Run it repeatedly when the issue is active:

free -h -s 2

This refreshes every two seconds. Press Ctrl+C to stop it. Watch whether available memory falls steadily, whether swap usage grows, and whether values recover after a workload finishes.

Swap is disk space that Linux can use as an extension of RAM. It can prevent an immediate crash during a short shortage. However, disk access is much slower than RAM when the system repeatedly moves active pages between memory and swap.

Check swap devices and current use with:

swapon --show
free -h

Look for swap that is configured but absent, a full swap device, or continually increasing use. Swap use alone does not prove a problem. A server may retain inactive pages in swap while applications still have adequate available memory.

More useful evidence is ongoing swap activity. If available, use:

vmstat 2

In the output, si represents memory brought in from swap, and so represents memory written to swap. Sustained nonzero activity during slow periods deserves investigation. Occasional values during startup or a brief workload may be normal.

Find processes consuming memory

After checking system totals, identify which processes account for demand. The interactive top utility is available on many Linux installations:

top

Press M to sort by memory use. Review %MEM and RES. Resident memory is the portion currently held in physical RAM, although shared libraries and shared memory require careful interpretation.

Many systems also provide htop, which presents similar information more visually. It may not be installed, and installing packages during an incident should follow your change process.

For a one-time process list, use:

ps aux --sort=-%mem | head -n 15

Do not terminate the largest process simply because it appears at the top. A database, web server, backup job, or application worker may legitimately need memory. First identify the service, confirm its normal range, and check its logs. A careful comparison makes Linux server memory usage troubleshooting safer than acting on a single process list.

Separate a leak from a busy workload

A memory leak occurs when a program keeps allocating memory without releasing it properly. A large, legitimate workload can create a similar symptom briefly. Compare process memory over several samples rather than relying on one ranking.

watch -n 5 'ps -p PID -o pid,ppid,cmd,%mem,rss,vsz'

Replace PID with the actual process identifier. RSS shows resident memory, while VSZ describes virtual address space. Virtual size is not the same as RAM consumption, so do not use it alone.

Also check whether several worker processes share the load. A service may have a reasonable individual footprint but exceed available RAM when its worker count rises.

Read kernel messages for out-of-memory events

When Linux cannot satisfy memory allocations, the kernel may invoke the out-of-memory, or OOM, killer. It selects a process to terminate so the system can continue operating. The selected process is not necessarily the original cause, so kernel messages matter.

dmesg -T | grep -i -E 'out of memory|oom|killed process'

On systems that restrict access to dmesg, review the system journal:

journalctl -k --since "2 hours ago" | grep -i -E 'out of memory|oom|killed process'

Adjust the time range to match the incident. Look for the timestamp, killed process, memory state, and related service messages. A killed database or web worker can explain an outage, but it does not prove that the service caused the pressure.

Containerized workloads add another layer. A container can hit its memory limit while the host still has free RAM. Inspect the container runtime and configured limits. Host-only review can miss the reason for termination.

Kernel logs are evidence, not a complete diagnosis. For a broader evidence-first method, compare this process with the Google SRE troubleshooting guidance.

Check service limits and workload changes

Memory pressure often follows a change rather than a permanent hardware shortage. Review recent deployments, configuration edits, traffic increases, backup jobs, imports, and scheduled tasks. A new worker count or cache setting can alter demand without changing server size.

Identify the service behind a process, then inspect status and recent logs:

systemctl status service-name --no-pager
journalctl -u service-name --since "2 hours ago"

Replace service-name with the actual unit. The systemctl manual documents the options. Avoid copying restart or stop commands into production until you understand dependencies and the recovery plan.

Some services impose memory limits through runtime settings, database caches, web worker limits, or systemd controls. Check documentation and existing configuration before lowering a value. An overly small cache or worker pool can create a different performance problem.

Decide whether swap or more RAM is appropriate

• High cache with healthy available memory: Usually normal.
• Low available memory with little swap activity: The workload may approach its practical limit.
• Low available memory with sustained swap activity: Pressure is affecting performance.
• OOM messages and killed processes: A system or workload reached a hard limit.
• One process grows continuously: Investigate its configuration, workload, and possible leak.
• Many workers grow together: Review concurrency, traffic, queues, and per-worker memory.

Adding swap can provide emergency headroom, but it does not create RAM-level performance. Before creating or resizing swap, verify storage layout, encryption, provider limits, backup expectations, permissions, and persistent configuration.

More RAM may be appropriate when demand remains high during normal workloads, service limits are reasonable, swap activity stays sustained, or OOM events recur after the cause is understood. Use representative busy-period measurements, not one alert. That evidence-based decision is the goal of Linux server memory usage troubleshooting.

Safe checks before changing configuration

Memory changes can affect uptime. Preserve evidence before restarting services, clearing caches, changing worker limits, or modifying swap. Save command output with timestamps and note what users experienced.

1. Confirm the server, time zone, and incident window.
2. Record free -h, swapon --show, and several vmstat samples.
3. Capture top memory-consuming processes.
4. Review kernel messages and affected service logs.
5. Compare settings with the last known-good configuration.
6. Change one controlled variable at a time.
7. Watch memory, swap activity, errors, and user impact afterward.

Do not clear caches as a routine fix. Cache clearing can make numbers look better temporarily while increasing disk reads and hiding the workload. Likewise, do not disable swap without understanding why it exists and whether the server can tolerate allocation failure.

When to request help with Linux memory issues

Linux server memory usage troubleshooting is manageable when you can collect repeatable evidence and make controlled changes. It becomes more urgent when OOM events interrupt services, the server lacks reliable console access, or several applications compete for limited RAM.

Tech Rescue Ops LLC can help review memory patterns, swap behavior, process growth, service logs, and capacity options remotely. Professional assistance is appropriate when the next step could interrupt production or when the evidence points to an application, container, or infrastructure problem requiring coordinated review.

For related diagnostic methods, see our guide to Linux server performance checks before restarting and our Linux server support services.