$ Linux One Liners
Back to problems

problem hub

Read-only, sensitive output

High memory process on Linux

Check memory, swap, top memory processes, containers, and OOM logs before restarting workloads.

Safest first command

free -h

Before you run this

Expected output: Memory and swap totals, used, free, cache, and available memory in human-readable units.

When not to use it: Do not assume the largest process is broken. It may be a database, cache, or worker designed to use memory.

Expected output example

              total        used        free      shared  buff/cache   available
Mem:           7.7Gi       6.8Gi       220Mi       180Mi       700Mi       420Mi
Swap:          2.0Gi       1.1Gi       900Mi

How to read the result

Use available memory and swap together. Linux cache is normal; high swap use plus low available memory suggests real pressure.

What to check next

Available memory is low and swap is active

Means: The host is under real memory pressure, not just using cache.

Next step: Summarize memory pressure and then rank processes by memory.

Check Memory Pressure Quickly

One process dominates RSS or %MEM

Means: The process is the first suspect, but large memory use can be normal for databases and caches.

Next step: Capture process context and service ownership before restarting anything.

Find the Processes Eating Memory

Kernel logs mention OOM or killed process

Means: The OOM killer already acted, so the current process list may miss the original victim.

Next step: Inspect recent OOM lines before changing service limits or swap.

Spot OOM Kills in the Kernel Journal

Check memory pressure and top processes

Memory pressure is not only used memory. Look at available memory, swap, OOM logs, and top memory processes together.

  1. free -h
  2. ps -eo pid,ppid,stat,pcpu,pmem,comm,args --sort=-pmem | head
  3. journalctl -k --since '2 hours ago' --no-pager | grep -i 'out of memory\|oom'

Bad fixes to avoid

Do not restart the largest process just because it is large. Do not add swap or tune OOM settings before checking logs and ownership. Do not paste process arguments, environment, or private paths into public tickets.

Common causes

  • Database or cache using expected memory
  • Memory leak in app workers
  • Too many concurrent jobs
  • Container memory pressure
  • OOM killer terminated a process earlier

What not to change yet

  • Do not restart the largest process just because it is large.
  • Do not add swap before checking why memory is exhausted.
  • Do not paste full process arguments or environment publicly.

Stop and escalate if

  • The system is near OOM and restarting services could make the outage worse.
  • The memory-heavy process owns production traffic, data writes, or queue processing.
  • Swap, disk, or kernel logs suggest wider resource or hardware trouble.

platform notes

Distro and service notes

OOM

Kernel logs can confirm whether the OOM killer acted.

Containers

Container limits can cause OOM while host memory looks available.

Databases

Databases often use memory intentionally; inspect config before restarting.

supporting commands

Command path

Guides and drills