How to Check Memory Consumption of a Process in Linux

Knowing how much memory a process uses on your Linux system will help you troubleshoot and optimize it. You can get some insights using standard tools like ps and top. But sometimes, they offer incomplete or even misleading information. 

This tutorial will hold your hands through how to get a better picture of memory consumption on your Linux machine. You’ll get more accurate memory analysis using the /proc filesystem and the smaps file.

Understanding Memory Metrics: VSZ, RSS, and PSS

When trying to find out the memory usage of your Linux machine, you'll encounter three key metrics. Understanding what these metrics entail and how they differ will help you get an accurate picture of memory usage.

1. VSZ (Virtual Set Size)

Think of VSZ as the total memory space a Linux process could use (in theory). It covers everything from the program's code to shared libraries and the data the program uses. 

Yet, as we noted above, this memory usage is theoretical. It doesn't tell you the actual usage but a potential one. So, it's not the best indicator of a process's true impact on your system's RAM.

2. RSS (Resident Set Size)

This metric tells you how much memory a process currently occupies in your system's physical RAM. RSS is helpful but can be misleading. 

Let's assume you have your Chrome browser with multiple tabs open. Each tab will load the same image file. However, RSS will count the image's size numerous times, even though it's loaded physically in the RAM only once.

3. PSS (Proportional Set Size)

PSS is where things get interesting. It offers the most realistic analysis of the memory consumption of a Linux process.

Let's say four processes use a shared library. PSS takes the library's memory size and divides it by four. So, it assigns a proportional share to each process. Therefore, PSS only inflates the memory usage of processes that rely heavily on shared resources.

Now that you know the three metrics for memory analysis, let's illustrate with a simple example.

Example

To find out the memory consumption of your Firefox browser, use the command below:

$ ps -o pid,vsz,rss,args -C firefox

  PID    VSZ     RSS      COMMAND
 78783 2971088 293884 /snap/firefox/3627/usr/lib/firefox/firefox

The above command displays information about the Firefox process. Now, let’s break down the command:

• ps: This is the fundamental Linux command for displaying information about running processes
• -o: This option is used to customize the output format. We customized our output based on the following format:

• pid: The Process ID (PID) of each matching process.
• vsz: The Virtual Set Size (VSZ) in kilobytes.
• rss: The Resident Set Size (RSS) in kilobytes.
• args: The full command line used to launch the process.

• -C firefox: This filters the output to display only processes whose command name contains the string, “firefox”.

In the command’s output:

• Firefox has a VSZ of `2971088 kilobytes`, indicating the total virtual memory the process could potentially use
• THe RSS is only `293884 kilobytes`, reflecting the actual amount the Firefox process is currently occupying

Additionally, if Firefox loads a shared system library, the PSS would tell its share of the library’s memory cost. But you can’t view the PSS by directly using the `ps` command. 

Later in this article, you’ll learn how to view the PSS of a process using a combination of commands with the smaps file of the `/proc` filesystem.

Limitations of Standard Monitoring Tools (ps, top)

Although the ps and top commands are essential Linux utilities, they have shortcomings. These tools are not reliable when it comes to providing a clear picture of memory usage. 

Let’s understand why:

• ps: By default, the command ps often displays the Virtual Set Size (VSZ) of Linux processes. VSZ tells you the total amount of memory a process can use, regardless of whether it currently occupies the allocated memory space. Hence making VSZ a misleading figure when assessing actual memory impact.
• top: This command displays the Resident Set Size (RSS). The RSS shows you how much of a process’s memory your physical RAM holds. While this is helpful, RSS is often inaccurate for processes that rely heavily on shared libraries.

Now, you know why you can’t rely on the commands ps and top to analyze memory consumption on your Linux machine. The workaround is to use tools that analyze the /proc filesystem and calculate the Proportional Set Size (PSS).

Analyzing Memory Usage with /proc and smaps

When you need to look deeper into memory usage for specific purposes, Linux provides a powerful tool. The tool is the /proc filesystem and its smaps file. Let’s explore how it can reveal the true memory usage of a process.

1. Find the Process ID (PID)

Before you can analyze the memory usage of any process, you need to identify the Process ID (PID). You can do this using commands like ps or top.

Using ps:

$ ps aux | grep <process_name>

The command above will display all the processes containing <process_name>, along with their corresponding PIDs, among other details.

Using `top`:

$ top

After typing the above command on your terminal, locate the process you’re interested in. The first column will be its PID. Then press q to exit top.

2. Access /proc/[PID]/smaps

As soon as you get the PID of the Linux process, you can access detailed information about it through the smaps file. This file is found within the /proc directory. 

Replace [PID] below with the actual PID of the process you want to analyze.

$ cat /proc/[PID]/smaps

The command above displays the contents of the smaps file, providing comprehensive memory usage information for the specified process.

Example

Say you want to check the memory usage of the Apache2 (web server) process. Follow the simple steps below:

Step 1: Find the Process ID (PID) of Apache2

$ ps aux | grep apache2

Output:

Ubuntu 949  0.0  0.2  7512  4096 ?  S  08:00   0:00 /usr/sbin/apache2 -k start
ubuntu 950  0.0  0.2  7696  4108 ?  S  08:05   0:00 /usr/sbin/apache2 -k start

Here, the PID is 949.

Step 2: Access the smaps file for Apache2

$ cat /proc/949/smaps | head -n 20

The command above prints the first 20 lines of the /proc/949/smaps file. Here’s the breakdown:

