Tips for Optimizing Linux Memory Usage
Like most Unix-compatible operating systems, the single most important factor in determining the performance you get out of Linux is often the amount of physical memory available. This is often a source of confusion to users accustomed to other systems such as MS-DOS. Since many Linux users are on a tight budget, the option of simply purchasing more memory is not always feasible. This article presents some ways in which you can make better use of the memory you already have.
Linux implements a demand-paged virtual memory system. Processes have a large (4 gigabyte) virtual memory space. As virtual memory is referenced, the appropriate pages are transferred between disk and physical memory.
When there are no more physical memory pages available, the kernel swaps some older pages back to disk. (If they are code pages that have not been changed, then they are just discarded; otherwise they are written to the swap areas.)
Disk drives are mechanical devices; reading and writing to disk is several orders of magnitude slower than accessing physical memory. If the total memory pages required significantly exceed the physical memory available, the kernel starts spending more time swapping pages than executing code. The system begins thrashing, and slows down to a crawl. If this increases to a point where the swap device becomes fully utilized, the system can virtually come to a standstill. This is definitely a situation we want to avoid.
When extra physical memory is not in use, the kernel attempts to put it to work as a disk buffer cache. The disk buffer stores recently accessed disk data in memory; if the same data is needed again it can be quickly retrieved from the cache, improving performance. The buffer grows and shrinks dynamically to use the memory available, although priority is given to using the memory for paging. Thus, all the memory you have is put to good use.
In order to know what your memory situation is and whether any changes you make are resulting in improvement, you need to have some way of measuring memory usage. What tools do we have at our disposal?
When the system first boots, the ROM BIOS typically performs a memory test. You can use this to identify how much physical memory is installed (and working) in your system, if you don't know already. On my system, it looks something like this:
ROM BIOS (C) 1990 008192 KB OK WAIT......
The next piece of useful information is displayed during the Linux boot process. Output such as the following should be displayed:
Memory: 7100k/8192k available (464k kernel code, 384k reserved, 244k data) ... Adding Swap: 19464k swap-space
This shows the amount of RAM available after the kernel has been loaded into memory (in this case 7100K out of the original 8192K). You can also see if the swap space has been properly enabled. If the kernel bootup messages scroll by too quickly to read, on many systems you can recall them at a later time using the “dmesg” command.
Once Linux is running, the “free” command is useful for showing the total memory available (which should match that shown during boot-up), as well as a breakdown showing the amount of memory being used, and the amount free. (If you don't have a “free” command, you can use “cat /proc/meminfo”.) Both physical memory and swap space is shown. Here is a typical output on my system:
Here is a typical output on my system:
The information is shown in kilobytes (1024 bytes). The “total” memory is the amount available after loading the kernel. Any memory being used for processes or disk buffering is listed as “used.” Memory that is currently unused is listed in the “free” column. Note that the total memory is equal to the sum of the “used” and “free” columns.
The memory indicated as “shared” is an indication of how much memory is common to more than one process. A program such as the shell typically has more than one instance running. The executable code is read-only and can be shared by all processes running the shell.
The “buffers” entry indicates how much of the memory in use is currently being used for disk buffering.
The “free” command also shows very clearly whether the swap space is enabled, and how much swapping is going on.
To better understand how the kernel uses memory, it is instructive to watch the output of the “free” command as the system is used. I'll show some examples taken from my own system; I suggest you try similar experimentation yourself.
On bootup, with one user logged in, my system reports the following:
total used free shared buffers Mem: 7096 2672 4424 1388 1136 Swap: 19464 0 19464
Note that we have considerable free memory (4.4MB) and a relatively small disk buffer (1.1MB). Now watch how the situation changes after running a command that reads data from the disk. (In this case I typed ls -lR /.)
total used free shared buffers Mem: 7096 5104 1992 1396 3460 Swap: 19464 0 19464
We see that the disk buffer has grown by over 2 MB. This brings the “used” memory up correspondingly, and the free memory down. Next, I start up the X Window system and examine the results:
total used free shared buffers Mem: 7096 7016 80 3112 3792 Swap: 19464 8 19456
This has caused the memory used to increase to 7MB, leaving only 80K free. The increase is to support the additional processes running (the X server, window manager, xterm, etc...). Note that the disk buffer didn't shrink, because there is still free memory. Remember: “free” memory means memory that is being wasted.
Now I start up the GNU chess program, having it play against itself. This starts two instances of a rather large program:
total used free shared buffers Mem: 7096 7016 80 1080 860 Swap: 19464 5028 14436
We see now that the disk buffer has shrunk down to less than 1MB and we are 5MB into swap to accommodate the large processes. Because of the swapping, the system has slowed down, and heavy disk drive activity can be heard. There is still a small amount of free memory. (The kernel tries to prevent user processes from taking all of the available memory; it reserves some for the “root” user only.)
The next step is to exit the X Window system and the applications running under it; here is the result.
total used free shared buffers Mem: 7096 2444 4652 412 1480 Swap: 19464 728 18736
We now have lots of free memory, the swap usage is almost gone (some idle programs are still presumably swapped out), and the disk buffer is starting to grow again.
The “top” and “ps” commands are also very useful for showing how memory usage changes dynamically, and how individual processes are using memory. For the scenario described earlier, we can see from the output of “ps” that each of the two chess processes was taking almost 8MB of virtual memory, obviously more than could fit in physical memory, causing the system to thrash.
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND ... tranter 282 4.1 34.4 7859 2448 v01 D 14:08 0:11 gnuchessx 40 5 tranter 285 7.9 30.7 7859 2180 v01 D 14:09 0:21 gnuchessx 40 5 ...
Another facility for getting system status information is built into the virtual console driver. This depends on your keyboard mapping, but the default for the US keyboard is to use the Scroll-Lock key. Pressing <Alt><Scroll Lock> shows the current value of the CPU registers. The <Shift><Scroll Lock> combination shows memory information, similar to the “free” command, but more detailed. Finally, <Ctrl><Scroll Lock> will give information on individual processes, much like the “ps” command.
These keys can be particularly handy if your system is slow, or appears to have crashed. Note that if you are running the syslog daemon, this information will probably be logged to a file instead of being displayed on the console. On my Slackware system for example, it is logged to the file /var/adm/syslog.
- You have to be careful there
7 weeks 5 days ago
- Wonder when LJ is going to
7 weeks 6 days ago
- Puerto Rico Free Software
8 weeks 3 hours ago
8 weeks 1 day ago
- I hate voice commands
8 weeks 1 day ago
- usabilty --- AGAIN with this nonsense
8 weeks 2 days ago
- Don't make excuses
8 weeks 2 days ago
- Sorry to let you know, but
8 weeks 2 days ago
- Ridiculous statement. Not a
8 weeks 3 days ago
8 weeks 3 days ago