Analyzing Linux Process Memory Usage with ps, pmap, and Alternative Tools

1. Overview

In this tutorial we discuss Linux memory‑usage analysis, first examining how Linux applications work and share memory to optimise resources, which influences how we define an application's memory consumption.

We then explore how to inspect a given application's memory usage and differentiate the portion exclusive to the application from the portion shared with other applications.

2. Understanding Memory in Linux

Most Linux applications use shared libraries; these libraries are required for execution but can be used by many processes, making it difficult to state the exact memory usage of a single application.

Should we count only the memory the application itself uses, or also the memory occupied by shared libraries? Including shared libraries can inflate the reported usage because they are loaded by default.

2.1. Potential Misuse of the ps Command

The ps command can monitor processes, but its memory fields must be interpreted carefully; the top command may also show unexpected values.

Running a detached process with sleep and checking it with ps -u -p <PID> yields VSZ (Virtual Set Size) and RSS (Resident Set Size) values:

$ sleep 15 &
[1] 611040
$ ps -u -p 611040
USER           PID %CPU %MEM    VSZ   RSS TTY   STAT START   TIME COMMAND
username    611040  0.0  0.0   5544  2076 pts/3 S   01:45   0:00 sleep 15

VSZ reports the maximum addressable RAM (including shared libraries), while RSS reports only the resident RAM, excluding shared libraries.

3. Using pmap for Accurate Memory Information

The pmap command reports a process's memory map. By default it shows only the current user's processes; use sudo to view all.

Running pmap -d <PID> provides a detailed breakdown, including mapped memory, writable/private memory, and a summary that corresponds to the VSZ reported by ps :

$ sudo pmap -d 611040
611040:   sleep 15
Address           Kbytes Mode  Offset Device Mapping
000061fabc20c000      8 r---- 0 ... sleep
... (output truncated) ...
mapped: 5548K   writeable/private: 336K   shared: 0K

The writable/private memory (336 KB) differs markedly from the VSZ value (5544 KB) because VSZ includes shared libraries.

pmap also shows per‑component usage, revealing multiple mappings of shared libraries such as ld-linux-x86-64.so.2 , which explains why ps can over‑report memory.

Additional flags -x and -X provide RSS, dirty pages, and PSS (Proportional Set Size) values, the latter reflecting both private and proportionally‑shared memory.

4. Alternatives to pmap

Other sources of memory information include the /proc pseudo‑filesystem.

4.1. /proc Files

The /proc/<PID>/status file offers similar data to ps (e.g., VmSize, VmRSS). The /proc/<PID>/smaps file provides a detailed per‑segment view comparable to pmap , including size, RSS, PSS, and other metrics.

$ cat /proc/611040/status
Name:   sleep
VmSize:  5544 kB
VmRSS:   2076 kB
... (truncated)

$ cat /proc/611040/smaps
5f7d1dbf7000-5f7d1dbf9000 r--p 00000000 ... /usr/bin/sleep
Size: 8 kB
Rss: 8 kB
Pss: 8 kB
...

4.2. Other Packages

Tools such as smem (a ps alternative) report VSZ, RSS, USS (Unique Set Size), and PSS. exmap can locate memory‑intensive processes, detect leaks, and assess inefficiencies. valgrind (with visualisers like alleyoop ) provides deep memory‑usage diagnostics, though it slows the program.

5. Conclusion

The article covered Linux memory usage, the impact of shared libraries on memory definitions, and the pitfalls of interpreting ps output. It highlighted that pmap and related tools deliver richer, component‑level insights, and presented alternative methods for obtaining memory information when pmap is unavailable.