• cat: this concatenates and displays file content.
• /proc/949/smaps: points to the memory map statistics for the PID 949.
• head -n 20: displays the first 20 lines of the input it receives.

Output:

08048000-08056000 r-xp 00000000 08:15 13130      /usr/sbin/apache2
Size:                688 kB
Rss:                 512 kB
Pss:                 255 kB
Shared_Clean:        384 kB
Shared_Dirty:          0 kB
Private_Clean:       128 kB
Private_Dirty:        88 kB
Referenced:          512 kB
Anonymous:            88 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
FilePmdMapped:         0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB
VmFlags: rd ex mr mw me dw sd

Interpreting Process Memory Information

The first 20 lines in the output above represent various memory regions used by the Apache web server process. Here’s what the key metrics mean:

• Size: total size of the memory region in kilobytes
• Rss: How much of the region is currently loaded into the physical RAM
• Pss: The most important metric when it comes to the actual memory impact of a process. It tells you how much of this region’s cost is attributed specifically to this process, taking shared memory into account.

Shared/Private:

• Shared: Memory regions marked as “Shared” could be used by other processes. They are often shared code or libraries.
• Private: Memory regions marked “Private” are exclusive to this specific process (PID 949)

Analyzing the PSS in the above example:

Observe that the PSS values are often smaller than RSS. This difference indicates memory sharing is at play. PSS helps prevent the overestimation of memory usage for processes that use shared libraries (a common scenario).

The key takeaway here is that by analyzing the `smaps` file, focusing on PSS, you can get a better picture of how much memory a process is using.

Identifying Shared Memory Usage

One may wonder why shared memory matters. The reason is that efficiently designed Linux systems rely on shared memory to prevent unnecessary copies of data or code.

For example, many processes like your text editor and web browser use shared system libraries (e.g the libc library for core functionality). Loading this library once into physical RAM and sharing it saves considerable memory resources.

Also, Linux processes use shared memory segments to exchange data, enabling fast and efficient direct collaboration.

The Shared Indicator in smaps

Entries marked Shared in the /proc/{PID]/smaps file are strong indicators of shared memory usage. Shared memory doesn't necessarily mean a process has a small memory footprint. It depends on how much other shared memory it uses.

Below, we highlight (in yellow) the shared memories in the output of our previous example:

08048000-08056000 r-xp 00000000 08:15 13130      /usr/sbin/apache2
Size:                688 kB
Rss:                 512 kB
Pss:                 255 kB
Shared_Clean:        384 kB
Shared_Dirty:          0 kB
Private_Clean:       128 kB
Private_Dirty:        88 kB
Referenced:          512 kB
Anonymous:            88 kB
AnonHugePages:         0 kB
ShmemPmdMapped:        0 kB
FilePmdMapped:         0 kB
Shared_Hugetlb:        0 kB
Private_Hugetlb:       0 kB
Swap:                  0 kB
SwapPss:               0 kB
Locked:                0 kB
VmFlags: rd ex mr mw me dw sd

In the above block:

• Shared_clean: This memory portion contains data or code (from a shared library) currently residing in RAM and unmodified since being loaded. `384 kB` indicates a significant portion of this region is likely shared with other processes.
• Shared_dirty: This memory segment contains code or data from a shared source that has been modified since being loaded. `0 kB’ indicates that no modifications have been made to the shared portion of this memory region.

The presence of Shared_clean or Shared_dirty is a strong indicator of shared memory usage. However, you can’t determine the exact library or mechanism used for sharing from the smaps output alone.

Calculating Real Memory Usage: Pss and Private Memory

Figuring out how much memory a process truly uses requires a bit more detective work than just using standard tools. Here’s how you can get the real value by focusing on Pss and private memory:

Step 1: Calculate the Pss

Use grep and awk to calculate the total Pss (still using our apache2 process above with PID 949):

$ cat /proc/949/smaps | grep Pss | awk '{total += $2} END {print total}'

Output:

1520

The above command retrieves the Pss values from the smaps file for Apache2 process and calculates the total Pss value.

Step 2: Accounting for Private Memory

Look for memory regions marked as Private in the smapa file. These regions contribute to the process’s private memory usage and should be accounted for in the overall memory analysis. 

Combine the total Pss and private memory usage and you’ll get the true memory footprint of your apache2 process.

Practical Example: Determining Nginx Process Memory Usage

Let’s apply the concepts we’ve learned above to analyze the memory usage of an Nginx web server process. Here’s the breakdown:

1. Extract Pss Values:

First we need to get the PID of the Nginx process:

$ ps aux | grep nginx

Output:

ubuntu    144239  0.0  0.0  50552  1456 ?        Ss   13:03   0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data  144241  0.0  0.3  51176  6220 ?        S    13:03   0:00 nginx: worker process
www-data  144242  0.0  0.3  51176  6220 ?        S    13:03   0:00 nginx: worker process
ubuntu    144276  0.0  0.0   7696   632 pts/0    S+   13:12   0:00 grep --color=auto nginx

The PID of the Nginx process is 144239. Now, let’s use this value to get the total Pss of the Nginx process:

$ cat /proc/144239/smaps | grep Pss | awk '{total += $2} END {print total}'

Output:

753

2. Extract Private Memory Values:

Next, we’ll examine the memory region marked Private in the smaps file. These regions contribute exclusively to the Nginx process’s memory. 

Let’s extract the total Private memory value:

$  cat /proc/144239/smaps | grep Private | awk '{total += $2} END {print total}'

Output:

180

Adding the total size of Private regions to the total Pss value calculated earlier will give you the true memory footprint of your Nginx server process.