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