Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Feb 2005 17:31:05 +0100 (CET)
From:      Oliver Fromme <olli@lurza.secnetix.de>
To:        freebsd-stable@FreeBSD.ORG
Subject:   Re: swapfile being eaten by unknown process
Message-ID:  <200502151631.j1FGV5eA034048@lurza.secnetix.de>
In-Reply-To: <20050215151712.M67335@reiteration.net>

next in thread | previous in thread | raw e-mail | index | archive | help
John <lists@reiteration.net> wrote:
 > Thanks for your input so far. Here is the output from top:
 > 
 > last pid: 59737;  load averages:  0.02,  0.03,  0.00    up 1+18:32:57  15:16:36
 > 82 processes:  1 running, 79 sleeping, 2 zombie
 > CPU states:  0.4% user,  0.0% nice,  0.4% system,  0.0% interrupt, 99.2% idle
 > Mem: 105M Active, 31M Inact, 61M Wired, 144K Cache, 33M Buf, 33M Free
 > Swap: 455M Total, 86M Used, 369M Free, 18% Inuse
 > 
 >   PID USERNAME       WRITE  FAULT  TOTAL PERCENT COMMAND
 >   177 root             0      0      0      0      0      0   0.00% adjkerntz
 > 59693 www              0      0      0      0      0      0   0.00% speedy_back
 > 59692 www              0      0      0      0      0      0   0.00% speedy_back
 > 59663 www              0      0      0      0      0      0   0.00% speedy_back
 > 59662 www              0      0      0      0      0      0   0.00% speedy_back
 > 59658 www              0      0      0      0      0      0   0.00% speedy_back
 > 
 > [...]
 > 
 > lots of other processes but all with 0s. occasionally I will see numbers under
 > VCSW  IVCSW   READ  but they just flash on then its back to 0 again.

That looks pretty normal.  In fact, it looks perfectly
fine.  There doesn't seem to be any significant paging
activity, but maybe some processes have been swapped to
disk (which is normal).

Type "vmstat -w 5" and watch the output of the "po" (page
out) and "sr" (scan rate) columns for, say, half a minute.
If they're near zero most of the time, there is no paging
activity, and you need not worry about RAM.

Next, I'd suggest you type "ps -waxwum | less".  That will
dispay a list of processes sorted by memory usage (largest
ones at the top).  Check the top-10 or so for any processes
that might be kill candidates.  If in doubt, copy&paste the
top-10 into a follow-up in this thread.

 > I need to
 > look up what those 2 processes are doing zombified.

Zombie processes don't take up any memory (except for the
entry in the process table, but that's just a few bytes),
so they shouldn't cause any problem.

 > I think I just need more RAM, but I'd expect there to be none free before it
 > starts eating swap. Why with free RAM wouldn't my swap also be liberated?

You do not need more RAM.  At most, a little more swap
space wouldn't hurt, but even that isn't strictly
necessary, given that only 18% of your swap are in use.
I'd start worrying if that number goes beyond 50%.

FreeBSD tries to conserve RAM by swapping processes and
pages to disk which haven't been used for a certain time.
For example, on a system which runs X11, you'll see the
text-mode gettys (those running one the syscons virtual
consoles) being moved to swap.  That's a good thing,
because those processes aren't needed normally, so keeping
them in RAM would be a waste of memory.  If they're used
one day, they're paged back into RAM pretty quickly.

Also, when RAM begins to get full, FreeBSD starts paging
more aggressively.  If the situation clears up and RAM
gets free again, those pages stay in swap until they're
actually used.

For those reasons (and others) it is normal that swap space
is being used even though there is free RAM available.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when was the
last time you needed one?"
        -- Tom Cargil, C++ Journal



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200502151631.j1FGV5eA034048>