I'm sure this is a pretty basic question, but I'm just trying to get a grasp of what's going on with my Ubuntu Hardy server running a Rails-based site. It seems that I have free memory available, yet the system is reporting that it is still swapping memory (unless I'm reading this incorrectly?).

Here is the free -m output

              total       used       free     shared    buffers     cached
Mem:          1024        905        118          0         33        409
-/+ buffers/cache:        462        561
Swap:         2047         95       1952

Could anyone explain to me some possible reasons that it is maintaining 95MB of swap at all times (it is never less)? I'm just looking for some leads on things I could check out that would explain to me exactly how memory is utilized in Linux.


I was in training in a class taught by Ted Ts'o, and the way he explained it to me when I asked the same question was like this...

By default, the kernel reserves most of the memory for caching things like filesystem metadata. That's why your "used" column shows 905MB. That's the total memory that's "used", meaning by programs and by cache. The actual amount of free memory is under the "free" column, beside "-/+ buffers/cache", in other words, 561MB. That's the amount available for use by programs.

Now, since the kernel has 462MB used for cache, it's leaving 118MB completely available. When a program says to the kernel, "hey, I need 50MB of memory RIGHT NOW!", the kernel draws the memory from this "free" pool. That makes the "free" pool at around 68MB, which is too small for comfort, so after that memory is drawn, the amount of stuff stored in cache is lowered, and the "free" pool goes back up.

But what happens if a program is a hog, and says "I need 120MB of memory RIGHT NOW!". You don't have that much "free" memory, so the kernel can't give it to the program, even temporarily, so the kernel digs into swap, just long enough to allocate enough free memory to give the program what it needs, then enough cache data is released to allow the "free" memory to go back to a comfortable level.

Through the settling process, the data in swap doesn't get freed from the swap immediately, even though it's cached data. The only time the swap memory is going to get used is if something requests the metadata (or whatever cached information) that is stored in that little segment of swap. So there's no harm in leaving it.

If it bothers you, you can run 'swapoff' then 'swapon' to get rid of it, but it isn't hurting anything.


Memory management is very complex, Understanding The Linux Kernel by O'Reilly gives lots of details.

The idea though is that you can swap out memory that will probably never be used again proactively. You can control how likely the swap is used with a value ranging from 0 to 100 in /proc/sys/vm/swappiness. A Higher number means more likely to be swapped.

Before you start to mess with this, see if the swap is actively being used with by watching the si/so columns of vmstat 3. If those remain 0, then there was swapping going on, but there is no swapping going on currently in which case I recommend you leave it be :-) One reason is that those cached files that free told you about might be useful to have in memory. Don't allow useless process memory to be swapped and you might miss out the chance to cache some files that would be useful to cache.

  • You might want to try 0 for swappiness if you feel you might murder someone if you have to wait for firefox to get that memory back every morning :-) – Kyle Brandt Apr 19 '10 at 19:41
  • There's vm.vfs_cache_pressure as well. I personally think Linux' VM is still be awful, comparing to BSD or Solaris. – poige Aug 25 '11 at 3:40

If you have 95MB of program data that hasn't been accessed in an hour, which would you rather do:

1) Waste 95MB of physical memory holding data that may never, ever be accessed.

2) Swap that 95MB to disk and have an extra 95MB of free physical memory.

The system, sensibly, picks option 2.

You tend to get a moderate amount of memory of this kind on many systems. One common cause is programs that allocate memory during startup and then wait for requests that never arrive. Many Linux systems have half a dozen server programs that are running but not actually ever used.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy