Staying on Top of Your Memory Usage in Linux
Many people notice that after using a computer for a long period of time, that their system might start to slow down; programs open up or respond slower, web browsers seem sluggish, and the computer seems to all but slow to a crawl. Experienced users will recognize that this occurrence is due to limited free memory or RAM on the system. This article is intended to help both novice and experienced users stay on top of their ram consumption in Linux.
Getting the right monitor
The first step in this process is making sure that you get the right information when you check your amount of free ram. Most Linux programs report the amount of absolute free memory on the system. For example, when I run the command free, I get the following:
kain@slickbox:~> free -m total used free shared buffers cached Mem: 1010 957 53 0 107 587 -/+ buffers/cache: 261 748 Swap: 1521 0 1521 kain@slickbox:~>
According to this, I only have 53 megabytes free on a 1 GB of memory system! What actually is happening here is that Linux has cleverly used my free memory to cache the system disk and speed up the system. However, as application needs arise, this memory will be re-allocated to those applications. So in reality, the memory really is “free” for use. The KDE info center’s memory module shows this graphically:
KInfoCenter’s Memory Module
Note the physical memory in the middle and in the green regions which represent data that is not being used by applications.
So what we really want to see is the how much memory is being used by applications. There happens to be a nice Linux utility called gkrellm which will report this to us graphically.
A screenshot of gkrellm can be seen on the left. Obviously, its useful for monitoring more than just system memory.
Note that when enabled, gkrellm displays the amount of “free” memory in the “mem” meter. The filled portion of the bar represents the amount of application memory in use by the system. So as the bar fills up, so does your memory.
On a typical Linux setup, users will notice performance degradation in their applications when their system exceeds roughly 40-50% of its ram consumption. This is because at this point, the system starts using sluggish swap space (space preallocated on the hard disk) to store program memory instead of the much faster RAM. This can be seen graphically in gkrellm by monitoring the filled portion of the “swap” meter which is located directly underneath of the memory one. In addition to degrading system responsiveness, the use of swap space can greatly affect battery life of laptops as well due to the amount of power it takes to access the hard drives on the system.
The fact that Linux starts using swap space when any physical memory is left at all may seem very counter-intuitive to most users (as it did to myself at first). Linux, being a server-oriented operating system, is by default tuned to deliver high performance to background applications at the expense of foreground applications. This means that your word processor, mp3 player, kde desktop manager, doom3 video game, and any other “foreground” application will start to be swapped out at the earliest sign of rising memory consumption so that the system background services can run smoothly. For the average desktop user, this is almost always not what you want. Short of turning swap space completely off (which is not recommended), Linux allows us the ability to fine-tune the likelihood of swap space being used at all.
To check the swappiness value on your system, run the following command on the terminal.
kain@slickbox:~> cat /proc/sys/vm/swappiness 60 kain@slickbox:~>
The value of 60 is often the default on SuSE Linux systems. This value ranges from 0 (less likely to swap) to 100 (very likely to swap). I notice that by setting it to 10, the system uses much less swap memory than before.
kain@slickbox:~> su Password: slickbox:/home/kain # echo "10" > /proc/sys/vm/swappiness slickbox:/home/kain # cat /proc/sys/vm/swappiness 10 slickbox:/home/kain #
The above code will set the value temporarily. To set it permanently so that it takes effect on each boot, edit the /etc/sysctl.conf file and add the line:
I’m sure we’re all familiar with the term “runaway process”. If not, I’m simply referring to a process that gets caught up in an infinite series of computation such that it never lets your cpu rest. In the gkrellm tool mentioned above, this can be seen as a 100% usage on the cpu chart and an overall system slowdown. However, its not as easy to detect when a program runs away with your memory (unless it is drastic). Many buggy programs leak memory over time, and if they aren’t properly killed, this can add up. This is especially true if you leave your Linux system running for days or months at a time.
The easiest tool I’ve found for monitoring process ram consumption is KDE’s process manager (named ksysguard). To bring up ksysguard, hit Ctrl+Esc on your keyboard while in the KDE environment. You should see something similar to the window below.
You’ll be presented with a chart of the various processes that are running on your system. Pay attention to the “VmRss” column. This is the amount of memory in bytes that each process has resident in memory. Reverse sorting by this column (clicking the column header until a tiny up arrow appears inside of it) will show you the current “high bidder” of your ram. If your ram usage seems unusually high, your ram-thief culprit will likely be at the top of this chart.
Here is my system process table again, this time sorted by ram usage.
As you can see from my system state, soffice.bin (OpenOffice) is the program that is using most of my ram (roughly 92 megabytes). If something was wrong here, the highest number would be considerably larger than this and may even refer to an application that “closed” a long time ago. If you have already tried all the graceful means of quitting the offending application, or if it has no more windows open, click the application row and then the “kill” button to kill the app. If it still remains, right click the process and send the SIGKILL signal to it to force it to quit. It’s important to remember that if you are not the owner of the process, you cannot kill it without root privileges in which special care should be taken to fix the problem.
As a final note, if the offending process listed is Xorg, and it has consumed quite a bit of memory, this means that the graphical X system needs to be restarted to reclaim the memory. You can achieve this by logging out and back into your system.