How to Accurately Check Memory Consumption of a Process in Linux

When your Linux system starts feeling sluggish or running out of memory, one of the first things you’ll want to check is which processes are consuming the most RAM. Tools like ps and top make this easy at a glance, but the numbers they show don’t always tell the full story.

A process might appear to use hundreds of megabytes of memory, yet in reality, a large portion of that memory could be shared with other processes. On the other hand, some processes may seem lightweight while quietly consuming more memory through shared libraries or caches.

To really understand what’s happening, you need to look beyond surface-level statistics and explore how Linux tracks memory internally. In this section, you’ll learn how to analyze a process’s true memory footprint using the /proc filesystem, focusing on a file called smaps that reveals detailed per-process memory mappings.

Before diving in, we’ll first look at the three main memory metrics (VSZ, RSS, and PSS) and understand what each one represents.

Understanding Linux Memory Metrics: VSZ, RSS, and PSS

When you start investigating memory usage on Linux, you’ll encounter a few key metrics that describe how much memory each process is using. At first glance, they can be confusing because they measure different aspects of memory. Let’s unpack them one by one so you can interpret them correctly.

VSZ — Virtual Set Size

The Virtual Set Size (VSZ) represents the total amount of virtual memory a process could theoretically use.
This includes not only the program’s code and data but also shared libraries, memory-mapped files, and reserved space that might never actually be touched.

Think of VSZ as the maximum possible memory footprint, a kind of “memory budget” the process could draw from if it needed to. Because of that, it often exaggerates the real amount of physical memory being used. So, while VSZ helps you understand the total address space allocated to a process, it’s not a good indicator of actual RAM consumption.

You can imagine this as a process reserving a 2 GB block of space, while in reality it might only use a fraction of it. That’s why VSZ often exaggerates the real amount of memory being used , it’s a theoretical upper limit, not what’s actually loaded in RAM.

RSS — Resident Set Size

The Resident Set Size (RSS) shows how much of the process’s memory is currently loaded into your physical RAM.
In other words, RSS represents the portion of the process that’s actively resident in memory right now.

Continuing the earlier analogy: if a process claimed 2 GB of virtual memory (its VSZ) but is only using 800 MB at the moment, that 800 MB is its RSS.

However, RSS can be misleading because it counts all shared memory regions as if they belong entirely to the process. It includes everything currently in use (code, data, heap, stack, and shared libraries), but treats shared pages as exclusive. Imagine several programs using the same 100 MB library: RSS adds the full 100 MB to each process, even though that memory exists only once in physical RAM. As a result, the total RSS across the system can appear larger than the actual installed memory, inflating the perceived usage because shared regions are counted multiple times.

PSS — Proportional Set Size

The Proportional Set Size (PSS) gives the most realistic view of a process’s actual impact on your system’s RAM.
It fixes the double-counting problem by dividing shared memory regions among the processes that use them.

If three processes share a 90 MB library, each one’s PSS increases by 30 MB.
Unlike RSS, PSS already includes private memory pages, so you don’t need to add anything extra to get the total.

This makes PSS the most meaningful measure of how much memory a process truly consumes. It tells you how much physical RAM would be freed if that process were terminated.

TIP
You can see VSZ and RSS using commands like ps or top, but not PSS.
To view a process’s PSS, you’ll need to check its /proc/[PID]/smaps or /proc/[PID]/smaps_rollup file, which we’ll explore next.

Using ps and top for Quick Memory Checks

The easiest way to check how much memory a process uses is by running ps or top. Both commands are built into nearly every Linux distribution and give you a quick snapshot of what’s happening on your system.

Checking Memory with ps

The ps command reports information about active processes. You can customize its output to include memory-related fields such as the process ID (PID), virtual memory size (VSZ), and resident memory size (RSS):

$ ps --forest -o ppid,pid,vsz,rss,comm -C nginx

Here’s what each column represents:

• PID: The process ID.

• VSZ: The total virtual memory allocated to the process (in kilobytes).

• RSS: The portion of memory currently resident in physical RAM (in kilobytes).

• COMMAND: The command used to start the process.

INFO

It’s important to note that the columns specified with the -o option appear in the exact order you list them.

This means you can arrange the output however you prefer. For example, placing rss before vsz if you want to focus on real memory usage first.

From this output, you can see that the main Nginx master process (PID 1353738) has a VSZ of about 16 684 kB and an RSS of around 1 932 kB.
If you divide these values by 1024 (since 1 MB = 1024 kB), that’s roughly 16 MB of total virtual address space and about 1.9 MB currently resident in physical memory.

This difference illustrates a key point: VSZ is always larger than RSS because it represents all the virtual memory the process could access — including code, shared libraries, heap, stack, and unmapped reserved regions — while RSS only reflects the portion actually loaded into RAM.

