Linux memory usage can be difficult to interpret and hard to understand. With
smem it’s easy to find out what memory a process is using, and which processes are using the most.
Linux gives you many ways to check what’s happening with your computer’s RAM. The problem is, memory management is a complicated challenge for your operating system. It has to juggle physical RAM, virtual RAM in the form of swap space, and the demands of the different types of processes that are running at any one time.
Processes consume RAM as they load themselves into memory. They then request more RAM so that they have space to perform whatever tasks it is they’re designed to do. Some processes hardly impact RAM, others are very memory-hungry.
The kernel and the rest of the operating system, your desktop environment, and every application or command line session you run are all clamoring for a portion of the finite amount of RAM installed in your computer. Some processes spawn other processes. Some processes share RAM with other processes.
Trying to decipher all of this and to come up with a simple answer to the question “How much RAM is this program or process using?” can be a surprising challenge. Granularity is great and has its place but, equally, information overkill can be an impediment.
For example, using
cat to peek into the /proc/meminfo pseudo filesystem returned 50 lines of output on the machine used to research this article. Where do you start?
And some Linux utilities give different answers. On our test machine, we had an instance of
less running, which had a process ID of 2183.
We can use the
pmap utility with the
-x (extended) option to get a full picture of the memory usage of a process. We’ll use it with the process ID of our instance of
pmap -x 2183
At the bottom of the output, we get a total for the Resident Set Size, which is the amount of main RAM being used.
We then used the
ps utility with the
-o (output) option, selected the
RSS column, and passed it the process ID of the same instance of
ps -o rss 2183
We get a different result. This is a design decision on the part of the
ps authors. This is from the
The authors of other utilities have their own views on how to measure RAM usage.
The RSS, the USS, and the PSS
The Resident Set Size (RSS) is the amount of RAM allocated to a process, excluding swap space, but including any RAM required by shared libraries that the process is using.
RSS almost always over-reports RAM usage. If two or more processes use one or more shared libraries, RSS will simply add the RAM usage of each library to its count of RAM usage for each of those processes. As well as inaccuracy, there’s a certain irony to this. Shared libraries mean each process doesn’t need to load its own private instance of a library. If the library is already in memory it’ll share that one—and reduce the RAM overhead.
The Proportional Set Size tries to address this by dividing the amount of shared memory amongst the processes that are sharing it. If there are four processes sharing some memory, PSS reports that 25% of the shared RAM is used by each of those processes. This is an approximation but it more closely resembles what’s going on than the picture that RSS paints.
The Unique Set Size is the amount of RAM that is being used exclusively by a process whether it is directly consumed by the process, or used by libraries that are solely in use by the process. Again, it ignores swap space. It’s only interested in genuine, physical RAM.
USS and PSS are terms and concepts that were proposed by Matt Mackall, the author of
The smem Utility
smem utility reports on memory used by processes, users, mapping, or system-wide. On all distributions we tested, it required installing. To install it on Ubuntu, use this command:
sudo apt install smem
smem on Fedora you need to type:
sudo dnf install smem
smem on Manjaro use:
sudo pacman -Sy smem
smem with no options gives you a list of the processes that are using RAM.
A table of information is displayed in the terminal window.
The columns are:
- PID: The process ID of the process that’s using the memory.
- User: The username of the user who owns the process.
- Command: The command line that launched the process.
- Swap: How much swap space the process is using.
- USS: The Unique Set Size.
- PSS: The Proportional Set Size.
- RSS: The Resident Set Size.
To see the sizes expressed as percentages, use the
-p (percentage) option.
The sizes in bytes have been replaced with percentages.
To see the figures rendered in a more human-friendly form, use the
-k (abbreviate) option. This shrinks the figures and adds unit indicators.
Instead of raw bytes, the sizes are shown in megabytes, gigabytes, and so on.
To add a totals line, use the
-t (totals) option.
smem -k -t
The last line of the output shows totals for each column.
Refining the Report
You can ask
smem to report on the memory usage by users, mapping (libraries), or system-wide. To filter the output by user use the
-u (user) option. Note that if you want to see more than just your own usage, you’ll need to run
sudo smem -u
As you can see, the output gets bent out of shape for user names longer than eight characters.
To see the usage mapped to the libraries that are in use, regardless of which processes are using the libraries, nor which users own those processes, use the
-m (mapping) option.
smem -m -k -t
We also asked for human-readable values and a total.
To see the system-wide memory usage use the
-w (system-wide) option.
smem -w -k -t
Reporting on a Single Program
With a little bit of command-line magic, we can report on a single program and all of its sub-processes. We’ll pipe the output from
tail and ask
tail to only show the last line. We’ll tell
smem to use human-readable values and to provide a total. The total will be the last line, and that’s the line
tail will display for us.
We’ll use the
-c (columns) option with
smem and tell it which columns we want to be included in our output. We’ll restrict this to the Proportional Set Size column. The
-P (process filter) option allows us to give a search string to
smem . Only matching lines of output will be included.
smem -c pss -P firefox -k -t | tail -n 1
That’s a quick and neat way to find out the RAM consumption of a program and its child processes.
You can pass the
--bar options to have
smem generate graphs. It has to be said that with too many categories the graphs quickly become unintelligible, but they can be useful for a quick visual overview.
The command format is:
smem --pie name -s uss
The pie chart appears in its own viewer window.
To see other plots, use
rss instead of
uss. To see a bar graph, use
--bar instead of
For this to work you’ll need to have Python installed, along with the
matplotlib library. These were already installed on the Ubuntu, Fedora, and Manjaro distributions we tested.
Good Things Come In Small Packages
smem utility has a few more tricks up its sleeve, and you’re encouraged to check out its
man page. Its main repertoire is what we’ve outlined here, and it’s a great little tool to have in your CLI toolbox.
- › How to Use the pmap Command on Linux
- › Intel’s Arc A750 Graphics Card Has a New Lower Price
- › Windows 11 Is Adding Even More Widgets
- › Samsung Made a Music Video for the Galaxy S23’s Ringtone
- › AMD’s Ryzen 7000X3D Pricing Looks Really, Really Good
- › Windows 10’s Bad Upgrade Prompts Are Back for Windows 11
- › Work and Play Anywhere With the ROG G14 Laptop, Now $400 Off