Ubuntu Server 18.04 – Monitoring memory usage

How to use the Docker Compose command

Understanding how Linux manages memory can actually be a somewhat complex topic, as understanding how much memory is truly free can be a small hurdle for newcomers to overcome. You’ll soon see that how Linux manages memory on your server is actually fairly straightforward. For the purpose of monitoring memory usage on our server, we have the free command at our disposal, which we can use to see how much memory is being consumed at any given time. My favorite variation of this command is free -m, which shows the amount of memory in use in terms of megabytes. You can also use free -g to show the output in terms of gigabytes, but the output won’t be precise enough on most servers. Giving the free command no option will result in the output being shown in terms of kilobytes:

Output of the free command

In my opinion, adding the -m option makes the free command much more readable:

free -m
Output of the free -m command

Since everything is broken down into megabytes, it’s much easier to read, at least for me.

To follow along, refer to the previous screenshot, and I will explain how to interpret the results of the free command.

At first glance, it may appear as though this server has only 205 MB free. You’ll see this in the first row and third column under free. In actuality, the number you’ll really want to pay attention to is the number under available, which is 392 MB in this case. That’s now much memory is actually free. Since this server has 481 MB of total RAM available (you’ll see this on the first row, under total), this means that most of the RAM is free, and this server is not really working that hard at all.

Some additional explanation is necessary to truly understand these numbers. You could very well stop reading this section right now as long as you take away from it that the available column represents how much memory is free for your applications to use. However, it’s not quite that simple. Technically, when you look at the output, the server really does have 205 MB free. The amount of memory listed under available is legitimately being used by the system in the form of a cache but would be freed up in the event that any application needed to use it. If an application starts and needs a decent chunk of memory in order to run, the kernel will provide it with some memory from this cache if it needed it.

Linux, like most modern systems, subscribes to the belief that “unused RAM is wasted RAM.” RAM that isn’t being used by any process is given to what is known as a disk cache, which is utilized to make your server run more efficiently. When data needs to be written to a storage device, it’s not directly written right away. Instead, this data is written to the disk cache (a portion of RAM that’s set aside), and then synchronized to the storage device later in the background. The reason this makes your server more efficient is that this data being stored in RAM would be written to and retrieved faster than it would be from disk. Applications and services can synchronize data to the disk in the background without forcing you to wait for it. This cache also works for reading data, as when you first open a file, its contents are cached. The system will then retrieve it from RAM if you read the same file again, which is more efficient. If you just recently saved a new file and retrieve it right away, it’s likely still in the cache and then retrieved from there, rather than from the disk directly.

To understand all of these columns, I’ll outline the meaning of each in the following table:




The total amount of RAM installed on the server.


Memory that is used (from any source). This is calculated as follows:
total – free – buffers – cache.


Memory not being used by anything, cache or otherwise.


Memory used by tmpfs.


The amount of memory being used by the buffers and cache.


Memory that is free for applications to use.


How much Swap is being used is something you should definitely keep an eye on. When memory starts to get full, the server will start to utilize the swap file that was created during installation. It’s normal for a small portion of swap to be utilized even when the majority of the RAM is free. But if a decent chunk of Swap is being used, it should be investigated (perhaps a process is using a larger than normal amount of memory).

You can actually control at which point your server will begin to utilize Swap. How frequently a Linux server utilizes swap is referred to as its swappiness. By default, the swappiness value on a Linux server is typically set to 60. You can verify this with the following command:

cat /proc/sys/vm/swappiness 

The higher the swappiness value, the more likely your server will utilize swap. If the swappiness value is set to 100, your server will use swap as much as possible. If you set it to 0, swap will never be used at all. This value correlates roughly to the percentage of RAM being used. For example, if you set swappiness to 20, swap will be used when RAM becomes (roughly) 80 percent full. If you set it to 50, swap will start being used when half your RAM is being used, and so on.

To change this value on the fly, you can execute the following command:

sudo sysctl vm.swappiness=30 

This method doesn’t set swappiness permanently, however. When you execute that command, swappiness will immediately be set to the new value and your server will act accordingly. Once you reboot, though, the swappiness value will revert back to the default. To make the change permanent, open the following file with your text editor:


A line in that file corresponding to swappiness will typically not be included by default, but you can add it manually. To do so, add a line such as the following to the end of the file and save it:

vm.swappiness = 30 

Changing this value is one of many techniques within the realm of performance tuning. While the default value of 60 is probably fine for most, there may be a situation where you’re running a performance-minded application and can’t afford to have it swap any more than it absolutely has to. In such a situation, you would try different values for swappiness and use whichever one works best during your performance tests.

Comments are closed.