Linux Memory Usage
Understanding Linux memory usage and how to check for used and free memory or RAM in Linux can be difficult. But once you learn about the Linux page cache and how to read the status of it, it's really quite simple.
Linux very efficiently caches frequently used files from the hard drive, to very fast to access RAM on the server. Data is stored electronically in RAM, so its speed is not limited by physical magnetic heads or spindle motors.
In this guide I'll go over Linux free memory, and how to properly read Linux memory info.
Linux free -m
The most common way you'll see on the web to check for free memory in Linux is by using the free command.
Using the free -m command to check your Linux memory usage, displays the values as MB instead of KB.
Most people will run this command and panic thinking they only haveof free memory on the server:
root@server [~]# free -m total used free shared buffers cached Mem: 1024 0 0 822 -/+ buffers/cache: Swap: 0 0 0
The free column beside -/+ buffers/cache withis the actual free memory available to Linux.
1024 MB is the total system memory available, which would be physical RAM.
and both show free because an application has access to both for memory storage.
822 MB cached gives the of memory actually free to use if needed.free plus the
Linux page cache
Linux uses something called a page cache in order to cache frequently hit files from the hard drive into memory.
There is an awesome helpful tool called vmtouch which allows you to directly interact with the Linux page cache. Below I'm using this to check if any parts of a 100 MB log file called access_log are in the page cache already:
root@server [~]# vmtouch -v /home/access_log /home/access_log [ ] 0/25642 Files: 1 Directories: 0 Resident Pages: 0/25642 0/100M 0% Elapsed: 0.000568 seconds
You can see that 0/25642 of all resident pages that make up this file are in the page cache.
This is also represented as 0/100 MB worth of that file's data, or 0%.
Here I'm using the time command to show how long a grep search takes initially:
root@server [~]# time grep wp-login.php access_log -c 702754 real 0m30.056s user 0m0.192s sys 0m0.082s
It took 30.056 seconds to read that file from the hard drive, let's see if any of it made it to the page cache:
root@server [~]# vmtouch -v /home/access_log /home/access_log [OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO] 25642/25642 Files: 1 Directories: 0 Resident Pages: 25642/25642 100M/100M 100% Elapsed: 0.003133 seconds
All 25642/25642 resident pages are in the page cache now, and all 100 MB worth of data, or 100%.
We know the whole access_log file is in memory, let's see what happens when we try to search in the file again:
root@server [~]# time grep wp-admin access_log -c 103161 real 0m0.168s user 0m0.137s sys 0m0.030s
It took 30.056 seconds reading the file from disk, down to just 0.168 seconds reading it from RAM.
That's over a 17,000% speed increase! This is why I say that Linux uses memory very efficiently.
The same thing applies to your applications and scripts that run on the server. Linux will try to move them to the page cache for quicker access. If another application needs more memory, it can simply take it back.
This throws a lot of people off because they see Linux is using a lot of memory, while in reality it's using it to speed things along while the full memory available to the server isn't actively needed for running applications.
Linux sar -r
If you wanted to take a look at your Linux memory usage historically then the Linux sar command is a great tool which uses System Activity Report logs to pull historical usage data from your server:
root@server [~]# sar -r 10:06:01 PM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit 10:06:01 PM 688956 359620 34.30 0 142912 0 0.00 10:16:01 PM 688792 359784 34.31 0 143000 0 0.00 10:26:01 PM 678744 369832 35.27 0 152968 0 0.00 10:36:01 PM 678052 370524 35.34 0 153516 0 0.00 10:46:01 PM 677532 371044 35.39 0 154024 0 0.00 10:56:01 PM 676688 371888 35.47 0 154036 0 0.00 11:06:01 PM 676160 372416 35.52 0 154216 0 0.00 11:16:01 PM 3644 1044932 99.65 0 60588 0 0.00 Average: 682327 366249 34.93 0 113811 0 0.00
The kbmemfree column shows how much memory was free.
The kbmemused column shows how much memory was used.
The %memused column shows how much memory was used as a percentage of total memory available.
The kbcached column shows how much memory was cached.
The command below goes through your sar logs and shows anytime that your server's memory is spiking.
When kbmemused is over 917504 KB or 896 MB, and kbcached is under 131072 KB or 128MB this command will output the memory usage stats from sar.
Doing it this way we can ensure that we're only looking at times when our actual free memory on the server has dipped below 128MB. That way we don't start panicking when the server says 99% of memory is being used, but in reality that memory is being used by the Linux page cache.
Here is the output from the above command:
/var/log/sa/sa06 --------------kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit 12:16:01 AM 25208 1023368 97.60 0 37536 0 0.00 12:26:01 AM 23708 1024868 97.74 0 38792 0 0.00 12:36:01 AM 13532 1035044 98.71 0 41756 0 0.00
With Linux there is a /proc pseudo-file system that doesn't contain any real phyical files, but does allow you to take a peak at how the Linux kernel is controlling the system via various config files.
One of these is called /proc/meminfo and this is where commands like free get their data from. You can directly look at these values yourself by simply accessing this pseudo-file:
root@server [~]# egrep "MemTotal|MemFree|Cached" /proc/meminfo MemTotal: 1048576 kB MemFree: 842752 kB Cached: 841728 kB
The VPS I'm looking at has 1048576 kB of total system memory, which is 1024 MB, or 1 GB of RAM.
Of that total available memory on the VPS, 842752 kB or 823 MB of that RAM is not in use, or free to use.
There is 841728 kB or 822 MB of memory currently being used by the Linux page cache to speed things up.
I know from the earlier testing I did, that 100 MB worth of that page cache usage is from my 100 MB log file that got placed in the page cache for quick access.