{"id":3075,"date":"2022-01-17T14:28:06","date_gmt":"2022-01-17T14:28:06","guid":{"rendered":"https:\/\/mailinvest.blog\/index.php\/2022\/01\/17\/easily-understand-your-linux-ram-usage-with-smem\/"},"modified":"2022-01-17T14:28:06","modified_gmt":"2022-01-17T14:28:06","slug":"easily-understand-your-linux-ram-usage-with-smem","status":"publish","type":"post","link":"https:\/\/mailinvest.blog\/index.php\/2022\/01\/17\/easily-understand-your-linux-ram-usage-with-smem\/","title":{"rendered":"Easily Understand Your Linux RAM Usage With Smem"},"content":{"rendered":"

<\/a>\n<\/p>\n

\n
\"Laptop
fatmawati achmad zaenuri\/Shutterstock<\/a><\/span><\/figcaption><\/figure>\n

Linux memory usage can be difficult to interpret and hard to understand. With smem<\/code> it\u2019s easy to find out what memory a process is using, and which processes are using the most.<\/p>\n

Memory Usage<\/h2>\n

Linux gives you many ways to check what\u2019s happening with your computer\u2019s RAM<\/a>. 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<\/a>, and the demands of the different types of processes<\/a> that are running at any one time.<\/p>\n

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\u2019re designed to do. Some processes hardly impact RAM, others are very memory-hungry.<\/p>\n

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.<\/p>\n

Trying to decipher all of this and to come up with a simple answer to the question \u201cHow much RAM is this program or process using?\u201d can be a surprising challenge. Granularity is great and has its place but, equally, information overkill can be an impediment.<\/p>\n

For example, using\u00a0cat<\/code> to peek into the\u00a0\/proc\/meminfo pseudo filesystem<\/a>\u00a0returned 50 lines of output on the machine used to research this article. Where do you start?<\/p>\n

cat \/proc\/meminfo<\/pre>\n
And some Linux utilities give different answers. On our test machine, we had an instance of less<\/code><\/a> running, which had a process ID of 2183.<\/p>\n
We can use the pmap<\/code> utility with the -x<\/code> (extended) option to get a full picture of the memory usage of a process. We\u2019ll use it with the process ID of our instance of less<\/code>:<\/p>\n
pmap -x 2183<\/pre>\n
\"Querying<\/p>\n
At the bottom of the output, we get a total for the Resident Set Size, which is the amount of main RAM being used.<\/p>\n
\"The<\/p>\n
We then used the ps<\/code> utility with the -o<\/code> (output) option, selected the RSS<\/code> column, and passed it the process ID of the same instance of less<\/code>:<\/p>\n
ps -o rss 2183<\/pre>\n
\"Using<\/p>\n
We get a different result. This is a design decision on the part of the ps<\/code> authors. This is from the ps<\/code> man<\/code> page:<\/p>\n
The SIZE and RSS fields don\u2019t count some parts of a process including the page tables, kernel stack, struct thread_info, and struct task_struct. This is usually at least 20 KiB of memory that is always resident. SIZE is the virtual size of the process (code+data+stack).<\/p>\n
The authors of other utilities have their own views on how to measure RAM usage.<\/p>\n
The RSS, the USS, and the PSS<\/h2>\n
The Resident Set Size (RSS) is the amount of RAM<\/a> allocated to a process, excluding swap space, but including any RAM required by shared libraries that the process is using.<\/p>\n
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\u2019s a certain irony to this. Shared libraries mean each process doesn\u2019t need to load its own private instance of a library. If the library is already in memory it\u2019ll share that one\u2014and reduce the RAM overhead.<\/p>\n
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\u2019s going on than the picture that RSS paints.<\/p>\n
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\u2019s only interested in genuine, physical RAM.<\/p>\n
USS and PSS are terms and concepts that were\u00a0proposed by Matt Mackall<\/a>, the author of smem<\/code>.<\/p>\n
The smem Utility<\/h2>\n
The smem<\/code> utility reports on memory used by processes, users, mapping, or system-wide. On all\u00a0distributions<\/a> we tested, it required installing. To install it on Ubuntu, use this command:<\/p>\n
sudo apt install smem<\/pre>\n
\"Installing<\/p>\n
To install smem<\/code> on Fedora you need to type:<\/p>\n
sudo dnf install smem<\/pre>\n
\"Installing<\/p>\n
To install smem<\/code> on Manjaro use:<\/p>\n
sudo pacman -Sy smem<\/pre>\n
\"Installing<\/p>\n
Using smem<\/code> with no options gives you a list of the processes that are using RAM.<\/p>\n
smem<\/pre>\n
\"Invoking<\/p>\n
A table of information is displayed in the terminal window.<\/p>\n
\"The<\/p>\n
The columns are:<\/p>\n