I have no idea why harmad has grown to 250MB. On the other hand 250MB is not that big compared to the memory size of your machine. I'd watch it closely but wouldn't be too concerned for the moment.

Your layout is somewhat astonishing insofar as the system has relatively many CPUs compared to the size of the main memory. As a rule of thumb a modern processor core can efficiently work programs fitting in roughly 1-1.5GB of memory. This of course says nothing about your system at all, rules of thumb don't necessarily cover a specific case.

Looking at your vmstat output your system is near to being memory-bound. The "avm"- and "fre"-columns are in memory pages and "fre" shows roughly 160MB memory to be free - not too much, considering the overall size of the system. For further investigation issue

Code:

svmon -G

(only as root) and look at the results (compare with this thread), maybe there is a memory shortage on your system.

Further places to investigate would be the tuning of the system: analyse (and/or post) the output of

Code:

vmo -a
ioo -a
schedo -a
no -a

To find out which tuning parameters are in effect. The values of tunables are also stored in the files "/etc/tunables/[lastboot]|[nextboot]". Also a place to investigate is

Code:

vmstat -v

which might tell you about I/O-problems (see # of "filesystem I/Os blocked with no fsbuf").

Also something to worry about is the blocked-queue (column "b"), which is non-zero. This corresponds with some (light) paging activity and some wait (rightmost column "wa"). Generally this column being non-zero means some process could run, but has to wait for some reason, usually memory to become freed.

As your "id" column is most times quite high you seem to have no CPU problems at all and your "iostat" output shows relatively low I/O bandwidth. I'd not aggregate over adapters but look at the disk statistics instead, you might want to look at the output of

Code:

iostat 1 | grep -v '0.0'

instead to identify probably hostspots. On the other hand the data you presented don't suggest any I/O-problems at all.

Another point is shared memory: "ps -o vsz" will tell you only about memory which belongs to one process, but will neglect shared memory. You might want to issue a

Code:

ipcs -m

and investigate possible shared memory pools which might consume large amounts of memory.

I hope this helps.

bakunin