How to Check Memory Usage per Process in Linux

When a Linux server feels slow or swap usage keeps increasing, one of the first questions is usually: which process is consuming memory? The answer depends on what you mean by memory. If the same process keeps growing over time, use these checks together with Linux memory leak detection tools.

For a fast operational check, ps and top are usually enough. They show RSS, which is the amount of physical memory currently resident for a process. For deeper troubleshooting, especially when many processes share libraries or memory mappings, you need /proc/<PID>/smaps_rollup or /proc/<PID>/smaps because those files expose PSS and private memory.

This guide shows practical Linux commands to check memory usage per process, find the top memory-consuming process, inspect one PID, and understand why different tools may show different numbers.

If the process runs in a container or Kubernetes pod, also compare RSS to cgroup usage and memory.stat on the host: a modest ps line can coexist with a cgroup near its cap because of cache, tmpfs, or other charged memory. For that three-way split (metrics vs cgroup vs process RSS), see Linux memory limits in containers (cgroups, Docker, and Kubernetes).

The examples below were tested on a Linux host with procps-ng tools, pmap, pidstat, and a temporary Python process that allocated about 80 MiB of memory. Your PIDs, usernames, process names, and memory values will be different.

Quick Command Summary

Understand Process Memory Terms First

Linux memory tools use different metrics. If you compare commands without knowing these terms, the output can look inconsistent.

For everyday troubleshooting, sort by RSS first. If several related processes look large because they share memory, use PSS to avoid over-counting. For a broader explanation of Linux memory behavior, see Linux memory management basics.

1. Check Top Memory-Consuming Processes with ps

The ps command is the fastest non-interactive way to list memory usage by process. This command sorts all processes by RSS in descending order:

ps -eo pid,user,comm,rss,%mem --sort=-rss | head -n 8

Tested output:

PID USER     COMMAND           RSS %MEM
  87638 golinux+ hugo            1361764 15.7
  39280 golinux+ MainThread      726732  8.3
  14667 golinux+ node            309604  3.5
   4307 root     kube-apiserver  251948  2.9
   4424 root     kube-apiserver  244872  2.8
   4901 root     kube-apiserver  221252  2.5
  39257 golinux+ MainThread      138712  1.5

In this output:

• RSS is shown in KiB.
• %MEM is the process RSS as a percentage of total physical memory.
• COMMAND is shortened to the executable name.

If you also want parent PID and virtual memory size, use this version:

ps -eo pid,ppid,user,comm,rss,vsz,%mem --sort=-rss | head -n 8

Tested output:

PID    PPID USER     COMMAND           RSS    VSZ %MEM
  87638   12696 golinux+ hugo            1361768 4387312 15.7
  39280   39231 golinux+ MainThread      726732 28075072  8.3
  14667   13864 golinux+ node            309324 86675144  3.5
   4307    3579 root     kube-apiserver  251952 1516052  2.9
   4424    3898 root     kube-apiserver  244968 1516820  2.8
   4901    4651 root     kube-apiserver  221304 1454104  2.5
  39257   39231 golinux+ MainThread      138712 1734324  1.5

This is useful when you need to know whether a large memory consumer is a child of another service or shell. If you want a wider process-management reference, see ps command examples in Linux and how to list Linux processes. For repeatable reporting, you can also adapt this shell script to check top memory and CPU consuming processes.

2. Check Live Process Memory with top

Use top when you want an interactive, live view. Inside top, press M to sort by memory usage. For a command-line snapshot that can be copied into logs or tickets, use batch mode:

top -b -o %MEM -n 1 | head -n 12

Tested output:

top - 21:51:53 up  7:56, 12 users,  load average: 5.13, 6.81, 9.01
Tasks: 397 total,   1 running, 396 sleeping,   0 stopped,   0 zombie
%Cpu(s): 26.0 us, 46.0 sy,  0.0 ni, 16.0 id,  0.0 wa,  0.0 hi, 12.0 si,  0.0 st
MiB Mem :   8467.0 total,    581.7 free,   5212.6 used,   3071.8 buff/cache
MiB Swap:   1024.0 total,     31.2 free,    992.8 used.   3254.4 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  87638 golinux+  20   0 4387312   1.3g  47472 S   0.0  15.7  22:57.50 hugo
  39280 golinux+  20   0   26.8g 727012  28668 S   5.3   8.4  19:29.20 MainThr+
  14667 golinux+  20   0   82.7g 311212  28308 S   0.0   3.6  20:22.56 node
   4307 root      20   0 1516052 252148  34212 S  10.5   2.9  58:28.81 kube-ap+
   4424 root      20   0 1516820 245100  34496 S  15.8   2.8  54:01.46 kube-ap+

top uses VIRT, RES, and SHR labels instead of VSZ, RSS, and shared resident memory. RES is usually the column you want for current RAM usage. For more top usage patterns, see top command examples in Linux.

3. Check Memory Usage for One Process

When you already know the PID, query that process directly. In this test, a temporary Python process allocated about 80 MiB of memory and then slept.

ps -o pid,ppid,user,comm,rss,vsz,%mem -p 111889

Tested output:

PID    PPID USER     COMMAND           RSS    VSZ %MEM
 111889  111878 root     python3         90692 102288  1.0

This tells us the process has about 90,692 KiB RSS and 102,288 KiB VSZ. RSS is actual resident memory; VSZ is the larger virtual address space.

If you need to stop a process after confirming it is the memory problem, see how to kill a process in Linux. If your process has many threads, also compare with checking thread count per process in Linux.

4. Read Process Memory from /proc/PID/status

The /proc/PID/status file gives readable memory fields for one process. Replace 111889 with your PID:

