How to Use the Linux pmap Command to Analyze Process Memory Footprints

Beyond Basic Memory Monitoring

When a Linux server starts running out of RAM, most administrators rely on the top or htop commands. These tools provide a quick overview, showing that a specific process (like mysqld or java) is consuming 4 GB of memory.

However, that single number is often misleading. Linux memory management is incredibly complex. A process doesn’t just hold one monolithic block of RAM. Its memory footprint is divided into many different segments: the actual executable code, the stack, the heap (where dynamic variables live), and crucially, shared libraries (like libc.so) which might be loaded into RAM once but used by fifty different programs simultaneously.

If you are troubleshooting a severe memory leak, or trying to optimize a custom application, knowing that it uses “4 GB” isn’t enough. You need to know exactly where that memory is allocated. To see this detailed breakdown, you need the pmap command.

Step 1: Finding the Process ID (PID)

Before you can use pmap, you must identify the exact Process ID (PID) of the program you want to investigate.

You can find this using the pidof command. For example, to find the PID of the Nginx web server, type:

pidof nginx

Assume this returns 1452. You will use this number in the next step.

Step 2: Running the Basic pmap Command

To view the memory map of a process, pass the PID to the pmap command (you usually need root privileges to view the memory of processes you don’t own):

sudo pmap 1452

The output will be a long list of memory allocations. It will look something like this:

1452:   nginx: worker process
000055c88439d000    828K r-x-- nginx
000055c88466b000      4K r---- nginx
000055c88466c000     88K rw--- nginx
000055c88562d000   1024K rw---   [ anon ]
00007fb18bc00000   1948K r-x-- libc-2.31.so
...
total            125432K

Step 3: Decoding the Output

Let’s break down what those columns mean:

1. Memory Address: (e.g., 000055c88439d000) This is the exact hexadecimal starting address of the memory block in the server’s RAM.
2. Size: (e.g., 828K) The size of that specific allocation in kilobytes.
3. Permissions: (e.g., r-x--) This indicates what the process is allowed to do with this memory segment. r (read), w (write), and x (execute). A segment marked r-x is executable code, while rw- is usually data variables.
4. Mapping: This tells you exactly what is stored there. It could be the main executable file (nginx), a shared library (libc-2.31.so), or it might say [ anon ].

Understanding [ anon ] (Anonymous Memory)

Anonymous memory is memory that is not backed by a physical file on the hard drive. This is usually the “heap” or the “stack”—the dynamic memory allocated by the program while it is running (e.g., using the malloc() function in C). If you suspect an application has a memory leak, you should look closely at the size of the [ anon ] blocks. If these blocks are massive and constantly growing, the program is failing to free its variables.

Step 4: Using the Extended Format (-x)

The basic output is useful, but the extended format provides the most critical piece of information: Shared vs. Private memory.

Run the command with the -x flag:

sudo pmap -x 1452

The output adds several new columns. The most important are RSS (Resident Set Size) and Dirty.

• RSS: This is the amount of physical RAM actually being consumed by this specific block right now (ignoring memory that was allocated but never used, or swapped to disk).
• Dirty: This is the crucial metric. “Dirty” memory is private memory that has been modified specifically by this process. Unlike clean shared libraries, dirty memory cannot be shared with any other program on the system.

By looking at the total “Dirty” memory at the very bottom of the pmap -x output, you can see the true, isolated memory footprint of the application, distinct from the shared resources it borrows from the operating system.