How to Check Process Memory Usage in Linux Using smem

Monitoring system memory consumption is a core responsibility for Linux administrators and developers. While standard system utilities like top, htop, and free provide high-level statistics, their process-level memory metrics often produce wildly misleading conclusions. Most command-line tools report Resident Set Size (RSS) and Virtual Memory Size (VSS). However, because modern Linux software extensively shares shared dynamic libraries (such as glibc) across hundreds of spawned processes, summing the RSS values across all processes frequently yields a total figure far exceeding physical RAM installed in the server.

The smem command solves this fundamental reporting flaw. By querying the kernel’s memory mapping statistics in /proc, smem calculates two crucial metrics: Unique Set Size (USS) and Proportional Set Size (PSS). In this guide, you will learn how to install smem, interpret its detailed output, filter memory hogging processes, and generate visual graphical memory charts in Linux.

Understanding Memory Metrics: USS vs PSS vs RSS

To accurately diagnose memory leaks or provision containers, you must understand the four primary memory metrics reported by smem:

Metric	Name	Definition & Operational Meaning
VSS	Virtual Set Size	Total accessible address space allocated to the process, including mapped files and unallocated memory. Rarely reflects actual RAM usage.
RSS	Resident Set Size	Total physical RAM currently held by the process. Crucially, it double-counts shared libraries used by multiple processes.
PSS	Proportional Set Size	The true memory cost of a process. It includes private memory plus a divided share of all shared libraries (e.g. if 4 processes share a 4MB library, each process is charged 1MB).
USS	Unique Set Size	Strictly private memory belonging exclusively to that process. This is the exact amount of RAM that would be freed immediately if the process were terminated.

When assessing how much RAM will be recovered by killing a stuck worker process, look directly at USS. When calculating the ongoing footprint of persistent background daemons, look at PSS.

Installing smem on Linux

The smem package is written in Python and is readily available in standard package managers across all major distributions.

On Debian, Ubuntu, and Linux Mint

sudo apt update && sudo apt install -y smem

On Fedora, RHEL, and Rocky Linux

sudo dnf install -y epel-release && sudo dnf install -y smem

On Arch Linux and Manjaro

sudo pacman -S smem

Note: Because reading complete memory maps across all system processes from /proc/[pid]/smaps requires administrative read rights, running smem with sudo is recommended for full accuracy.

Basic smem Commands and Practical Examples

1. Listing Process Memory Usage in Human-Readable Format

By default, smem displays raw memory amounts in kilobytes. Pass the -k (kilobytes/megabytes/gigabytes) or -m (megabytes) flags to format numbers cleanly:

sudo smem -k

This command prints a table listing Process ID (PID), User, Command Name, Swap, USS, PSS, and RSS. Processes are automatically sorted from lowest memory footprint to highest, meaning the largest memory consumers appear directly at the bottom of your terminal.

2. Sorting Processes by Highest PSS Footprint

To sort output explicitly by PSS (the most realistic memory metric), use the -s sorting flag:

sudo smem -k -s pss -r | head -n 20

The -r flag reverses the sort order so the heaviest processes appear at the top, while head -n 20 limits terminal output to the top twenty culprits.

3. Aggregating Memory Usage by User

If you run a multi-tenant development server or shell host, you can determine how much physical RAM each user account is actually consuming:

sudo smem -u -k

This aggregates all individual child processes into concise per-user PSS and USS totals.

4. Aggregating Memory Usage by Application Mapping

To see total memory consumed across all instances of an application (such as all child workers of Nginx, Apache, or Python):

sudo smem -m -k

Filtering Memory Usage for Specific Processes

To isolate a particular service without wading through hundreds of system threads, pass a regular expression filter with the -P switch:

sudo smem -k -P "chrome|firefox"

This provides an instant, side-by-side comparison of private (USS) and shared (PSS) memory utilised across all running web browser processes.

Generating Visual Graphical Memory Charts

If you have installed Python’s matplotlib library on your system (sudo apt install python3-matplotlib), smem can generate pie charts and bar graphs directly:

Generate a Pie Chart of PSS Usage

sudo smem --pie=command -s pss

Generate a Bar Chart Comparing USS and PSS

sudo smem --bar=command -c "uss pss" -s pss

A window will open rendering high-resolution charts that clearly visualise which services dominate your server’s physical memory capacity.

Troubleshooting Common smem Pitfalls

• Permission Denied on /proc/PID/smaps: If you run smem without root privileges, it can only inspect your own processes, which results in incomplete system totals. Always run with sudo when performing whole-system memory audits.
• High Swap Numbers: If smem reveals substantial Swap usage alongside a low USS, the Linux kernel has paged inactive application code to disk to free RAM for filesystem caches. This is normal unless accompanied by high I/O wait times.

Using smem equips you with pinpoint visibility into proportional and unique memory footprints, making it vastly superior to legacy memory monitors for identifying memory leaks and tuning Linux server workloads.