swap -s output in BigBrother monitor inconsistent and incorrect

swap -s output in BigBrother monitor inconsistent and incorrect

Post by t_monkeybo » Thu, 27 Nov 2003 22:34:36


Hi all,

I've run into a llittle problem with determining swap space usage on
our Sun servers using swap -s.

swap -s run from the command line will return:
total: 465960k bytes allocated + 241456k reserved = 707416k used,
2871024k available

swap -s which is used in an external script in BigBrother returns:
total: 467984 bytes allocated + 2338632 reserved = 2806616 used,
771824 available

The external script is a perl script. To make matters worse, every
once in a while swap -s in the external BigBrother script will return
the same result as from the command line.

Thanks,
Tom
 
 
 

swap -s output in BigBrother monitor inconsistent and incorrect

Post by cet1 » Fri, 28 Nov 2003 00:48:19

In article < XXXX@XXXXX.COM >,


The difference is (almost exactly) 2GB extra "reserved" swap space.
This is indicative of something allocating a lot of virtual memory,
but not actually using it, e.g. a mammoth malloc() or an anonymous
mmap (without MAP_NORESERVE).

Try checking for processes with huge VSZ values, e.g. by

ps -eo pid,vsz,comm | sort +1n | tail

If you identify a likely culprit, apply pmap(1) to it.

Chris Thompson
Email: cet1 [at] cam.ac.uk

 
 
 

swap -s output in BigBrother monitor inconsistent and incorrect

Post by t_monkeybo » Fri, 28 Nov 2003 04:54:48

Chris,

Thanks, that pointed me in the right direction and I found the culprit.

Tom
 
 
 

swap -s output in BigBrother monitor inconsistent and incorrect

Post by Casper H.S » Sat, 29 Nov 2003 01:18:07


XXXX@XXXXX.COM (Tom) writes:



Was it tail?

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
 
 
 

swap -s output in BigBrother monitor inconsistent and incorrect

Post by cet1 » Thu, 04 Dec 2003 04:25:12

In article <3fc623bf$0$1499$ XXXX@XXXXX.COM >,


I would be interested to know the answer to that question, as well.
Casper obviously suspects

4348627 *tail* tail reserves 2G when reading from a stdin.

fixed by 108089-03 (7) 108090-03 (7_x86) 111225-01 (8) or 111226-01 (8_x86)
in late 2001. Or according to one report on SunSolve, *not* fixed by them...

Chris Thompson
Email: cet1 [at] cam.ac.uk