The worker processes listed below the master show similar VSZ values but slightly higher RSS numbers, indicating that they’re more actively using memory to handle client requests. Because Nginx uses a master-and-worker model/architecture, the hierarchical layout created by the --forest option makes it easy to see how memory usage is distributed across the master and its workers.

NOTE
By default, ps reports VSZ, which can be misleading because it includes unused and shared memory regions. It’s better to focus on RSS for a closer estimate of real memory usage, though even RSS can exaggerate numbers when shared libraries are involved.

Monitoring Memory with top

The top command provides a dynamic, real-time view of what’s running on your system. It refreshes every few seconds, showing CPU and memory usage across all active processes. You can also filter top to focus on specific processes, for example, those belonging to Nginx.

$ top -p $(pidof nginx | tr ‘ ‘ ‘,’ | cut -d’,’ -f1-20)

Let’s break down this command step by step. Many people use top interactively without options, but it’s more flexible than it looks.

• The -p option allows you to monitor specific processes by their process IDs (PIDs).

• Since Nginx spawns multiple worker processes, we use command substitution to generate a list of their PIDs dynamically using pidof nginx.

• The tr ‘ ‘ ‘,’ part converts spaces into commas because top expects the PID list to be comma-separated.

• The cut -d’,’ -f1-20 section ensures that only the first 20 PIDs are passed to top, as it can only handle a maximum of 20 at once.

Once top is running, look for the RES column, it corresponds to RSS (Resident Set Size), showing how much physical memory each process currently occupies. The VIRT column represents VSZ (Virtual Set Size), indicating the total virtual memory mapped by the process.

Although top is convenient for a live overview, it suffers from the same limitation as ps: it can’t show proportional memory usage. Processes that share large libraries or memory segments may appear to use more RAM than they actually do.

So while ps and top are useful for quick checks, they don’t provide the full story. To understand a process’s real memory footprint, we need to dig deeper into the /proc filesystem ,specifically into the smaps file.

---

Sysxplore is an indie, reader-supported publication.
I break down complex technical concepts in a straightforward way, making them easy to grasp. A lot of research goes into every piece to ensure the information you read is as accurate and practical as possible.

To support my work, consider becoming a free or paid subscriber and join the growing community of tech professionals.

---

Diving Deeper with /proc and smaps

To get a precise understanding of how much memory a process is really using, you’ll need to explore the /proc filesystem.
This is a special virtual filesystem that Linux uses to expose kernel and process information to user space. Every process running on your system has its own directory inside /proc, named after its process ID (PID). Inside that directory, you’ll find several files that reveal everything from open file descriptors to detailed memory maps.

$ lsd /proc

Among those files, the one we care about is smaps.

$ ls -lh /proc/[PID]/smaps

It contains a breakdown of how memory is being used by a specific process, including private and shared regions and the Proportional Set Size (PSS) we discussed earlier.

Step 1: Find the Process ID (PID)

Before analyzing memory usage, you first need to identify the process you’re interested in. You can use ps or top to find its PID.

$ ps --forest -o ppid,pid,vsz,rss,comm -C nginx

We already discussed about this command, so we are going to focus on the parent Nginx process with pid of 1353738.

Step 2: View the smaps File

Once you know the PID, you can read the smaps file for that process:

This command prints the first 20 lines of the file, giving you a glimpse of the process’s memory regions and usage statistics.

NOTE

You need sudo to access the smaps file of a process, otherwise you’ll get a Permission denied error.

Each memory region used by the process is listed with detailed statistics. Let’s understand a few of them.

• Size: The total size of the memory region.

• Rss: How much of it is currently in physical RAM.

• Pss: The proportional share of this region’s memory assigned to the process.

• Shared_Clean / Shared_Dirty: Memory pages shared with other processes (clean = unchanged, dirty = modified).

• Private_Clean / Private_Dirty: Memory used exclusively by this process.

TIP
The PSS value is the key metric when you want to know how much memory the process actually contributes to system usage. If the process terminates, the system will reclaim approximately that much memory.

In the example above, notice that the PSS (5 kB) is smaller than the RSS (112 kB).
That’s because part of the memory region is shared, the PSS divides it among processes that use the same library or resource.

Next, we’ll look at how to interpret these smaps fields in more depth and calculate the total proportional memory usage of a process.

Interpreting Process Memory Information

The /proc/[PID]/smaps file contains a tremendous amount of information, and the first time you look at it, it can seem overwhelming. Each memory region in the file corresponds to a specific part of the process’s address space such as program code, shared libraries, heap, stack, or memory-mapped files.

Let’s revisit a simplified portion of the smaps output we saw earlier:

