home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.unix.admin:6161 comp.unix.ultrix:8274 comp.windows.x:19069 comp.sys.sun.apps:2457
- Newsgroups: comp.unix.admin,comp.unix.ultrix,comp.windows.x,comp.sys.sun.apps
- Path: sparky!uunet!ukma!usenet.ins.cwru.edu!agate!doc.ic.ac.uk!cc.ic.ac.uk!imperial.ac.uk!vulture
- From: vulture@imperial.ac.uk (Thomas Sippel - Dau)
- Subject: Re: Why is xload such a memory pig?
- Message-ID: <1992Nov12.202948.24923@cc.ic.ac.uk>
- Sender: vulture@carrion.cc.ic.ac.uk (Thomas Sippel - Dau)
- Nntp-Posting-Host: cscgc
- Reply-To: cmaae47@imperial.ac.uk
- Organization: Imperial College of Science, Technology and Medicine
- References: <1992Nov11.223350.18090@leland.Stanford.EDU>
- Date: Thu, 12 Nov 92 20:29:47 GMT
- Lines: 28
-
- In article <1992Nov11.223350.18090@leland.Stanford.EDU>, mosedale@genome.stanford.edu (Dan Mosedale) writes:
- .....
- - -rwxr-sr-x 1 root kmem 24576 Oct 1 18:07 xload*
- -
- - The executable was compiled with gcc 2.2.2, and is nice and small
- - since it was linked with shared libraries.
-
- I guess it is just X what is the pig. This I found on IRIX
-
- carrion$ ls -l `whence xload`
- -rwxr-sr-x 1 root sys 254128 Mar 6 1992 /usr/bin/X11/xload
-
- carrion$ ps -le
- F S UID PID PPID C PRI NI P SZ:RSS WCHAN TTY TIME COMD
- 30 S 98 15020 1 0 +39 24 * 482:119 80149700 ? 0:21 gr_osview
- 30 S 98 15023 1 0 26 24 * 328:39 80149700 ? 0:26 xload
-
- gr_osview is a similar (though more useful but proprietary) system activity
- display tool.
-
- Thomas
-
- --
- *** This is the operative statement, all previous statements are inoperative.
- * email: cmaae47 @ ic.ac.uk (Thomas Sippel - Dau) (uk.ac.ic on Janet)
- * voice: +44 71 589 5111 x4937 or 4934 (day), or +44 71 823 9497 (fax)
- * snail: Imperial College of Science, Technology and Medicine
- * The Center for Computing Services, Kensington SW7 2BX, Great Britain
-