Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Jun 2005 17:28:18 +1000 (EST)
From:      Ian Smith <smithi@nimnet.asn.au>
To:        freebsd-questions@freebsd.org
Subject:   When does swap decreases
Message-ID:  <Pine.BSF.3.96.1050621164507.28656B-100000@gaia.nimnet.asn.au>
In-Reply-To: <20050621043701.EC21A16A429@hub.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
[was] Re: freebsd-questions Digest, Vol 100, Issue 5
 > Message: 32
 > Date: Mon, 20 Jun 2005 23:07:58 -0400 (EDT)
 > From: Francisco Reyes <lists@natserv.com>
 > Subject: Re: When does swap decreases
 > To: Dan Nelson <dnelson@allantgroup.com>
 > Cc: FreeBSD Questions List <questions@freebsd.org>

 > On Mon, 20 Jun 2005, Dan Nelson wrote:
 > 
 > > In the last episode (Jun 20), Francisco Reyes said:
 > >> How wonder how the current method affects performance. Basically if
 > >> there is a surge of memory usage and processes start that use the
 > >> swap and these processes are long lived.. I wonder if performance
 > >> will be affected.
 > >
 > > There may even be a performance gain, since if the system comes under
 > > memory pressure again, some of the in-memory pages of those long-lived
 > > processes previously copied to swap may still be clean, and the system
 > > won't even have to page them out; it can simply free the RAM.  I can't
 > > think of any way for there to be a performance hit, unless you actually
 > > run out of swap.

 > I must really be missing something here..
 > My case. 384MB of RAM
 > For several days swap was 0.
 > That to me means that everything was fitting nicely into memory.

I needn't add anything to Dan's technical explanation, especially in a
subsequent message to the one quoted; you can confidently listen to him.

However, Francisco, I'd like to address your apparent impression that
any use of swap is somehow 'bad' .. 

 > At one point in the last few days I must have opened too many 
 > windows/apps.. and the OS actually had to use swap.

Yes, well that's ok.

 > Once I closed programs (xpecially X, Opera, and other GUI apps) I expected 
 > the swap would go back to 0.
 > 
 > Swap remained at 10MB.. Whatever processes are using the swap aren't they 
 > accessing the HD?

If you run top you'll see that, while swap usage often doesn't show a
decrease, or at least as much as you'd expect, meanwhile it will show
more Free memory.  Further processes you open will first use that, and
possibly some of your Cache and/or Buf memory, before increasing swap. 
 
 > Can there be swap usage, yet the OS doing all the work on memory?

Yes indeed.  For example, on this little old Compaq Armada 1500c laptop
with all of 160Mb RAM, it often shows up to 40-50% swap used, but most
of it is associated with, for example, the 19 kwrite windows I currently
have open, or perhaps a dozen communicator-linux threads, without at all
impacting performance (such as it is on a 300MHz Celeron :) because most
of these processes are quiescent.  Here's the top of my current top list
ordered by resident memory use ('o res' in top).

last pid: 39824;  load averages:  0.01,  0.05,  0.00   up 61+20:05:59 17:03:21
98 processes:  5 running, 92 sleeping, 1 zombie
CPU states:  1.5% user,  0.2% nice,  2.0% system,  0.0% interrupt, 96.3% idle
Mem: 85M Active, 13M Inact, 36M Wired, 5804K Cache, 25M Buf, 14M Free
Swap: 192M Total, 72M Used, 120M Free, 37% Inuse

  PID USERNAME PRI NICE  SIZE    RES STATE    TIME   WCPU    CPU COMMAND
38686 smithi     2   0 30904K 25060K select   6:40  0.00%  0.00% communicator-l
18434 smithi     2   0 28844K 18660K select 412:00  0.93%  0.93% XF86_SVGA
18491 smithi     2   0 24292K 13084K select  27:50  0.00%  0.00% kdeinit
38688 smithi     2   0 16820K  8640K select   0:00  0.00%  0.00% communicator-l
34607 smithi     2   0 20068K  7532K select   3:50  0.00%  0.00% kdeinit
18489 smithi     2   0 18056K  6236K select  10:00  0.00%  0.00% kdeinit
31536 smithi     2   0 20064K  5416K select   0:40  0.00%  0.00% kdeinit
39334 smithi     2   0  7980K  5400K select   0:05  0.00%  0.00% gs
31507 smithi     2   0 20100K  4736K select   0:38  0.00%  0.00% kdeinit
18499 smithi     2   0 16544K  4436K select  58:08  0.00%  0.00% kdeinit
18458 smithi     2   0 15236K  4400K select 132:26  0.00%  0.00% kdeinit
18500 smithi     2   0 16180K  4332K select   2:07  0.00%  0.00% kdeinit
18495 smithi     2   0 15084K  4256K select  49:08  0.00%  0.00% kdeinit
18475 smithi     2   0 16960K  4156K select   3:44  0.00%  0.00% kdeinit
18506 smithi     2   0 16752K  3660K select  18:40  0.00%  0.00% kdeinit
18502 smithi     2   0 16312K  3060K select   7:24  0.20%  0.20% kdeinit
34420 smithi     2   0 14892K  2668K select   0:01  0.00%  0.00% kdeinit
18501 smithi     2   0 16264K  2640K select   5:10  0.00%  0.00% kdeinit
29824 smithi     2   0 20020K  2432K select   1:26  0.00%  0.00% kdeinit
39331 smithi     2   0  3000K  2168K select   0:01  0.00%  0.00% gv
18456 smithi     2   0 15000K  2116K select   0:01  0.00%  0.00% kdeinit
18505 smithi     2   0 15764K  2056K select   0:33  0.00%  0.00% kdeinit
39728 root       2   0  2476K  1672K select   0:11  0.00%  0.00% ppp
39731 smithi     2   0  2504K  1612K select   0:03  0.00%  0.00% ssh
18510 smithi     2   0 22456K  1220K select   1:14  0.00%  0.00% kdeinit
18473 smithi     2   0 16908K  1088K select   0:08  0.00%  0.00% kdeinit
39805 smithi    36   4  2036K  1068K RUN      0:04  0.05%  0.05% top
18474 smithi     2   0  9696K  1024K select   0:06  0.00%  0.00% ksmserver
18449 smithi     2   0 14532K   992K select   0:01  0.00%  0.00% kdeinit
18487 smithi     2   0  6020K   964K poll   305:49  0.00%  0.00% x11amp
[..]

Nothing much to worry about there; I'm in good shape, check the uptime,
actually since January, given that it's asleep when I am :)  Eventually
Netscape will leak enough memory I'll need to restart it to free another
30Mb or so, but that's not FreeBSD's fault.  (4.5-RELEASE, fwiw) 

In short, be glad you only have 10Mb swap used to worry about :)

Cheers, Ian




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1050621164507.28656B-100000>