home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.sun.apps:2450 comp.windows.x:19021 comp.unix.ultrix:8246 comp.unix.admin:6135
- Newsgroups: comp.sys.sun.apps,comp.windows.x,comp.unix.ultrix,comp.unix.admin
- Path: sparky!uunet!stanford.edu!leland.Stanford.EDU!genome.stanford.edu!mosedale
- From: mosedale@genome.stanford.edu (Dan Mosedale)
- Subject: Why is xload such a memory pig?
- Message-ID: <1992Nov11.223350.18090@leland.Stanford.EDU>
- Sender: news@leland.Stanford.EDU (Mr News)
- Organization: Stanford Yeast Genome Project
- Date: Wed, 11 Nov 92 22:33:50 GMT
- Lines: 29
-
- I'm running X11R5 patchlevel 17 on Sun's and DECs.
-
- On a Sun running SunOS 4.1.2:
-
- -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.
-
- However, once it's running, ps shows that it has a size of ~250k, and
- it's resident set size anywhere between 800k and 1.2megs:
-
- 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
-
- Interestingly, on DECstations running Ultrix 4.2a, which doesn't have
- shared libraries, the executable (also compiled with gcc 2.2.2) is
- ~725K, with a typical SZ of ~1.2meg, and RSS of ~930k.
-
- Why is this happening, and what can I do about it? I don't want
- everyone logged in to have a minimally useful program like xload
- taking up a meg of RSS most of the time...
-
- Thanks,
- Dan Mosedale
-
-