Well, the answers came in (are still coming) thick and fast as always. Too
many respondees to thank individually.
One person commented that you should never be into swap - if you are then
you are basically out of memory. My boss said this as well. I'd be
interested in any other comments on this - I've always believed that swap is
there to be used.
Here's the summary:
a. ps -o pmem,vsz,rss,pid,user,command | sort -n |more
or
ps -ef -o pid,user,vsz,rss,comm | sort -k 3n | tail
That will give you the processes using the most virtual memory (for the
most part). Changing the 3 to a 4 should reflect the processes using
the most resident memory.
ps has these nice options since about 2.5, "ps --help" for more info
b. top has a sort by memory usage option. top:
http://www.groupsys.com/topinfo. This should give you all of the
information you want and plenty more.
c. tmpfs. By default /tmp is actually usingtmpfs a memory based filesystem
( using free memory + swap), and if you put a 500MB file on /tmp, you have
just taken 500M of free space from the VM subsystem. You might want to
consider switching /tmp to UFS if you think that could be a problem. Do a
man on tmpfs for more info. df -k /tmp will give you a rough idea of how
much memory /tmp is consuming by looking at the 'used' field.
d. vmstat to get an idea of paging activity.
e. Try memtool from http://playground.sun.con/pub/memtool (package name =
RMCmem)
f. memstat from www.sun.com/sun-on-net
g. use the /usr/proc/bin/pmap command:
[jed@supernova /dev/pts/8]$ ./pmap $$
25559: /bin/tcsh
00010000 312K read/exec /usr/bin/tcsh
0006C000 40K read/write/exec /usr/bin/tcsh
00076000 200K read/write/exec [ heap ]
FF100000 656K read/exec /usr/lib/libc.so.1
FF1B2000 32K read/write/exec /usr/lib/libc.so.1
.
.
.
As it turned out, for me, /tmp usage was not an issue. The culprit was
apache/httpd. Gracefully restarting apache freed up 250+mb of swap. We're
now looking into memory leaks in apache.
Thanks for everyone's help.
Eric
******************************
Eric Watson
Sr. Systems Administrator
Harvard Law School
617-496-6518
******************************
S
U BEFORE POSTING please READ the FAQ located at
N ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/faq
. and the list POLICY statement located at
M ftp://ftp.cs.toronto.edu/pub/jdd/sun-managers/policy
A To submit questions/summaries to this list send your email message to:
N sun-managers@ececs.uc.edu
A To unsubscribe from this list please send an email message to:
G majordomo@sunmanagers.ececs.uc.edu
E and in the BODY type:
R unsubscribe sun-managers
S Or
. unsubscribe sun-managers original@subscription.address
L To view an archive of this list please visit:
I http://www.latech.edu/sunman.html
S
T
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:14:12 CDT