Each of these fields provides clues about how memory is being used:

• Size shows the total size of this memory region in kilobytes.

• Rss (Resident Set Size) tells you how much of that region currently resides in physical RAM.

• Pss (Proportional Set Size) represents the portion of the region that belongs specifically to this process. Shared memory regions have their sizes divided among the processes that use them.

• Shared_Clean and Shared_Dirty indicate memory pages shared with other processes.

  • Clean pages are unchanged copies (usually from shared libraries).

  • Dirty pages have been modified since being loaded.

• Private_Clean and Private_Dirty represent memory regions used exclusively by this process.

  • Private_Clean pages are unmodified.

  • Private_Dirty pages are writable and have been changed by this process.

When analyzing these numbers, the PSS field is the most important.
If you summed the PSS values for all memory regions in this file, you would get a realistic estimate of the process’s total memory footprint. This is roughly the amount of RAM that would become available if the process were terminated.

IMPORTANT
PSS already includes private memory. You don’t need to add private values to it separately. The total PSS represents both the private pages and each process’s fair share of shared pages.

In this example, notice how RSS (112 kB) is higher than PSS (5 kB). This difference exists because a significant part of the memory is shared (Shared_Clean: 112 kB). PSS accounts for that sharing by dividing the shared portion among all users of that memory.

TIP
The smaps file breaks down every individual region of memory. If you only need the totals, you can check /proc/[PID]/smaps_rollup, which provides a concise summary including total PSS, RSS, and Swap values.

Now that you know how to interpret the output of the smaps file, let’s take it a step further and learn how to calculate the total memory usage of a process using command-line tools.

Calculating Real Memory Usage (PSS)

So far, you’ve seen how to view the smaps file and interpret the memory regions for a specific process. Now, let’s go a step further and calculate how much memory the process actually uses, its total Proportional Set Size (PSS).

As mentioned earlier, PSS already accounts for both private and shared memory, making it the most accurate reflection of a process’s real memory footprint.
By summing up all the PSS values from /proc/[PID]/smaps, you can estimate how much of your physical RAM would be freed if that process were stopped.

Step 1: Summing PSS Values

You can calculate the total PSS by extracting all the PSS lines from the smaps file and summing them with awk:

$ sudo cat /proc/1353738/smaps | grep "^Pss:"

$ sudo cat /proc/1353738/smaps | grep "^Pss:" | awk '{total += $2} END {print total, "kB"}'

Let’s look at what each part of this command does:

• sudo cat /proc/1353738/smaps — Prints the contents of the smaps file for the Nginx process with PID 1353738. The sudo command is required because regular users don’t have permission to view such detailed process memory information.

• | grep “^Pss:” — Filters the output, keeping only the lines that start with Pss:. Each Pss: line shows the proportional share of memory used by a particular region of the process.

• | awk ‘{total += $2} END {print total, “kB”}’ — Uses awk to sum all the numeric PSS values (the second field in each line).

  • total += $2 adds each PSS value (in kilobytes) to a running total.

  • END {print total, “kB”} prints the final total followed by the unit label “kB.”

The output shows the total Proportional Set Size (PSS) for that process, representing how much memory it truly occupies after accounting for shared libraries and resources.

This means the Nginx process with PID 1353738 contributes roughly 1.5 MB of real memory usage to your system.

TIP
The same calculation works for any process. Just replace the PID with the one you want to analyze.

---

If you’re enjoying this kind of breakdown, you’ll love my upcoming book First Steps with Linux. I go even deeper into topics like mounting, permissions, system management and so on.
More than 2,500 people have already joined the waitlist, you can join too at firststepswithlinux.com to get notified when it’s out.

---

Step 2: Using smaps_rollup for a Quick Summary

Instead of parsing the entire smaps file manually, modern Linux kernels include a file called /proc/[PID]/smaps_rollup. It provides summarized memory information, including total PSS, RSS, and Swap, all in one place:

$ sudo cat /proc/1353738/smaps_rollup

This is the simplest way to check a process’s true memory usage. It saves you from having to run grep or awk, while still giving accurate results.

NOTE
Not all older kernels have smaps_rollup. If you don’t see it on your system, you can safely rely on the grep and awk method.

This means the Nginx process with PID 1353738 contributes roughly 135 kB (about 0.13 MB) of real memory usage to your system.

---

Thanks for reading!

If you enjoyed this content, don’t forget to leave a like ❤️ and subscribe to get more posts like this every week.

---

Sysxplore is an indie, reader-supported publication.
I break down complex technical concepts in a straightforward way, making them easy to grasp. A lot of research goes into every piece to ensure the information you read is as accurate and practical as possible.

To support my work, consider becoming a free or paid subscriber and join the growing community of tech professionals.