Illogical usage of swap

Bob Johnson bob89 at eng.ufl.edu
Wed Mar 16 17:12:05 PST 2005


Colin J. Raven wrote:

>
>Hmm, yeah I should have included what I've actually read in the handbook 
>and elsewhere. In fact I did read that exerpt you quoted the URL 
>for  above sometime previously, when it was quoted in another thread 
>on the list.
>
>Free memory (or the lack thereof) isn't the issue though.
>
>The issue is this:
>Swap: 8192M Total, 116K Used, 8192M Free
>and that's the piece of the puzzle that has us all utterly baffled.
>
>No way in creation this box should be swapping.
>
>  
>
That only tells you how much swap space you have available (8.2GB), it 
tells
you absolutely nothing about why the system might be using some of that 
space.

The previous line

 > 479M Active, 2470M Inact, 337M Wired, 101M Cache, 199M Buf, 5468K Free

says that out of roughly 3.6 GB of memory, only 5.5 MB of it is not in 
use. 
Something ate the memory.  The next clue is that 2.5 GB of that is 
"Inactive"
which means that whatever is using it hasn't accessed it for a while 
(but it is
still claiming to own it).  Perhaps looking at the "RES" column of top will
suggest a culprit without requiring you to become an expert on VM stats. 


Memory pages in the "inactive" queue have been removed from the page
table for the owning processes, but are still intact and a page can be
easily reassigned to the process that owns its contents if the process
tries to access it.   If it stays "inactive" long enough, and the "cache"
queue starts to run low because processes are asking for memory,
a page may be moved to the "cache" queue.  This means that whatever
action is necessary to make the memory available to other processes
has been taken, which in some cases (but not all) will mean that the
contents of the memory have been written out to the backing store
(swap).  Things that can be recovered by other means (e.g. out of the
disk file that they were originally read from) need not be swapped,
they can simply be discarded, but I don't know how smart the VM
system is about that ("pretty smart" seems to be first-order answer). 

It looks to me like something small had not been used in a long time, so it
got written out to the backing store (swap) when you started to get low on
memory.  Note that something in the "cache" queue may still reside
in memory but also reside in swap.  That means the memory it uses is
immediately available for some other use if necessary (because it is 
already
in swap), but is also immediately available for use by the process that 
owns
the object in that memory space (because it still resides in memory).  
Thus,
the mere fact that something has appeared in swap does not mean that
any inefficiency has occured.  It just means you were getting low on
memory and the VM system started planning ahead by making more
memory available.  As long as the process that owns the memory object
in swap doesn't try to access it, it will probably just sit there, doing no
harm.

Pages that don't contain anything owned by any process are in the
"free" queue.  If too much "free" memory accumulates, the VM
system will attempt to find something useful for it to do, perhaps
assigning it to i/o buffers (the "buf" queue).  I suppose that it could
even move objects out of swap and back in to the "cache" queue, but I
don't know if that actually happens, and even if it does, there is no
reason to erase an object from swap until the owning process actually
accesses it and makes it active again (or if you run low on swap).

At least, that's how I understand it, but I may have some of it wrong.  
Read 
http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/vm.html
and see what you think.

- Bob









More information about the freebsd-questions mailing list