grep -E '^(Name|State|VmHWM|VmRSS|RssAnon|RssFile|RssShmem|VmSwap):' /proc/111889/status

Tested output:

Name:	python3
State:	S (sleeping)
VmHWM:	   90692 kB
VmRSS:	   90692 kB
RssAnon:	   84788 kB
RssFile:	    5904 kB
RssShmem:	       0 kB
VmSwap:	       0 kB

Useful fields:

• VmRSS is the current resident memory.
• VmHWM is the peak resident memory, also called high-water mark.
• RssAnon is anonymous memory, often heap and private allocations.
• RssFile is file-backed resident memory, such as mapped executable and library pages.
• RssShmem is resident shared memory.
• VmSwap shows swapped-out memory for the process.

This method is lightweight and does not require extra packages.

5. Use smaps_rollup for RSS, PSS, and Private Memory

For more accurate per-process accounting, use /proc/PID/smaps_rollup when it is available. It summarizes the process memory mappings without forcing you to parse the full /proc/PID/smaps file.

grep -E '^(Rss|Pss|Private_Clean|Private_Dirty|Swap):' /proc/111889/smaps_rollup

Tested output:

Rss:               90692 kB
Pss:               88340 kB
Private_Clean:      3496 kB
Private_Dirty:     84788 kB
Swap:                  0 kB

Here Pss is lower than Rss because some resident pages are shared. For a single process, RSS is usually fine for a quick check. For groups of related processes, PSS is usually better because it avoids counting the same shared pages repeatedly.

To estimate USS from this output, add Private_Clean and Private_Dirty:

USS ~= Private_Clean + Private_Dirty
USS ~= 3496 kB + 84788 kB = 88284 kB

Use the full /proc/PID/smaps file only when you need mapping-by-mapping detail. It is more verbose and can be more expensive to read for very large processes.

6. Convert /proc/PID/statm Resident Pages to KiB

The /proc/PID/statm file stores memory values as page counts. The second field is resident pages. Use getconf PAGESIZE to convert pages to KiB:

awk -v pagesize="$(getconf PAGESIZE)" '{printf "resident_pages=%s rss_kb=%d\n", $2, ($2*pagesize)/1024}' /proc/111889/statm

Tested output:

resident_pages=22673 rss_kb=90692

This matches VmRSS from /proc/111889/status because 22,673 resident pages at 4 KiB per page equals 90,692 KiB.

7. Inspect Process Memory Maps with pmap

pmap shows memory mappings for a process. It is useful when you need to see whether memory is anonymous, stack, library-backed, or file-backed.

pmap -x 111889 | tail -n 8

Tested output:

00007feab810d000      44      40       0 r---- ld-linux-x86-64.so.2
00007feab8118000       8       8       8 r---- ld-linux-x86-64.so.2
00007feab811a000       4       4       4 rw--- ld-linux-x86-64.so.2
00007feab811b000       4       4       4 rw---   [ anon ]
00007ffc0a78d000     132      84      84 rw---   [ stack ]
ffffffffff600000       4       0       0 --x--   [ anon ]
---------------- ------- ------- -------
total kB          102292   90692   84788

The summary line shows total virtual size, RSS, and dirty memory in KiB. pmap is helpful when a process has many mapped files or a large anonymous region.

8. Check Overall Memory Before Blaming One Process

Before killing or tuning a process, check system-wide memory. Linux uses free memory for page cache, so low free memory alone does not always mean trouble.

free -h

Tested output:

total        used        free      shared  buff/cache   available
Mem:           8.3Gi       5.1Gi       590Mi        98Mi       3.0Gi       3.2Gi
Swap:          1.0Gi       992Mi        31Mi

Look at available, not only free. If available is still healthy, the system may be using memory efficiently for cache. If swap usage is high and available is low, then per-process memory checks become more urgent. To correlate memory, swap, run queue, and I/O wait, see vmstat command examples. For swap operations, see swapon and swapoff command examples. For disk-space checks, see how to check disk space in Linux; for Transparent HugePages memory accounting, see how to check Transparent HugePages in Linux.

9. Sample Per-Process Memory Activity with pidstat

pidstat can sample memory-related counters for a PID. This is useful when you want to see whether a process is actively faulting pages.

pidstat -r -p SELF 1 1

Tested output:

Linux 6.14.0-37-generic (server1) 	06/07/26 	_x86_64_	(3 CPU)

21:51:13      UID       PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
21:51:14        0    112361      1.00      0.00    8784    2200   0.03  pidstat
Average:        0    112361      1.00      0.00    8784    2200   0.03  pidstat

Important columns:

• minflt/s is minor page faults per second. These do not require disk I/O.
• majflt/s is major page faults per second. These may require disk I/O and can indicate pressure.
• VSZ, RSS, and %MEM have the same general meaning as in ps.

For broader system performance monitoring, see sar command examples in Linux.

Which Method Should You Use?

For most incidents, use this order:

1. Run free -h to confirm whether the system is under memory pressure.
2. Run ps -eo pid,user,comm,rss,%mem --sort=-rss | head to find likely processes.
3. Inspect the top PID with ps -p PID, /proc/PID/status, and /proc/PID/smaps_rollup.
4. Use pmap -x PID only when you need mapping detail.
5. Use PSS instead of RSS when comparing many related processes that share memory.

Summary

To check memory usage by process in Linux, use ps for the fastest sorted list, top for live monitoring, and /proc/PID/status for a lightweight one-process view. When RSS is misleading because of shared memory, use /proc/PID/smaps_rollup and check Pss. For mapping-level detail, use pmap -x PID.

The main rule is simple: RSS is good for quick troubleshooting, PSS is better for accurate accounting, and VSZ is not the same as RAM usage.