What is eating swap?

Tyler Aviss tjaviss-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Tue Jul 3 21:41:17 UTC 2007


You could try to manually figure it out.

ps axwweo "vsize rss ruser pid fname"

It should give you output like:

  4268   916  taviss   20648 ps
  1740   568  root     21396 pump

As per my understanding:
    VSIZE (Virtual memory SIZE) - The amount of memory the process is
    currently using. This includes the amount in RAM and the amount in
    swap.

    RSS (Resident Set Size) - The portion of a process that exists in
    physical memory (RAM). The rest of the program exists in swap. If
    the computer has not used swap, this number will be equal to
    VSIZE.

So that means that your VSIZE-RSS should indicate the amount of swap
being used. From there, you could find out what is consuming lots of
swap:

ps -axwweo "vsize rss ruser pid fname" | awk '{print "Swap used from
PID #" $4 " is " $1-$2}'

However, you're right in that the results of such don't seem to be
100% true, as testing showed that you can have a bigger VSIZE than RSS
on machines that don't use a swap partition at all. However, a big
difference might lead you to the guilty process...

On 6/28/07, Fraser Campbell <fraser-eicrhRFjby5dCsDujFhwbypxlwaOVQ5f at public.gmane.org> wrote:
> Funny that I haven't really run into this one before, hoping someone here has
> ideas ...
>
> I have a box with lots of free memory where swap usage is growing (slowly)
> despite lots of free memory and swap is actively being used (according to
> vmstat).  Here's what free has to say:
>
>                  total       used       free     shared    buffers     cached
>     Mem:       1034640     439260     595380          0      34404      84544
>     -/+ buffers/cache:     320312     714328
>     Swap:      2097144    1793680     303464
>
> It is RHEL4 (kernel 2.6.9-22.ELsmp 32-bit).
>
> There is no single process whose virtual size wouldn't fit within the 700MB of
> supposedly free memory.  Interestingly although swap use is growing, "used"
> memory (the 320312 figure) is supposedly dropping.
>
> Normally when a box has free memory I can coax it into increasing the
> filesystem cache easily (find /usr -type f -exec cat '{}' \; > /dev/null), in
> this case filesystem cache does not grow at all no matter how much disk I
> read ... this suggests to me that there really is no free memory, or perhaps
> just that the kernel is in a really bad state.
>
> Is there a tool which can dig through memory to say which processes are
> pointing at the swapspace?
>
> Red Hat has an FAQ on this topic and they suggest looking at the swapped field
> in top (http://kbase.redhat.com/faq/FAQ_85_9807.shtm).  As far as I can tell
> they are completely wrong, all of the numbers from top look quite bogus (on
> this and other machines).
>
> My other thought was that the box was hacked and some processes hidden from
> me ... at least so far I don't see any such indication.
>
> --
> Fraser Campbell <fraser-Txk5XLRqZ6CsTnJN9+BGXg at public.gmane.org>
> Georgetown, Ontario, Canada
> --
> The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
>
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list