Understanding memory information on Linux systems
Every operating system needs memory to store program code segments and data. This is also true for Linux systems. The problem: there is a lot of information available regarding memory usage and its behavior. Let’s discover how Linux manages its memory and how we can gather memory information.
After reading this guide, you will be able to:
- Show the total amount of memory
- Display all memory details
- Understand the details listed in /proc/meminfo
- Use tools like dmesg, dmidecode, free, and vmstat
Table of Contents
Linux memory information
Random access memory
When we talk about memory in this article, we usually mean random access memory (RAM). This is the memory which can be used for both showing and storing data. Typically we will find in this type of memory the programs that are running on the system, including the Linux kernel itself. Besides the program code, memory also stores a lot of data. A good example is when you are running a MySQL database server. The program itself is relatively small, the data itself is huge. So we will also have a look at tuning programs and their memory usage, as this is typically a problem with memory-hungry programs.
Determine the amount of RAM
The first step is to discover the amount of RAM we have in the system. There are a few ways on how to achieve this, starting from the data stored in
dmesg | grep -in mem
The output may look something like this:
This information shows the number of memory available in kilobytes. The first value shows what is currently available, the second value displays the total memory in the system. These values are usually very close. This indicates that most of the memory can be used and is a good thing. The small portion “missing” is used by the initial loading of the kernel. If there is a big gap, then this might be caused by the kernel and how many memory it can allocate. Especially with 32 bits versions of Linux, this number is limited.
Details and information about RAM modules
The next step is learning more about the RAM modules itself. You will need the
dmidecode utility for this, which is available for most Linux distributions. To gather memory information, tell the dmidecode to only show information for device type 17.
dmidecode --type 17
Depending on your hardware it may be able to extract the specifics of your modules and show detailed information. You may need to run this as root user. Normal users won’t have the right permissions to read all information.
In this output above you can see the details of the first memory module. We see it is a chip of 4 GB and configured at a 1600 MHz speed. This is a great way to determine the memory available in a Linux system, together with detailed output. Unfortunately, the command does not always play well with virtual systems.
Let’s move on to the next set of utilities and gather details regarding memory usage.
After the Linux kernel is booted, it is time to start programs. The kernel itself is not responsible for the programs. Instead, it delegates this responsibility to a service manager like init or systemd. This process is the first to be started and will get process ID 1. Its duty is to start other services and programs during the lifetime of the system. Each program will consume some amount of memory, depending on the program size and the related data. Let’s have a look at some ways to see available memory on Linux and retrieving related details.
See available memory with free command
The first command to obtain available memory information is the perfectly named tool
This utility shows two different types of memory: normal memory and swap memory. Swap is a type of memory that you want to avoid needing as much as possible. If it would be used, then it means your normal memory is full. The system will then leverage the swap memory to temporarily store data, at the cost of disk operations. As they are much slower than normal RAM, your system will be impacted. In this screenshot, we see the swap is not used, which is good.
The free utility retrieves this memory information from a file named /proc/meminfo. Let’s have a look at that as well.
Details from /proc/meminfo
The next step to obtain everything available regarding memory is found in the procfs tree, usually mounted under /proc. This file is very extensive, so have a look at it on your system:
Memory management under Linux is extensive and changed over time to what it is now. This results in a delicate system that optimizes memory usage as much as possible. Let’s get into some of these fields and understand better how Linux does its job.
The system does a lot of repetition, including reading the same files or data. Everything that goes into memory and is no longer needed, will be kept for a little bit longer. If you then request the same data while it is in memory, you will get it almost instantly. This is what happens when you run a find command on a particular directory the first time, which usually takes a while. Run it again and it will be much quicker.
A page cache optimizes access to files. These buffers can be recently used (=active), or not (=inactive).
Active is the total of Active(anon) and Active(file). Similarly, Inactive is the total of Inactive(anon) + Inactive(file).
These provide insights in the configured swap memory and how much is left. Ideally, the SwapFree value is equal to SwapTotal, meaning no swap is in use at that time. Swapping is disk intensive.
The Dirty field refers to data that is stored in memory and still needs to be written to the disk.
You can test this easily by writing to a temporary file and compare the value before and after.
cat /proc/meminfo | grep Dirty && dd if=/dev/zero of=/tmp/testfile.txt bs=1M count=10 && cat /proc/meminfo | grep Dirty
Note: if you repeat this command, you will see the effect of smart memory management. In that case, the value before and after will most likely be the same, as some data was cached and directly returned as a finished action. You can counter this by retrieving random data from /dev/random.
Slab, SReclaimable, SUnreclaim
The kernel does a lot of repetition during the time it is running. Some objects, like asking for the specific inode of a file may be performed thousand times a day. In such case, it would be wise to store it in a quick reference list, or cache. Slab is the combination of caches for kernel objects, to optimize those activities that happen the most.
The Slab field is the total of SReclaimable and SUnreclaim.
Slab: 32272 kB
SReclaimable: 18144 kB
SUnreclaim: 14128 kB
For systems that use NFS this is a good measurement to see how much data is not committed to the storage yet. For systems without NFS, this value can be ignored and is usually just zero.
If you compared these fields with your own system, you will discover there are more fields. Depending on your workload, you will have to discover what fields make sense to monitor. What does generally work well during troubleshooting, is comparing similar systems and check for the differences in /proc/meminfo. It may give a good indication of where memory is used and what keeps the system busy.
Using vmstat utility
Another nice utility that is often available is vmstat. With
-s we can query memory statistics.
We can also query the previous mentioned slabs.
Monitoring memory usage in Linux
If you have a monitoring system in place, then two key attributes from /proc/meminfo should be monitored.
By monitoring these two values you may discover memory leaks and badly optimized systems. You may also pick up on a misbehaving process now and then.
For environments that have many similar systems with a typical workload (e.g. lots of web servers doing the same), then it would make sense to monitor more of the keys in /proc/meminfo. Storing the data a few times per day may give you the ability to compare systems and find exceptional events.
Frequently Asked Questions
How can I find out the total physical memory (RAM)?
Use the free command to show the total amount of memory and how it is assigned.
What Linux tool can I use to see the details of the memory modules?
Use the hwinfo tool to gather details regarding the memory. If that is not available, then consider using the output from dmesg.
How can I see which processes consume the most memory?
Use the ps command to show memory usage and do a reverse sort.
ps -e -orss=,args= | sort -nr | head
Why are the buffer and cache use so much memory on Linux?
Linux considers unused memory to be wasted memory. So it will use as much memory as possible to speed up the performance on the system. The related caches and buffers contain typically data related to the file system. That is also why a second run of the find command in the same directory runs much quicker. The kernel will reassign memory to processes when needed.
Where does the kernel store the details regarding virtual memory management?
Most of the related settings, like how to act during an Out-of-Memory event, will be stored in /proc/sys/vm.
Linux memory management is an extensive subject and there is a lot to learn. Make sure to understand the basics, like how to obtain memory information, including that of RAM and swap. This is of great help during troubleshooting and to know what programs need to do their job.
Did you learn something from this article? Great! Share it on your favorite website or with others. If you have a nice tool for memory analysis or got a question, you are welcome to use the comments!
Big thanks for you has helped fixed my task from college
You are very welcome!
MemFree is fairly unimportant for monitoring. It will always settle towards a small amount as the page cache is filled with disk data. What you’re really looking for is MemAvailable, this is what the kernel thinks it could free up for application memory by throwing out buffers and cache.
Note, MemAvailable is only available in kernels 3.14 and newer. Previous to that you need to use a calculation of MemFree + Buffers + Cache.
It’s also worth noting that a useful metric for monitoring memory pressure is “pgmajfault” from /proc/vmstat. If this counter is increasing at a high rate and you have low MemAvailable, you are probably running low on memory. Major Page Faults are part of the page cache system that indicate that an application binary page needed to be mmaped into memory in order to execute. This is normal, as it happens every time you execute a new binary, but if it’s happening continuously it’s likely that the kernel is having to throw out page cache to run some code, but then has to immediately pull the application binary back into memory to execute something else.
I wrote some rules for Prometheus to monitor exactly this condition:
Can we read the complete data of RAM? Something like reading the values of variables and registers using a debugger. If yes, then how?
I would like to understand a bit more. This description is a very good start, to understand what an application does on the server. Basically, what I want to check is, what a process consumes over a period of time. How is that doable? What kind of data can be used from /proc/PID/==> statm ==> status ==> smaps ==>? Or what does pmap bring us as well?
When I have more than one process doing work for my application, how is shared memory spead? How is it then to be calculated, to say at the end, how much memory was consumed over a period of time? Lets say, you do an NFR (Non Function Requirement) Test, where you run massive load to see the behaviour of the application – which values are consumed there?
Is there a way to be able to calculate this exactly? Or is that not possible to say?