home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.sun.apps:2454 comp.windows.x:19058 comp.unix.ultrix:8264 comp.unix.admin:6153
- Newsgroups: comp.sys.sun.apps,comp.windows.x,comp.unix.ultrix,comp.unix.admin
- Path: sparky!uunet!uchdcc!jpiquer
- From: jpiquer@dcc.uchile.cl (Jo Piquer)
- Subject: Re: Why is xload such a memory pig?
- Originator: jpiquer@tortel
- Sender: usenet@dcc.uchile.cl (Network News)
- Message-ID: <1992Nov12.190254.24366@dcc.uchile.cl>
- Date: Thu, 12 Nov 1992 19:02:54 GMT
- References: <1992Nov11.223350.18090@leland.Stanford.EDU> <1992Nov12.023124.871@mnemosyne.cs.du.edu>
- Organization: Universidad de Chile, Depto. de Ciencias de la Computacion
- Lines: 25
-
-
- In article <1992Nov12.023124.871@mnemosyne.cs.du.edu>, ihastie@nyx.cs.du.edu (Ian Hastie) writes:
- >mosedale@genome.stanford.edu (Dan Mosedale) writes:
- >
- >> F UID PID PPID CP PRI NI SZ RSS WCHAN STAT TT TIME COMMAND
- >>200080011528 3219 3203 0 1 0 252 896 select S ? 0:01 xload -geome
- >>200080011666 3263 3248 0 1 0 248 920 select S ? 0:01 xload -geome
- >>200080011578 3640 3625 0 1 0 248 868 select S ? 0:01 xload -geome
- >>200080012717 3694 3679 0 1 0 248 884 select S ? 0:00 xload -geome
- >
- >OK... I may be being stupid here, but as far as I understand it a programs RSS
- >should always be smaller than it's SZ. At least surely it should not be bigger
- >since this implies that the resident portion is bigger than the total size
- >of the process. Is there really something wierd going on or is it just that
- >ps work differently on Suns in this respect from the way it does on DEC's
- >boxes??
- >
- >Ian.
-
- It's typical in Sun OS4.x, it is due to the shared libs, they are
- counted for RSS but not for the SZ. xload includes a big part of the libX11
- and libc.
- --
- Jose' Piquer (jpiquer@dcc.uchile.cl)
-